GitLab Patches Code Execution, Information Disclosure Vulnerabilities

GitLab has rolled out Community Edition (CE) and Enterprise Edition (EE) security updates that resolve 13 vulnerabilities, including three high-severity bugs.

The most severe is CVE-2026-10086, an XSS flaw in the Analytics dashboard of GitLab EE, rooted in the improper sanitization of user-supplied input.

According to GitLab, the security defect could have allowed an authenticated user with developer rights to execute arbitrary client-side code in the context of other users’ sessions.

Next in line is CVE-2026-10712, an XSS in the Web IDE workbench asset handler that could have allowed unauthenticated attackers to execute JavaScript code in users’ browser sessions.

The third high-severity vulnerability is CVE-2026-12053, described as an insufficient output filtering in Duo Workflows, which could have allowed users to access sensitive information already committed to a project.

The fresh GitLab CE/EE updates also resolve seven medium-severity flaws, including authorization bypass, incorrect authorization, insufficient filtering, improper input validation, and improper access control issues.

Advertisement. Scroll to continue reading.

Successful exploitation of these bugs could have led to settings tampering, confidential information disclosure, DAST site profile secrets exfiltration, sensitive information being written to logs, content concealment, Maven package metadata overwrite, and package metadata disclosure.

Patches for all these flaws were included in GitLab CE/EE versions 19.1.1, 19.0.3, and 18.11.6. Users are advised to update their deployments as soon as possible.

“These versions contain important bug and security fixes, and we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately. GitLab.com is already running the patched version,” GitLab notes.

Related: 25-Year-Old Vulnerability Patched in Curl

Related: Chrome 149 Update Resolves 18 Severe Vulnerabilities

Related: Exclusive: Meet AIVEX, a New Triage Model Built to Reduce Supply Chain Threat and Risk

Related: New Exploit Bypasses Apple’s Boot Defenses, Affects Millions of iPhones

https://www.securityweek.com/gitlab-patches-code-execution-information-disclosure-vulnerabilities/




25-Year-Old Vulnerability Patched in Curl

The open source data transfer tool and library curl has been updated this week with patches for 18 vulnerabilities, including one introduced 25 years ago.

The flaws, four medium and 14 low-severity, were discovered as part of a community effort after Anthropic’s Mythos discovered a single curl bug in early May.

This release resolves the highest number of CVEs patched with a single curl update, including an issue that was introduced in version 7.7, shipped on March 22, 2001.

Tracked as CVE-2026-8932, it is described as an mTLS connection reuse and could lead to authentication bypass. It affects libcurl applications and not the curl command-line tool.

The CVE exists because “libcurl could reuse an existing connection even after client certificate or private key settings had changed,” vulnerability management firm Aisle says.

Aisle used its AI platform to identify multiple weaknesses across curl and libcurl, six of which were issued a CVE this year, CVE-2026-8932 included.

Advertisement. Scroll to continue reading.

The other identified flaws include credential confusion (CVE-2026-8926), double-free (CVE-2026-8925), use-after-free (CVE-2026-9080 and CVE-2026-10536), and improper host validation (CVE-2026-9547).

As the company suggests, it’s no surprise that Mythos found a single curl bug and that few security issues are being surfaced in the popular tool and library.

“Curl is of particular interest to security researchers: the easy bugs are long gone, and what remains is difficult to find: old protocol paths, state reuse, callback behavior, credential selection, and code paths that are easily forgotten about,” Aisle says.

Over 30 billion devices use curl today for data transfer, including servers, phones, and cars, and vulnerabilities in it could prove highly valuable to attackers. However, there have been no public reports of successful in-the-wild exploitation of any security defect in curl.

Related: Chrome 149 Update Resolves 18 Severe Vulnerabilities

Related: Cisco SD-WAN Zero-Day Exploited Months Before Patching

Related: Anthropic’s Mythos Model Found Vulnerabilities in Classified US Government Systems, Official Says

Related: Data Exposure Flaws Threaten Dify AI Platform Used by 1 Million Apps

https://www.securityweek.com/25-year-old-vulnerability-patched-in-curl/




Chrome 149 Update Resolves 18 Severe Vulnerabilities

Google on Wednesday rolled out a new Chrome 149 update that resolves 18 vulnerabilities, including four critical and 14 high-severity security defects.

More than half of the addressed issues, including three critical and seven high-severity, are use-after-free flaws, a type of memory corruption bug that could lead to remote code execution (RCE).

In Chrome, use-after-free vulnerabilities can be combined with security holes in the underlying operating system or in a privileged browser process to escape the sandbox.

The remaining eight issues patched in this update are out-of-bounds read, inappropriate implementation, uninitialized use, and insufficient validation of untrusted input bugs.

Per Google’s advisory, the most severe of the flaws was reported by an anonymous researcher. The company has yet to disclose the bug bounty amount to be rewarded for the report.

The remaining 17 security defects were discovered by Google, a trend that has been ongoing for the past couple of months, likely fueled by the use of AI.

Advertisement. Scroll to continue reading.

Also notable is the fact that, following a spike in new vulnerability discoveries in April and May, which culminated in a massive batch of 429 patches in early June, the number of fresh security weaknesses addressed with each new Chrome release has dropped into the lower two digits.

Google makes no mention of any of the newly resolved vulnerabilities being exploited in the wild.

The latest Chrome iteration is now rolling out as versions 149.0.7827.196/197 for Windows and macOS and as version 149.0.7827.196 for Linux.

Related: Exclusive: Meet AIVEX, a New Triage Model Built to Reduce Supply Chain Threat and Risk

Related: Chrome and Firefox Updated to Patch Critical, High-Severity Vulnerabilities

Related: Critical Ubiquiti Vulnerabilities in Attackers’ Crosshairs

Related: Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking

https://www.securityweek.com/chrome-149-update-resolves-18-severe-vulnerabilities/




Cisco SD-WAN Zero-Day Exploited Months Before Patching

Google’s Mandiant team has detailed the exploitation of a Cisco Catalyst SD-WAN vulnerability that was exploited as a zero-day months prior to its disclosure.

The vulnerability, tracked as CVE-2026-20245, is the 7th Cisco SD-WAN product flaw whose exploitation came to light in 2026. 

CVE-2026-20245 affects the CLI of Cisco Catalyst SD-WAN Manager and allows an authenticated local attacker to execute arbitrary commands with root privileges using specially crafted files.

The security hole was disclosed by Cisco in early June, and patches were released roughly one week later. 

Mandiant’s investigation began in early 2026 after observing an unidentified threat actor targeting SD-WAN infrastructure at a service provider. 

The attacker established initial access to an SD-WAN Manager instance via SSH in March 2026. They then exploited CVE-2026-20245 to escalate privileges to root.

Advertisement. Scroll to continue reading.

According to Mandiant, the same victim’s SD-WAN Manager systems were previously targeted — either by the same or a different threat actor — possibly through the exploitation of other vulnerabilities, CVE-2026-20127 or CVE-2026-20182, which at the time were also zero-days. 

In the March attack, the hackers authenticated to the SD-WAN Manager instance via SSH using the ‘vmanage-admin’ account and then used that access to change the default admin account’s password. 

“The threat actor subsequently used their active vmanage-admin session to change the password of the admin account back to its original state before terminating their active session. This activity was likely performed to reduce the probability of detection by an administrator trying to log into the device during day-to-day operations,” Mandiant explained.

It added, “The vmanage-admin and admin accounts are default accounts on Cisco Catalyst SD-WAN controllers that have different privileges, but neither possesses root shell access.”

Once they had admin privileges to the targeted system, the attacker exploited CVE-2026-20245 to escalate privileges and achieve full root-level access. 

In an effort to evade detection, the threat actor deleted all files created during the attack, restored altered system configurations, and ran a script to ensure no evidence remained. 

“This campaign underscores the living off the edge paradigm, where threat actors prioritize the compromise of network appliances to bypass traditional security perimeters. As organizations increasingly adopt software-defined networking, the orchestrators managing these environments become primary targets.” Mandiant said.

Additional technical details and IoCs are available in Mandiant’s blog post.

Separately, a cybersecurity firm has reported seeing attacks exploiting CVE-2026-20230, a Cisco Unified CM vulnerability patched in early June. However, Cisco told SecurityWeek that it cannot confirm in-the-wild exploitation as of June 24. 

Related: Cisco Patches Another SD-WAN Zero-Day, the Sixth Exploited in 2026

Related: Critical Ubiquiti Vulnerabilities in Attackers’ Crosshairs

Related: FFmpeg PixelSmash Flaw Allows RCE on Video Players, Media Servers, NAS Appliances

https://www.securityweek.com/cisco-sd-wan-zero-day-exploited-months-before-patching/




Exclusive: Meet AIVEX, a New Triage Model Built to Reduce Supply Chain Threat and Risk

Remediation priority (vulnerability triaging) traditionally focuses on Software Bill of Materials (SBOMs) and Vulnerability Exploitability eXchange (VEX) statements provided with the software and supplemented by CVSS scores. That is not enough in today’s environment.

SBOMs list the components within the software. They emanated from Executive Order 14028 designed to reduce supply chain attacks. VEX statements emerged soon afterward to indicate whether any known vulnerabilities are exploitable. The separate CVSS score is used as a severity indicator for vulnerability remediation priority. It’s not working – supply chain attacks continue.

A major cause is a growing lack of context around exploitation. In the AI Age, the effect of exploitation may differ depending on which stage of an AI lifecycle in which it occurs. Lack of context reduces the effectiveness of remediation priority, while the expansion of AI software will magnify the problem. Supply chain attacks will continue to grow.

(Understanding ‘context’ is essential for understanding anything and everything in life. We perceive things – in this case data – but those things are meaningless in isolation. It is the surrounding, often invisible, context in which we see things that gives them any meaning. For another and different example of the importance of context, again involving AI, see the effect of bad AI context on AI decision-making.)

Devashri Datta is an independent researcher and security architect (specializing in DevSecOps automation, software supply chain security, and governance of large-scale vulnerability and compliance systems) has a solution. This solution comprises two new elements in the triage process: a safety relevance interpretation layer (SRIL) to provide context, and an extension (known as AIVEX) to the CycloneDX VEX to make the context machine readable. 

SRIL provides context, and AIVEX transforms the context into a CycloneDX‑compatible schema suitable for use within the organization’s existing tooling. 

Advertisement. Scroll to continue reading.

Datta’s article explaining SRIL (Moving Beyond Severity Scores: A VEX-Driven Interpretation Layer for Software Supply Chain Governance) will be published by ISACA on July 1. Today, she sat down with SecurityWeek to discuss the failure of existing SBOM/VEX/CVSS, and the manner in which AIVEX/SRIL can change things.

A growing concern

AI can transform a data threat against systems into a physical threat against people – it is increasingly and autonomously driving physical robots. 

If a firm has two CVSS scores — a CVSS 9.8 critical remote code execution flaw in a back-office analytics dashboard and a moderate CVSS 5.2 input-validation bug in the sensor-fusion module of an autonomous delivery robot operating in a public warehouse — current logic dictates patching the former first. But the latter could possibly harm or even kill innocent members of the public. The existing triage logic of using SBOMs, VEX and CVSS scores does not provide this context.

As software-driven autonomous robots increasingly pervade our physical world, context becomes ever more important. “But VEX stops short of safety context,” explained Datta. “It can tell you a vulnerability is not exploitable; but it cannot tell you that if it were exploitable, the consequence would be a vehicle losing steering control at highway speed.” 

The commercial consequence of an autonomous robot causing death because of a software vulnerability that could have been fixed but wasn’t fixed would probably be bankruptcy.

This is the anomalous consequence of relying on CVSS scores: AI turns low threat into very high risk.

The AI Attack Surface

The inability of CVSS to indicate context is a growing concern and has reduced the CVSS value for DevSecOps engineers. Today, with the rise of AI and autonomous robots, a new solution is urgent. But context within AI software is complicated because AI’s attack surface is not the same as a traditional software attack surface.

“An AI system, particularly an agentic one capable of taking actions in the real world, has attack surfaces distributed across training data, model weights, inference pipeline, tool integrations, and deployment infrastructure,” explained Datta. “A compromise at any stage can alter behavior in ways that are difficult to detect and harder to attribute.”

She tackles this problem through the combination of SRIL and AIVEX. 

SRIL

SRIL is not just a vague idea. “Flexera has adopted this and is shipping the version to customers next week; similarly, Anchore is working on it and will ship it in the next version,” she explained.

So, what is it? “SRIL is a structured annotation layer designed to sit above existing vulnerability data, enriching CVSS scores and VEX statements with four dimensions of context that safety-critical environments need but current standards do not provide,” she continued.

The four dimensions are: 

  • Safety domain classification (does the vulnerable component operate within a safety-critical function such as a sensor in an autonomous vehicle); 
  • Lifecycle stage mapping (the attack surface differs between different stages of an AI – training data integrity has a different level of risk than inference-time input validation);
  • Consequence severity modifier (independent of the CVSS score, what is the real-world consequence if this vulnerability is exploited?)
  • Exploitability in context (does the deployment environment, threat actor model, and asset exposure change the exploitability calculation in ways the base VEX statement does not capture?).

In combination, said Datta, “These dimensions allow security teams to generate a safety-adjusted priority – a triage score that reflects not just how severe a vulnerability is in isolation, but how much it matters in the specific operational context where affected software is deployed.”

This is a manual effort required from the DevSecOps team, but one that is fully justified by the potential blast radius of an unpatched low-severity AI vulnerability causing robotic third party harm.

AIVEX

The SRIL data is consumed and processed by the AIVEX. It generates context-rich decisions (such as ‘remediate now’, ‘defer’, or ‘monitor’ in machine readable format.

“The AI Vulnerability Exploitability eXchange is a proposed extension to the CycloneDX VEX schema. It makes SRIL machine-readable in structured fields for model provenance, inference-time attack surface classification, safety domain annotation, and AI lifecycle stage. It is designed to integrate with existing SBOM tooling rather than replace it,” explained Datta. “The CycloneDX working group has it under active consideration.”

VEX tells you whether a CVE is exploitable in a given product configuration. “AIVEX asks the question that comes afterward,” she continued. “If the vulnerable component is an AI model acting as an agent in the real world, what does exploitation actually mean? That’s a different problem class, and the industry doesn’t have a standard for it yet.”

AI compliance benefits

More realistic triaging is not the only benefit provided by SRIL/AIVEX. It also benefits increasingly arduous AI regulatory compliance. “A life cycle-based interpretation model improves traceability and auditability without introducing new compliance burdens. The US National Institute of Standards and Technology (NIST) Secure Software Development Framework promotes risk-informed decisions,” she explains in the paper being published on July 1.

“This model operationalizes that guidance by clarifying how SBOM and VEX data feed into real-world governance decisions. Importantly, the model does not redefine these standards; it helps organizations apply them consistently.”

She goes further, anticipating future international regulation convergence. The EU AI Act is in force, but full enforcement of its most demanding aspects for AI embedded in regulated products (conformity assessment, risk management, logging, human oversight) will only begin in August of this year. 

Meanwhile, she explained, “NIST’s AI Risk Management Framework similarly emphasizes governance processes that account for operational context and real-world impact of AI system failures, not merely technical severity. Sector-specific guidance from FDA (medical devices), CISA (critical infrastructure), and the Department of Transportation (autonomous vehicles) is independently converging on the same need: a structured mechanism to connect vulnerability data to safety consequence.”

Such increasingly arduous regulations make demands without telling DevSecOps how to comply with those demands. “SBOMs tell you what components you have. VEX tells you whether they’re exploitable. But SRIL asks the question that regulators actually care about: if exploited, does it matter to a patient, a power grid or a passenger?”

Related: Are SBOMs Failing? Supply Chain Attacks Rise as Security Teams Struggle With SBOM Data

Related: SBOM Pioneer Allan Friedman Joins NetRise to Advance Supply Chain Visibility

Related: AI and Cybersecurity – Everything You Wanted to Know, But Were Afraid to Ask

Related: The Wild West of Agentic AI – An Attack Surface CISOs Can’t Afford to Ignore

https://www.securityweek.com/exclusive-meet-aivex-a-new-triage-model-built-to-reduce-supply-chain-threat-and-risk/




Critical Ubiquiti Vulnerabilities in Attackers’ Crosshairs

Threat actors have been targeting three critical-severity vulnerabilities in Ubiquiti devices, the US cybersecurity agency CISA warns.

The exploited flaws, tracked as CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910, with a CVSS score of 10/10, were patched last month.

CVE-2026-34908 is described as an improper access control issue that could allow remote attackers to make unauthorized changes to vulnerable UniFi OS devices.

CVE-2026-34909 is a path traversal defect that could be exploited to access files on the underlying operating system and manipulate them to access underlying accounts.

CVE-2026-34910 is described as an improper input validation weakness that allows attackers to execute command injection attacks over the network. A variant of the flaw, tracked as CVE-2026-33000 (CVSS score of 9.1), requires authentication.

On May 21, Ubiquiti announced that UniFi OS Server version 5.0.8 was released with patches for these vulnerabilities.

Advertisement. Scroll to continue reading.

The company made no mention of their in-the-wild exploitation, yet multiple users reported on the company’s forums and on Reddit that the bugs were exploited in the wild, likely as zero-days, to create rogue administrator accounts under the username ‘John Sim’, in what appear to have been automated reconnaissance attacks.

A BishopFox analysis of the patches shows that CVE-2026-34908 and CVE-2026-34909 are an authentication gateway bypass rooted in how NGINX processes crafted requests. In raw form, the requests begin with the auth-exempt prefix, while in normalized form they resolve to an authenticated internal route.

“We confirmed the bypass against a live [UniFi OS version] 5.0.6 virtual machine. Requests built this way reached internal backends that are supposed to require authentication,” BishopFox said.

The gateway bypass then leads to CVE-2026-34910, the lack of validation of package names in a function that handles updates. It allows an attacker to supply a crafted package name containing shell metacharacters, as well as an option that forces the command code path, leading to command injection.

“We validated the unauthenticated path against our live 5.0.6 test target using a benign, time-based oracle: a request whose injected portion simply causes the server to pause for a fixed interval before responding,” the company says.

As the Centre for Cybersecurity Belgium points out, UniFi OS devices are designed for managing infrastructure and are centrally integrated into networks. Their successful compromise could allow attackers to move laterally into enterprise environments.

On Tuesday, CISA added CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 to its Known Exploited Vulnerabilities (KEV) catalog, urging federal agencies to patch them within three days, in line with BOD 26-04 requirements.

The same applies to CVE-2025-67038 (CVSS score of 9.8), an unauthenticated OS command injection defect in Lantronix EDS5000 that could lead to code execution with root privileges. The issue was disclosed in April along with 21 other Lantronix and Silex vulnerabilities, collectively tracked as BRIDGE:BREAK.

Related: Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking

Related: Hackers Exploiting Cisco Unified CM Vulnerability

Related: Eight-Year-Old Samsung KNOX Flaw Exposed Millions of Galaxy Devices to Kernel Attacks

Related: F5 Patches Critical, High-Severity NGINX Vulnerabilities

https://www.securityweek.com/critical-ubiquiti-vulnerabilities-in-attackers-crosshairs/




Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking

A systemic class of exploitable CI/CD vulnerabilities in the open source software supply chain exposes millions of repositories to takeover, cybersecurity firm Novee warns.

Referred to as Cordyceps, the security defects allow unauthenticated attackers to hijack developer workflows and gain full control over affected repositories.

Agentic coding, Novee says, has resulted in insecure patterns being reproduced across millions of repositories through automatically generated CI/CD workflows.

The flaws, ranging from command injection to authentication logic, artifact poisoning, and privilege escalation, impact build tooling from Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation, with a ripple effect reaching thousands of other organizations.

Any unauthenticated attacker with a free account can exploit these weaknesses to forge approvals, push code, and exfiltrate credentials, without an organization membership or special privileges.

“Once the exploit pattern was identified, 654 repositories were flagged in a single scan, and more than 300 were confirmed fully exploitable – attacker-controlled code execution, credential theft, or outright supply chain compromise,” Novee says.

Advertisement. Scroll to continue reading.

The vulnerabilities, the cybersecurity firm says, reside in GitHub Actions YAML. Low-privileged workflows can be triggered via untrusted pull requests or comments, with the output ending in high-privilege workflows that authenticate to cloud providers with the maintainer’s permissions.

“These workflows run shell commands, authenticate to cloud providers, hold signing keys, and publish releases, yet they are treated as ‘configuration,’ not as security-critical code. The result: command injection, privilege escalation, and supply-chain compromise hiding in plain sight,” Novee says.

The cybersecurity firm identified the flaws in GitHub Actions .yml files, which are overlooked by traditional security scanners, but underlines that this is not a GitHub-exclusive weakness, and that any workflow management system is susceptible.

“When that same software is then installed by thousands of organizations, one compromised workflow in one repository can ripple outward into banks, cloud accounts, AI labs, and end-user devices,” Novee says.

Webinar Today: Modern Exposure Validation in the AI Era

Cordyceps was confirmed to impact Microsoft’s Azure Sentinel, Google’s AI Agent Development Kit, Apache’s Doris analytics database, Cloudflare’s Workers SDK, and Python Software Foundation’s Black code formatter, impacting all organizations that rely on these repositories.

The exploitation of these vulnerabilities could lead to supply chain compromise (through malicious packages published on NPM, PyPI, Crates.io, Docker/GHCR, and Helm), malicious code pushed to protected branches, forced CI checks, compromised credentials across AWS, GCP, and Netlify, compromised self-hosted runners, and bot impersonation.

“This supply chain vulnerability lies in the foundational open-source plumbing the entire industry runs on, and the kind of issue that hides from scanners because, technically, every individual piece is working as designed. The workflow does what it was told. The vulnerability exists only in the composition – untrusted data crossing a trust boundary that no one audited,” Novee says.

Related: Anthropic’s Mythos Model Found Vulnerabilities in Classified US Government Systems, Official Says

Related: Dragos Unveils AI for OT Security

Related: Data Exposure Flaws Threaten Dify AI Platform Used by 1 Million Apps

Related: FFmpeg PixelSmash Flaw Allows RCE on Video Players, Media Servers, NAS Appliances

https://www.securityweek.com/exploitable-ci-cd-vulnerabilities-expose-millions-of-repositories-to-hijacking/




Webinar Today: Modern Exposure Validation in the AI Era

Weeks to hours. That’s how fast AI now turns a new vulnerability into a working exploit.

Patch-and-pentest cycles were built for a slower world. The question has changed from “are we patched?” to “are we secure right now, and can we prove it?”

Here’s the hard truth: finding exposures was never the problem. Proving which ones an attacker could actually use, and deciding the right call on evidence, is the hard part. And no single tool gets you there: automated pentesting only tests CVEs that have an exploit, on assets it can safely reach, leaving your most vulnerabilities unvalidated.

Join the live webinar on June 24th at 1PM ET to learn how to:

  • Turn every exposure into a defensible Patch, Mitigate, Monitor, or Accept with Evidence decision, backed by proof, not a severity score
  • Run automated pentesting, exposure validation, and BAS as one program across attack surfaces, exposures, and controls
  • Answer “is this exploitable here?” for the restricted, air-gapped, and no-exploit assets a live exploit can’t touch

The exploit timeline collapsed. Make sure your validation didn’t.

https://www.securityweek.com/webinar-today-modern-exposure-validation-in-the-ai-era/




Decades-Old Squid Proxy Flaw ‘Squidbleed’ Can Expose User Data

Security researchers at Calif.io have disclosed a memory leak vulnerability in Squid Proxy that has existed in the software since 1997. 

Squid is a widely used open source web proxy that can reduce bandwidth and improve response times via caching. Squid supports HTTP, HTTPS, FTP, and other protocols.

Calif researchers discovered that Squid is affected by a vulnerability that is similar to the notorious OpenSSL vulnerability known as Heartbleed, which is why they have dubbed it Squidbleed.

Officially tracked as CVE-2026-47729, the vulnerability causes Squid’s FTP parser to read beyond the boundary of a memory buffer, into a region that may contain a previous user’s uncleared HTTP request data.

Exploitation requires the attacker to control an FTP server reachable from the proxy. Squidbleed poses the biggest risk in shared proxy environments, such as corporate networks, schools, and public Wi-Fi hotspots, where multiple users may route traffic via the same Squid instance. 

An attacker with access to such a network could silently siphon HTTP request data belonging to other users, potentially capturing authentication credentials, session tokens, and API keys. 

Advertisement. Scroll to continue reading.

The exposure is limited to cleartext HTTP traffic and deployments where Squid terminates TLS. Standard HTTPS connections relayed as opaque Connect tunnels are not affected. While that reduces the overall attack surface, sensitive credentials can still travel in cleartext HTTP in many enterprise and legacy environments.

The vulnerability was discovered with the aid of Anthropic’s Claude Mythos AI model.

A patch was merged into Squid version 8 in April 2026 and shipped in version 7.6 in June 2026. The risk can be mitigated by disabling FTP support entirely if it’s not needed.

Calif researchers also recently found a high-severity vulnerability in OpenSSL and a DoS attack technique called HTTP/2 Bomb, which allows an attacker to quickly knock web servers offline. Both vulnerabilities were discovered using AI. 

Related: Attackers Exploit Gravity SMTP Plugin Flaw to Harvest Valuable WordPress Data

Related: Splunk Enterprise Vulnerability Exploited in Attacks Days After Disclosure

Related: Majority of Internet-Accessible REDCap Servers Outdated

https://www.securityweek.com/decades-old-squid-proxy-flaw-squidbleed-can-expose-user-data/




Attackers Exploit Gravity SMTP Plugin Flaw to Harvest Valuable WordPress Data

Threat actors are exploiting a medium-severity vulnerability in the Gravity SMTP WordPress plugin to steal complete system details, Defiant warns.

Gravity SMTP for WordPress is an email deliverability plugin that integrates with multiple SMTP providers and API-based services to allow admins to send and track emails directly from their websites.

All plugin iterations before version 2.1.5 are affected by a sensitive information exposure vulnerability tracked as CVE-2026-4020 (CVSS score of 5.3) that has been exploited in the wild since early May.

The issue impacts a REST API endpoint that unconditionally returns true, thus becoming accessible to any unauthenticated user. If a specific parameter is appended to a query, the endpoint returns internal connector data in JSON format.

The data contains the full system report, including configuration data such as PHP and WordPress version, loaded extensions, web server details, document root path, database details, active plugins and theme, WordPress configuration details, and configured API keys/tokens.

According to Defiant, the bug exists because the impacted REST API endpoint, registered within a shared library providing a configuration collection system, does not perform authentication or capability checks.

Advertisement. Scroll to continue reading.

“This makes it possible for unauthenticated attackers to harvest credentials that could be used to send email on behalf of the site, as well as to gather detailed reconnaissance about the site’s software stack that can be leveraged to identify and target other vulnerabilities,” Defiant explains.

The WordPress security firm has observed in-the-wild exploitation of the security defect since early May. Attackers have been sending unauthenticated GET requests to the vulnerable endpoint to retrieve the full System Report JSON object.

In June, Defiant has observed a surge in attacks targeting CVE-2026-4020. To date, the company has blocked over 17 million exploit attempts.

Site owners and administrators are advised to update their Gravity SMTP deployments to version 2.1.5 as soon as possible and to check server access logs for requests to the affected endpoint, as the in-the-wild exploitation does not leave other obvious traces.

“If you are running a vulnerable version of Gravity SMTP and have configured any third-party email integrations (such as Amazon SES, Google, Mailjet, Resend, or Zoho), you should assume the associated API keys, secrets, and OAuth tokens may have been exposed. We strongly recommend rotating these credentials after updating the plugin,” Defiant notes.

Related: Majority of Internet-Accessible REDCap Servers Outdated

Related: 15,000 WordPress Websites Cleaned Up in SocGholish Botnet Takedown

Related: Joomla, LiteSpeed Vulnerabilities Exploited in Attacks

Related: No Exploits Required

https://www.securityweek.com/attackers-exploit-gravity-smtp-plugin-flaw-to-harvest-valuable-wordpress-data/