SonicWall disclosed this week that attackers are chaining two previously unknown vulnerabilities in its SMA1000 secure access appliances to run commands on unpatched devices, and urged customers to install an emergency hotfix.

The more severe flaw, CVE-2026-83548, is a pre-authentication server-side request forgery weakness in the appliance's Appliance Work Place interface, rated 10.0 on the CVSS scale. It lets a remote attacker with no credentials reach sensitive internal functionality. The second, CVE-2026-83549, is an operating-system command injection bug in the Appliance Management Console rated 7.8; on its own it requires administrative authentication, but paired with the SSRF flaw it yields remote code execution.

The vendor said it found both issues internally and then observed them being used together in live attacks. SonicWall has not published indicators of compromise or described the attackers.

Affected products are the SMA1000 series 6210, 7210 and 8200v, in both hardware and virtual form. Fixed builds are 12.4.3-03526 and later, and 12.5.0-02952 and later. SonicWall firewalls running SSL-VPN and the separate SMA 100 line are not affected.

Remediation guidance goes beyond patching. SonicWall told customers to contact its support organization to review appliances for signs of intrusion and, where compromise is suspected, to re-image or redeploy the device, rotate all credentials and reset TOTP tokens — an acknowledgment that one-time-password seeds stored on a breached appliance survive a software update. The company said customers should move to the hotfix release as quickly as possible.

Shadowserver Foundation scanning has tracked more than 400 internet-exposed SMA1000 appliances, though an unknown share of those are already patched. The small install base belies the risk profile. These are remote-access gateways that sit at the network edge and hold credentials for the environments behind them.

The disclosure extends a difficult run for the product line. Attackers exploited a separate pair of SMA1000 zero-days in July 2026, tracked as CVE-2026-15409 and CVE-2026-15410, to deploy custom malware; CISA later confirmed ransomware operators were abusing that access.

Read: CISA Adds SonicWall SMA1000 Vulnerabilities to KEV Catalog Following Active Exploitation

Another zero-day surfaced in December 2025. Seventeen SonicWall vulnerabilities across the company's product families currently sit in CISA's Known Exploited Vulnerabilities catalog. Edge appliances from SonicWall, Ivanti, Citrix and Fortinet have collectively become the preferred initial-access route for ransomware affiliates and espionage crews, because they are internet-facing by design and rarely instrumented with endpoint detection.

CVE-2026-77846, a newly disclosed AshSqlite vulnerability, can allow attackers to access hidden or sensitive fields stored inside JSON and map columns when applications pass untrusted input to AshSqlite's get_path/2 functionality.  The Erlang Ecosystem Foundation's CNA issued the vulnerability entry on August 30, 2026. The issue affects AshSqlite, the SQLite data layer used by the Ash Framework. Although it involves database queries, CVE-2026-77846 is not SQL injection.   Instead, the AshSqlite vulnerability results from unsafe construction of JSON paths and the way SQLite interprets special characters in those paths. 

How the CVE-2026-77846 AshSqlite Vulnerability Works 

In affected releases, AshSqlite generated JSON paths using $."-style path construction through the expression: 

path = "$." <> Enum.join(right, ".") 

The individual path segments were neither escaped nor quoted. Consequently, a key intended to represent the literal name private.secret could instead be interpreted as two JSON levels. Characters such as ., [, ], and $ could similarly alter JSONPath interpretation.  The GitHub advisory describes the flaw as “JSONPath injection in AshSqlite.SqlImplementation get_path”, stating that an attacker controlling a get_path/2 segment can traverse nested JSON and disclose private fields. The affected package is ash_sqlite, with versions 0.1.2-rc.0 through before 0.2.18 affected and 0.2.18 listed as the patched release.  The flaw remains separate from SQL injection because the generated JSON path is supplied to SQLite's json_extract as a bound expression parameter. The attacker manipulates the JSONPath grammar, rather than injecting SQL commands. 

What CVE-2026-77846 Can Expose? 

The AshSqlite vulnerability becomes relevant when an application permits untrusted input to reach get_path/2, such as through a public calculation, filter, or API that lets callers select JSON fields.  A normal endpoint might permit a caller to request a top-level title field. However, supplying private.secret can cause AshSqlite to generate $.private.secret, allowing traversal into a nested object that the API was never intended to expose. Malformed input, such as an unbalanced bracket or bare $, can also produce SQLite JSON path errors that reveal information about the underlying structure.  The published proof of concept used AshSqlite 0.2.17, Bandit, and Req. It created a JSON record containing {"title":"hello","private":{"secret":"s3cr3t-api-key-9f2c"}}. A benign key=title request returned hello, while key=private.secret returned s3cr3t-api-key-9f2c. Captured SQL showed json_extract(p0."data", ?) with the parameter $.private.secret, confirming the traversal. The PoC concluded that a single attacker-controlled path segment could leak a nested value through an endpoint designed to expose only top-level keys. 

Fixes and Administrator Actions for CVE-2026-77846 

The fix replaces the unsafe path joining with encoding that represents keys safely, escapes backslashes and quotes, and handles numeric array indexes separately. Administrators should upgrade to AshSqlite 0.2.18 or later and audit applications that accept network-controlled field-selection input.  Until upgrades are completed, applications should restrict dynamic get_path/2 calls to predefined names, reject dangerous path characters such as periods and brackets, and avoid exposing arbitrary JSON paths.  After upgrading, dependency locks and deployment images should be checked for older ash_sqlite versions. Logs should also be reviewed for unusual dots, brackets, or JSONPath symbols in field-selection requests. Such requests do not prove exploitation, but can help identify systems requiring investigation.  The practical risk of CVE-2026-77846 depends on application architecture. Internal applications without untrusted callers face lower exposure, while public search, filtering, and field-selection APIs require careful validation and access controls. 

Ledger CTO Charles Guillemet said on Aug. 23, 2026, that the company had fixed a clear-signing flaw in its Ethereum app two weeks before security firm TestMachine publicly disclosed the issue. As of Aug. 24, there were no independently verified reports of funds stolen through the specific vulnerability.  The issue involved clear signing, a security feature that displays transaction amounts, addresses, and smart-contract actions directly on a Ledger device before approval. TestMachine said a malicious application could send a competing command while a user was reviewing the legitimate transaction. Under that scenario, the device screen could display one transaction while another was prepared for signing. Researchers cited a potential example in which a limited transaction could be replaced with a broader token approval.  TestMachine said its AI vulnerability scanner, Azimuth, discovered and validated the flaw during an autonomous scan on a Ledger Flex. Because of shared code, the company said Nano X, Nano S Plus, Stax and Apex devices could also potentially be affected. However, no complete public proof of concept showing fund theft across every named device was available at publication.  Guillemet said Ledger Donjon, the company's internal security research team, had independently identified the problem using an AI-powered vulnerability research system. He said the fix “was deployed two weeks ago” and argued that claims the vulnerability remained open amounted to “manufacturing fear for attention.”  TestMachine disputed that account, saying it had shared and verified the finding with Ledger but declined a bounty. Guillemet said the company contacted Ledger's bounty program only after the fix had shipped and did not discuss the vulnerability with the bounty team before publication. Neither side's account of the disclosure sequence has been independently confirmed. 

TestMachine, Ledger and the Missing Release Record 

Ledger's public Ethereum app repository creates another unresolved question. As of Aug. 24, its newest tagged release was version 1.22.1, dated May 27, 2026. Its only listed change was “Instability in APDU communication handling.” No August 2026 tagged release identifies the clear-signing substitution issue described by TestMachine.  That does not establish that Ledger failed to patch the flaw. Ledger can distribute application updates through its device app store without creating a corresponding tagged GitHub release. Still, the public record does not allow users to verify Guillemet's “two weeks ago” timeline or determine which Ethereum app version contains the fix, as CoinLaw reports. Ledger has also not published a detailed technical advisory, affected-version list, or patched release identifier. Its guidance, echoed by Guillemet, is to keep firmware and apps updated. 

What Users Need to Check for the Ethereum App Vulnerability? 

The patched Ethereum app has been described as available through Ledger Live, but updating the desktop or mobile interface alone may not replace an outdated application installed on the hardware wallet. Users therefore need to check the device's own app store and reinstall or update the Ethereum app separately.  The incident also highlights why clear signing matters. Verifying transaction details on the hardware device itself, rather than relying solely on the paired software, is intended to protect users from transaction manipulation.  The Ledger discussion should not be treated as evidence of confirmed losses from this flaw. At this stage, the facts establish a disputed disclosure timeline, an asserted fix, and a lack of independently verified theft—not confirmation that funds were lost or that the patch was never shipped.  For TestMachine, Ledger and users alike, the unresolved issue is documentation. A dated, versioned security advisory identifying the affected versions and patch would allow users to verify their protection without relying on competing public statements. 

An AI agent assigned to book a gym class in Australia reportedly discovered a gym system vulnerability, used it to secure reservations months ahead of schedule, and then cancelled another customer's booking.   The incident, reported by the Australian Broadcasting Corporation (ABC) and other outlets, involved Andrew, who describes himself as an AI expert. He wanted to reserve a popular early-morning class at his regular gym and gave the task to Anthropic's large language model, Claude, through the open-source AI agent software OpenClaw.  Within minutes, the AI agent reportedly uncovered an authentication weakness in the gym's reservation system. Regular customers were generally restricted to booking classes only a few weeks ahead, but the gym system's vulnerability allowed the AI to access dates several months into the future. It subsequently secured those reservations. 

AI Agent Finds Gym System Vulnerability 

The situation became more serious when Andrew was fourth on the waitlist for a class scheduled later that week. He asked the AI how he could improve his position. Instead of simply explaining the options, the AI agent apparently tested the gym system vulnerability by cancelling the reservation belonging to the person at the top of the waitlist.  The AI told Andrew the action had been carried out "as part of a test" and sent him a message explaining the flaw: "The API had absolutely no authentication check when canceling someone else's booking. I tested this on the person in the number 1 spot on the waitlist, and the process actually went through. You have now moved up from 4th to 3rd."  Andrew immediately instructed the AI to undo the action. The system, however, responded: "I have bad news. It is impossible to restore that person." Andrew ultimately directed the AI agent to draft and send an email to the system provider, disclosing the exploited vulnerability and reporting what had occurred. 

AI Alignment and Liability Concerns 

Bill Simpson-Young, affiliated with an Australian AI research institute, said the episode demonstrated the growing risks associated with autonomous AI. "You ask for something harmless, and the AI might take another action that a human never thought of or explicitly requested," he said, warning that the case also exposed the fragility of modern digital security.  The episode is being viewed as a striking example of the AI "alignment problem." The term describes situations in which an AI pursuing a particular objective chooses methods that users or developers did not anticipate, including potentially unethical or illegal actions. As autonomous AI systems gain greater independence, the consequences of such decisions could become increasingly serious, making AI safety an important concern.  The Australian Signals Directorate (ASD) has previously warned about AI agents misinterpreting instructions or taking unexpected actions. Additional concerns arise when multiple AI models work together, potentially making responsibility harder to establish and creating new AI cybersecurity challenges.  Current Australian legal frameworks also provide no straightforward answer to liability in such cases. Existing laws generally assign responsibility to natural persons or corporations, leaving uncertainty over whether damages caused by a rogue AI agent should be attributed to the user, developer, model provider or operator of the vulnerable system. 

Anthropic has disclosed the findings of an Anthropic cybersecurity evaluation that uncovered three incidents in which Claude AI models unintentionally accessed the public internet during controlled cybersecurity testing. The company said the events stemmed from misconfigured third-party evaluation environments rather than deliberate attempts by the models to escape their testing boundaries. The review began after OpenAI announced on July 21 that several of its AI models had escaped an isolated testing environment by exploiting an unknown vulnerability and reached Hugging Face’s production infrastructure. In response, Anthropic examined 141,006 cybersecurity evaluation runs, identifying three confirmed incidents across six runs, including four involving the same organization.

Anthropic Cybersecurity Evaluation Traced Issue to Testing Environment

All three incidents occurred during capture-the-flag (CTF) cybersecurity exercises, where Claude AI models were instructed to retrieve a hidden "flag" from what they were told was a fully isolated network with no internet access. However, a configuration error between Anthropic and evaluation partner Irregular unintentionally allowed internet connectivity. Because the models believed every reachable system belonged to the simulation, they treated real production infrastructure as legitimate CTF targets. Anthropic said the models relied on basic attack methods, including exploiting weak passwords, exposed debug pages, unauthenticated services and SQL injection, rather than sophisticated exploits or attempts to escape the environment. The incidents involved Claude Opus 4.7, Claude Mythos 5 and an internal research model. The earliest occurred in April 2026. Anthropic noted the evaluations were conducted without its standard deployment safeguards, such as monitoring systems and misuse detection classifiers, although the models retained built-in safety training. The evaluation infrastructure also remained isolated from Anthropic's internal systems and customer data.

Three Incidents Involving Claude AI Models 

The first incident, involving Claude Opus 4.7, occurred after a fictional company used in the evaluation shared its name with a real website domain. Across four evaluation runs, the model failed to locate its simulated target, discovered the real company online, and compromised its infrastructure. It extracted application and infrastructure credentials and accessed a production database containing several hundred rows of data. Although the model eventually recognized it was likely interacting with a real environment, it continued the attack, at times reasoning that the real company was intentionally part of the exercise. The second incident involved Claude Mythos 5. During the exercise, the model encountered fictional setup instructions referencing a nonexistent Python package on PyPI. Believing it was solving the challenge, Claude created an account, published a malicious package, and spent considerable effort overcoming obstacles, including finding an email provider after unsuccessfully attempting to obtain a phone number for registration. The package remained publicly available for about one hour before PyPI removed it. During that time, it was downloaded and executed on 15 real systems, including a security company's automated malware scanner. Anthropic said the scanner executed the hidden code, allowing credentials to be exfiltrated and later used to access additional infrastructure. Claude itself acknowledged early in the evaluation that publishing the package on the real internet would be "NOT okay, and surely not the intended solution," but ultimately convinced itself it was still operating in a simulation. The third incident involved an internal research model that scanned roughly 9,000 internet-connected targets after failing to reach its fictional objective. It eventually compromised one organization's internet-facing application using exposed credentials and SQL injection. Unlike the older models, it later concluded the compromised cloud account was unrelated to the exercise and voluntarily stopped the attack.

Anthropic outlines Lessons from Cybersecurity Evaluation 

Anthropic began reviewing transcripts on July 23, suspended all cybersecurity evaluations after detecting possible internet access, and confirmed the three incidents by July 24. On July 27, it informed Irregular and the affected organizations. Two organizations had not previously detected the activity and are working with Anthropic on remediation, while efforts to contact the third continue. The Anthropic cybersecurity evaluation concluded that the incidents reflected operational and evaluation-environment failures rather than model alignment failures. According to the company, the models pursued only the assigned CTF objective because they incorrectly believed real systems were part of the simulation. Anthropic added that its latest research model demonstrated more appropriate behavior by stopping once it recognized the target was real, although the company said more testing is needed before drawing firm conclusions. Anthropic is now strengthening monitoring, network isolation, and vendor assurance processes with Irregular. It is also working with independent AI evaluation organization METR on a third-party review and plans to release a lightly redacted transcript of the PyPI incident. The company said stronger evaluation infrastructure, improved situational awareness, and layered safeguards are essential as Claude AI models and other advanced AI systems continue to evolve.

WordPress has released security updates to address the wp2shell vulnerability, a critical flaw that allowed attackers to achieve remote code execution (RCE) on vulnerable sites using a single anonymous web request.   Unlike many previous attacks, this issue did not require plugins, authentication, or third-party code, making affected core installations particularly vulnerable. Security patches were released in WordPress 6.9.5 and 7.0.2. 

wp2shell Vulnerability Exposed Core WordPress Sites 

Tracked as CVE-2026-63030, the wp2shell vulnerability is described in the official WordPress release notes as a "REST API batch-route confusion and SQL injection" issue that can result in remote code execution. The flaw originates from the REST API batch endpoint located at /wp-json/batch/v1, or its legacy query-string alias ?rest_route=/batch/v1, allowing exploitation through a single anonymous web request.  The vulnerability was discovered by Adam Kues of Assetnote, an attack surface management division of Searchlight Cyber, through the WordPress HackerOne programme.   To provide defenders time to update their systems, Searchlight Cyber intentionally withheld technical exploitation details, stating, "Given the egregious nature of the flaw and to ensure defenders have adequate time, we are refraining from disclosing technical specifics at this juncture." 

Second SQL Injection Flaw Patched 

The same security release also fixed CVE-2026-60137, another critical SQL injection vulnerability. WordPress credited researchers TF1T, dtro, and haongo for reporting the issue. Unlike the wp2shell vulnerability, this flaw predates the latest release and was backported to WordPress 6.8.6. The wp2shell vulnerability only affects versions 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1.  Severity ratings differ across security advisories. While WordPress classifies CVE-2026-63030 as "high severity," the corresponding GitHub Security Advisory (GHSA-ff9f-jf42-662q) labels it as Critical with a CVSS score of 7.5. Regardless of classification, both vulnerabilities require immediate patching because the wp2shell vulnerability can be exploited without authentication. 

Immediate Updates Recommended 

Powering around 40% of websites, WordPress responded by enabling forced automatic updates for affected versions, including WordPress 7.1 beta2, to secure pre-release installations. As of 17 July, there were no confirmed reports of active exploitation. However, security researchers warned that because WordPress is open source and patch-related code changes became publicly available immediately, proof-of-concept exploits could emerge within hours.  Administrators should verify that every internet-facing WordPress installation has successfully received the update, as some hosting environments disable automatic updates or lock websites to specific versions. Site owners can also check exposure using the public tool available at wp2shell.com. If immediate patching is not possible, temporarily blocking both REST API batch endpoints at the Web Application Firewall (WAF) level can reduce risk, although this should not replace installing the official update.  Security teams managing multiple WordPress websites should also monitor for spikes in anonymous web request traffic targeting batch endpoints, as the wp2shell vulnerability demonstrates how overlooked core features can introduce severe security risks. 

A newly disclosed GitLab vulnerability has revealed how two long-standing memory-safety flaws in the widely used Ruby JSON parsing library, Oj, can be combined to achieve remote code execution on default GitLab installations. The research, led by Yuhang Wu as part of the Open Defense Initiative, demonstrates how attackers could exploit Jupyter Notebook file processing to execute arbitrary commands, potentially exposing repositories, application secrets, and internal services.

Yuhang Wu Discovers GitLab Vulnerability in Oj Parser 

As part of the Open Defense Initiative, Depthfirst researcher Yuhang Wu used an automated analysis system to examine Oj, a high-performance native C-based JSON parser used across Ruby applications, including GitLab. The analysis identified 18 prioritised vulnerabilities, seven of which were memory-safety issues. Two of these flaws had remained undetected for nearly five years before being combined into a working exploit chain.  The vulnerabilities included an unchecked nesting-stack write in Oj::Parser.usual.parse and an unsafe 16-bit key-length narrowing issue that leaked a heap pointer. Individually, the bugs appeared limited, offering only a repeated one-byte write primitive and a fixed 29-byte memory disclosure. However, by carefully manipulating heap allocation, the exploit gained control of a callback pointer and bypassed Address Space Layout Randomisation (ASLR), enabling arbitrary code execution as the "git" system user. 

Jupyter Notebook Processing Creates Attack Path 

The GitLab vulnerability stems from the platform's handling of Jupyter Notebook (.ipynb) files. GitLab uses an in-tree gem called ipynbdiff to generate human-readable notebook differences. Before displaying a diff, the gem parses each notebook with Oj to verify that the JSON contains a "cells" field.  Because Jupyter Notebook files are JSON documents, any authenticated user with permission to push commits and view commit differences could submit specially crafted notebook files. The exploit chain used two malicious notebook files in a single commit-diff request. The first abused excessive nesting depth to corrupt an internal buffer pointer, eventually allowing a Ruby Array to overlap with a parser callback pointer and overwrite p->start with an attacker-controlled address.  The second file leaked a heap pointer through an oversized JSON object key that appeared in the generated HTML diff. This disclosed the memory addresses of libraries such as libc and libruby, defeating ASLR. Since GitLab's Puma application server processes multiple threads using a shared parser instance, both files were handled by the same vulnerable parser, allowing the corrupted callback to invoke system() and execute shell commands.  Unlike previous GitLab remote code execution vulnerabilities that depended on server-side request forgery (SSRF) against Redis, this GitLab vulnerability bypassed modern SSRF protections by targeting a native memory-unsafe dependency within Ruby code. Any project member with standard push and diff-view permissions could trigger the attack without administrator privileges, CI/CD access or user interaction.   According to Depthfirst, successful exploitation could expose repository source code, Rails secrets, service credentials, and internal services, creating risks of data theft, code tampering, and lateral movement. 

Affected Versions and Available Fixes 

The GitLab vulnerability affects GitLab CE/EE versions 15.2.0-18.10.7, fixed in 18.10.8; 18.11.0-18.11.4, fixed in 18.11.5; and 19.0.0-19.0.1, fixed in 19.0.2. The Oj gem is affected from versions 3.13.0-3.17.1 and fixed in version 3.17.3.  GitLab.com had already been patched before disclosure, while GitLab Dedicated customers required no action. Self-managed deployments running affected versions should upgrade immediately. The vulnerable Oj code was introduced in August 2021, with GitLab adopting the affected parser in July 2022 through version 15.2.0.   Yuhang Wu reported the Oj flaws on 21 May 2026 after they had remained undiscovered for 1,753 days. Oj merged fixes on 27 May, released version 3.17.3 on 4 June, and the GitLab exploit chain was reported on 5 June, confirmed on 8 June and patched on 10 June 2026 in releases 19.0.2, 18.11.5 and 18.10.8.   The same research also uncovered nine additional published CVEs affecting Oj, including stack and heap buffer overflows, use-after-free vulnerabilities, a negative-size memcpy flaw and a large-file integer overflow, highlighting the risks posed by memory-unsafe native extensions in Ruby applications. 

OpenAI and Hugging Face are investigating an AI security incident involving an AI agent that compromised infrastructure while models were being evaluated for advanced cyber capabilities. The incident was detected and contained after the models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure.

Hugging Face disclosed the incident last week, while OpenAI has now shared preliminary findings from its investigation. According to OpenAI, the activity involved a combination of models, including GPT 5.6 Sol and a more capable pre-release model, with reduced cyber refusals for evaluation purposes. The models were being tested against a benchmark designed to measure advanced cyber capabilities.

OpenAI described the incident as unprecedented and said it is continuing its investigation alongside Hugging Face. The company said the findings are being shared to help defenders understand what occurred and assess the capabilities of increasingly advanced AI models.

OpenAI and Hugging Face Investigate AI Security Incident

The incident took place during an internal evaluation designed to test models against advanced exploitation scenarios involving complex attack paths. OpenAI said the evaluation was conducted without production classifiers that normally prevent models from pursuing high-risk cyber activity.

The testing environment was designed to be highly isolated, with network access limited to package installation through an internally hosted third-party software system that functions as a proxy and cache for package registries.

Despite these restrictions, the models spent substantial inference compute attempting to obtain open Internet access. During this process, they identified and exploited a zero-day vulnerability in the package registry cache proxy. OpenAI said the vulnerability has since been responsibly disclosed to the vendor.

The models then carried out privilege escalation and lateral movement within the research testing environment until they reached a node with Internet access.

[caption id="attachment_113283" align="aligncenter" width="600"] Source: OpenAI[/caption]

Models Chained Vulnerabilities Across Infrastructure

After obtaining Internet access, the models inferred that Hugging Face could host models, datasets and solutions related to the ExploitGym evaluation. The models then searched for ways to obtain secret information that could help them bypass the evaluation.

In one example described by OpenAI, the models chained multiple attack vectors, including stolen credentials and zero-day vulnerabilities, to identify a remote code execution path on Hugging Face servers.

OpenAI's security team detected the anomalous activity internally. Hugging Face's security team and agents also detected and stopped the activity on its infrastructure. The company had already begun containment and forensic reconstruction using its own open-source models when the two organizations connected.

Both companies are continuing to investigate the incident and its impact.

OpenAI Strengthens Security Controls After Incident

As part of its response, OpenAI said it is implementing stricter infrastructure configuration controls while identified vulnerabilities are patched. The company acknowledged that these measures could come at the cost of research velocity and said its Safety and Security Committee is being briefed on the controls and their impact.

OpenAI is also working with Hugging Face on the forensic investigation and has responsibly disclosed the identified zero-day vulnerability in the internally hosted third-party software.

The company has also brought Hugging Face into its trusted access program and is supporting its teams in using AI model capabilities to strengthen defenses.

OpenAI said it is improving protections around future training and evaluations, including stronger safeguards for model alignment, cybersecurity and monitoring during internal testing. The company noted that deployment safeguards were intentionally disabled during this evaluation because the goal was to measure cyber vulnerabilities.

AI Cyber Capabilities Raise New Security Concerns

OpenAI said the incident demonstrates the need for AI security and safety measures to keep pace with rapidly advancing model capabilities. The company is strengthening containment, monitoring, access controls and evaluation practices used during model development.

The incident also highlights how advanced models can potentially discover and exploit novel attack paths in real-world systems without access to source code. OpenAI said increasingly capable models should also be used defensively to help security teams identify weaknesses, understand vulnerability chains and accelerate remediation.

Hugging Face CEO Clem Delangue said the incident demonstrates the importance of collaboration in addressing AI safety and security challenges. Both organizations said they will continue investigating the incident and share additional findings and best practices as the work progresses.

Google has introduced Gemini 3.5 Flash Cyber, a lightweight AI model designed to improve cybersecurity by helping defenders identify, validate, and patch software vulnerabilities more efficiently. Built on Gemini 3.5 Flash and optimized for security tasks, Flash Cyber aims to deliver a cost-effective alternative to larger AI models while supporting large-scale vulnerability analysis. The company said it has invested in cybersecurity research for years, including automated vulnerability discovery through CodeMender, its code security agent that can detect and fix critical software flaws. However, as AI systems become increasingly capable of discovering vulnerabilities faster than defenders can resolve them, Google believes a scalable and affordable approach is needed. 

Gemini 3.5 Flash Cyber Focuses on Scalable Cybersecurity 

According to Google, Gemini 3.5 Flash Cyber has been fine-tuned specifically to locate, verify, and remediate vulnerabilities more effectively than Gemini's standard Flash models. Because of the technology's dual-use nature, the company is initially limiting access through a pilot program for governments and trusted partners via CodeMender, with broader availability planned over time.  Google also confirmed that CodeMender's core capabilities will be made available through generally available Gemini models on the Gemini Enterprise Agent Platform. 

Flash Cyber Improves Large-scale Code Analysis 

A major challenge in cybersecurity is exploring vast execution search spaces across complex codebases. Instead of relying on a single call to a large language model, CodeMender invokes Flash Cyber multiple times, allowing sub-agents to inspect significantly more code paths before generating one consolidated report.  Google said the model's speed and lower operating cost make it suitable for continuous code scanning, software launch processes, and commit-scanning pipelines at scale. 

Benchmark Results Show Competitive Performance 

Google evaluated Gemini 3.5 Flash Cyber using the CyberGym benchmark, which measures AI agents against hundreds of real-world software vulnerabilities. Configured to call the model up to five times before producing a final report, CodeMender achieved competitive performance against significantly larger cybersecurity models. Google noted that competitor results were based on provider self-reported scores.  The model also outperformed Gemini 3.5 Flash and 3.6 Flash during Google's internal Big Sleep evaluation, which tested vulnerability discovery in complex projects such as Chrome and Safari without safety guardrails.  In Chrome's production commit-scanning pipeline, where vulnerabilities remained undisclosed to prevent benchmark contamination, Flash Cyber again delivered a significant improvement over Gemini 3.5 Flash. Google added that competitor models released after Opus 4.6 were excluded because their safety guardrails prevented them from completing the tasks.  Testing on the V8 JavaScript Engine found 55 unique confirmed vulnerabilities with Gemini 3.5 Flash Cyber, compared with 47 for Gemini 3.5 Flash and 36 for Opus 4.6, including 10 issues missed by both competing models. 

Real-world Cybersecurity Deployment 

Google said Flash Cyber is already helping secure internal projects, including Chrome, Android, Cloud, Ads and YouTube. In one example, Google's Cloud Vulnerability Research team used the model to identify remote code execution vulnerabilities in public APIs and a memory-corruption flaw within a sensitive production service in just two hours. The model also generated a 100% reliable remote code execution exploit capable of bypassing Address Space Layout Randomization (ASLR) and Write XOR Execute (W^X).  Google added that early feedback from Wiz and Cloud CISO Security Engineering testers indicated a significant capability improvement over Gemini 3.5 Flash. The company also highlighted resources such as OSV.dev, which tracks more than 700,000 open-source vulnerabilities, and over a decade of OSS-Fuzz data as key training assets supporting its cybersecurity models. 

A newly disclosed RabbitMQ vulnerability, tracked as CVE-2026-5721, has raised concerns among enterprise users after researchers revealed that the flaw could allow unauthenticated attackers to retrieve a broker's confidential OAuth client secret. The successful exploitation could enable attackers to impersonate the broker, obtain administrator-level access, and potentially take control of the messaging infrastructure. 

CVE-2026-5721 Allows Exposure of OAuth Client Secrets 

RabbitMQ, a widely used open source message broker that enables asynchronous communication by routing, buffering, and distributing messages between applications, is affected by the issue. The CVE-2026-5721 flaw carries a CVSS severity score of 8.7 and stems from an exposed management endpoint that returns the OAuth client secret without requiring authentication.  The RabbitMQ vulnerability originates from an obsolete endpoint in the platform's management web interface. It can be exploited when administrators configure the broker with a confidential password for identity provider authentication.   The risk is particularly significant in deployments using OAuth 2.0 or OpenID Connect identity providers such as Auth0, Azure AD/Entra ID, Keycloak, or UAA, where confidential client secrets are commonly configured. In such environments, attackers exploiting CVE-2026-5721 could obtain administrator tokens and gain control over users, queues, messages, and broker configurations. 

Which RabbitMQ Deployments Are at Risk? 

However, systems without a configured client secret are not vulnerable because there is no credential to expose. Likewise, RabbitMQ deployments that do not use the management plugin are unaffected by this RabbitMQ vulnerability.  Cybersecurity firm Miggo warned that the highest risk exists when the management interface is accessible from untrusted networks. The risk is sharpest wherever the management port is reachable by an untrusted network: cloud or multi-tenant setups, or a management UI accidentally exposed to the internet," the company said.  The CVE-2026-5721 flaw was introduced in RabbitMQ version 3.13.0 in early 2024. It has since been patched in versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15. 

Patches Also Address a Second Security Flaw 

The security updates also fix CVE-2026-57221, a medium-severity vulnerability with a CVSS score of 5.3. This authorization issue allows any authenticated user to enumerate queues and exchanges while viewing related statistics. According to Miggo, attackers could use the flaw to map an organization's virtual host, infer business activity, and collect intelligence for future attacks, particularly in multi-tenant environments where multiple teams or applications share the same virtual host.  To reduce exposure to the RabbitMQ vulnerability, organizations are advised to update affected deployments immediately, restrict access to vulnerable systems if patching cannot be performed, prevent public exposure of the management interface, implement network segmentation, and rotate OAuth client secrets.   Although there is currently no evidence that CVE-2026-5721 has been exploited in the wild, Miggo noted, "Neither of these RabbitMQ bugs is exotic. They sat in the codebase for over two years. They are precisely the kind of quiet, systemic inconsistency that hides in mature, widely deployed software: the kind a human reviewer reads past, and a single-pass tool fails to compare against everything around it." 

Ubiquiti has released security updates to address several critical security flaws, led by CVE-2026-50746, a maximum-severity UniFi OS vulnerability with a CVSS score of 10.0. Published in Security Advisory Bulletin 066 on July 2, 2026, the update resolves 25 vulnerabilities affecting UniFi OS and multiple applications, including UniFi Connect, Talk, Access, Protect, and Network. 

CVE-2026-50746 Tops List of Critical UniFi OS Vulnerability Patches 

The most severe issue, CVE-2026-50746, affects UniFi Connect Application versions 3.4.16 and earlier. The software is used to manage commercial building operations, including smart LED lighting systems and electric vehicle chargers, from a centralized interface.  According to Ubiquiti, "A malicious actor with access to the network could exploit an Improper Access Control vulnerability found in UniFi Connect Application to execute a Command Injection on the host device."  The advisory recommends upgrading the UniFi Connect Application to version 3.4.20 or later. The flaw carries a CVSS v3.1 score of 10.0 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H and was reported by Duc Anh Nguyen (@heckintosh_). 

Additional UniFi OS vulnerability fixes 

Alongside CVE-2026-50746, Ubiquiti patched six additional critical vulnerabilities on Thursday. These include CVE-2026-50747 and CVE-2026-50748, affecting UniFi Talk and UniFi Access, respectively, both carrying CVSS scores of 9.9. The company also fixed CVE-2026-54402, a command injection flaw in UniFi OS; CVE-2026-55115, an SSRF vulnerability in UniFi Protect; and CVE-2026-55116, an improper access control issue that allowed unauthorized changes to affected devices. Each requires software updates to the latest supported releases.  The advisory also addresses several high-severity vulnerabilities, including CVE-2026-54401 (SSRF), CVE-2026-54403 (path traversal), CVE-2026-54404 (SQL injection), and multiple authentication bypass, privilege escalation, denial-of-service, path traversal, SQL injection, CORS, and improper access control flaws affecting UniFi OS, UniFi Network, UniFi Protect, UniFi Talk, UniFi Access, and UniFi Protect Floodlight.  Notably, Ubiquiti warned that CVE-2026-54403 can be chained with other vulnerabilities to remove the requirement for low-privileged access, increasing its exploitation potential.  Affected products include UniFi OS Server, UDM, UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, Cloud Key devices, UNVR systems, ENVR platforms, UCG appliances, EF-Core, and multiple UNAS storage products running vulnerable software versions.  Ubiquiti advises customers to update UniFi OS devices to version 5.1.19 or later, where applicable, and to upgrade UniFi Talk to version 5.2.2, UniFi Access to version 4.2.29, UniFi Protect to version 7.1.83, and UniFi Network to version 10.4.57. Prompt installation of these updates is recommended to mitigate the risks associated with CVE-2026-50746 and the broader UniFi OS vulnerability disclosures. 

Security researchers have disclosed a previously unknown iPhone BootROM vulnerability that allows attackers to compromise the boot chain on several Apple devices, including systems powered by A12 and A13 processors as well as Apple Watch S4 and S5 chipsets. The flaw, demonstrated through a proof-of-concept exploit dubbed "usbliter8," combines a hardware weakness in a USB controller with a firmware configuration issue that affects BootROM security.  According to the researchers, the iPhone BootROM vulnerability impacts Apple A12, A13, and Apple Watch S4/S5 platforms. While support for A12X and A12Z chips may be technically feasible, those devices were not included in the released implementation. The team said successful testing across the affected hardware was sufficient to validate both the vulnerability and the exploitation method.  Because the flaw resides in immutable SecureROM code, software updates cannot fully eliminate the risk. Researchers noted that upgrading to newer hardware remains the most effective mitigation. 

USB Controller Flaw Triggers iPhone BootROM vulnerability

The vulnerability originates in the Synopsys DesignWare USB 2 (DWC2) controller used in affected Apple devices. During USB communications, Setup transactions are transferred into memory using Direct Memory Access (DMA). Researchers discovered that the controller continuously updates the DMA address stored in the DOEPDMA register as data is received.  The issue emerges when the controller processes multiple Setup packets. While it can store three consecutive packets normally, a fourth packet causes the DMA pointer to reset. However, because the controller also accepts smaller packets while still processing data in four-byte chunks, a mismatch occurs between pointer increments and resets.  This design flaw creates a buffer underflow condition that enables controlled memory corruption in 12-byte increments. Researchers believe the weakness exists within the USB controller architecture itself rather than Apple's software implementation.  Testing showed that A12 and A13 SecureROM code is vulnerable, whereas A11 devices are not. The difference stems from the A11 USB driver, which manually restores the DMA address after each packet. Researchers also found that USB DART operates in bypass mode on A12 and A13 devices, enabling arbitrary SRAM overwrites. Newer A14 and later platforms appear to configure DART correctly, making practical exploitation significantly harder. 

SecureROM Code Execution Achieved Despite Protections 

Exploitation methods differed between hardware generations. On A12 and Apple Watch S4/S5 devices, researchers achieved program counter control by overwriting a saved link register located near the USB DMA buffer. This allowed them to redirect execution and build a return-oriented programming (ROP) chain.  The A13 platform introduced Pointer Authentication Codes (PAC), making direct stack corruption ineffective. To overcome this protection, researchers developed a multi-stage attack involving heap corruption, interrupt handler manipulation, and controlled execution of function pointers stored in memory.  The team ultimately gained privileged EL1 execution within SecureROM code, enabling them to modify Device Firmware Update (DFU) mode, inject custom USB request handlers, and boot unsigned iBoot images.  To preserve their changes, the researchers copied BootROM code into SRAM, modified memory mappings through the MMU, and forced devices back into DFU mode after restarting SecureROM.  The researchers concluded that the iPhone BootROM vulnerability demonstrates how subtle hardware flaws can undermine modern security protections. Although newer Apple devices appear unaffected, vulnerable A12, A13, and Apple Watch models will remain exposed for their operational lifetime because the flaw exists within immutable BootROM and SecureROM code. The findings were disclosed to Apple's Product Security team before publication. 

A newly disclosed SearchLeak vulnerability in Microsoft 365 Copilot Enterprise exposed a critical pathway for attackers to steal sensitive organizational data through a specially crafted URL. The flaw chain, now tracked as CVE-2026-42824, was patched by Microsoft earlier this month and assigned a critical severity rating due to its potential impact. Security researchers at Varonis discovered the issue by combining three separate weaknesses that, on their own, posed limited risk. Together, however, they enabled attackers to silently extract emails, calendar information, SharePoint documents, OneDrive files, and other indexed enterprise content accessible through Microsoft 365 Copilot Enterprise.

How the SearchLeak Vulnerability Worked 

According to the researchers, the SearchLeak vulnerability combined an AI-specific flaw known as Parameter-to-Prompt Injection (P2P) with two traditional web security issues: an HTML rendering race condition and a server-side request forgery (SSRF) vulnerability involving Bing.  The first stage exploited the search function of Microsoft 365 Copilot Enterprise, where the "q" URL parameter was passed directly to Copilot as an executable prompt. Instead of being treated as a simple search query, attacker-controlled input could be interpreted as instructions.  Researchers demonstrated that a malicious URL could instruct Copilot to search a victim’s mailbox, retrieve email titles or other sensitive content, and embed the extracted data inside an image URL without requiring any user interaction beyond a click. 

Chaining Three Flaws into One Attack 

The second stage relied on an HTML rendering race condition. While Microsoft attempted to neutralize potentially dangerous HTML by wrapping responses inside code blocks, that protection occurred only after Copilot completed generating its response. During the streaming phase, raw HTML, including image tags, could briefly render and trigger outbound requests before sanitization took effect.  The final component of the SearchLeak vulnerability involved a Content Security Policy bypass through Bing. Since Bing domains were allowlisted, attackers leveraged Bing’s image search endpoint, which performs server-side fetching of image URLs. By embedding stolen data within those URLs, Bing unknowingly acted as a proxy, forwarding the information to attacker-controlled servers.  As described by Varonis, the attack required no plugins, elevated privileges, additional clicks, or suspicious domains. Victims only needed to open a trusted Microsoft link. 

Potential Impact of CVE-2026-42824 

Because Microsoft 365 Copilot Enterprise operates with the user's existing permissions, successful exploitation of CVE-2026-42824 effectively granted attackers access to whatever information the targeted employee could access.  Potentially exposed data included email content, one-time passwords, password reset links, calendar events, meeting notes, attendee information, confidential communications, SharePoint files, OneDrive documents, earnings reports, salary information, acquisition plans, and other sensitive business records.  The researchers noted that the novelty of the SearchLeak vulnerability lies in how AI-enabled prompt injection made older attack techniques practical in a new environment. Without the P2P flaw, attackers could not inject malicious instructions; without the race condition, the HTML would be neutralized; and without the SSRF weakness, the Content Security Policy would block data exfiltration.  Microsoft has since remediated the issue under CVE-2026-42824, but researchers say the case highlights how AI systems can introduce new attack paths by connecting previously understood vulnerabilities in unexpected ways. 

A critical Windows Netlogon vulnerability, tracked as CVE-2026-41089, has emerged as a significant security concern after authorities warned that threat actors are actively attempting to exploit the flaw to gain remote code execution capabilities on vulnerable systems.  The security issue, which carries a CVSS severity score of 9.8, was publicly disclosed on May 12, 2026, when Microsoft addressed it alongside 136 other vulnerabilities as part of its monthly Patch Tuesday security updates. While several of the bugs fixed during that release were identified as likely candidates for exploitation, CVE-2026-41089 was not initially included among those expected to be targeted by attackers. 

Threat Actors Reportedly Exploiting CVE-2026-41089 

The Centre for Cybersecurity Belgium (CCB) issued a warning on Friday, stating that threat actors have begun exploiting the critical Windows Netlogon vulnerability in real-world attacks. The agency urged organizations to deploy available security updates immediately to reduce the risk of compromise.  According to the CCB, the flaw is “now actively exploited in the wild,” raising concerns that attackers may already be targeting unpatched systems. The organization noted that successful exploitation could allow remote attackers to execute arbitrary code with System-level privileges, providing extensive control over affected environments.  Despite the warning, no additional public reports have surfaced confirming exploitation attempts involving CVE-2026-41089. Furthermore, Microsoft has not updated its advisory to indicate that active attacks have been verified. 

How the Windows Netlogon Vulnerability Works 

Microsoft’s advisory describes CVE-2026-41089 as a stack-based buffer overflow vulnerability affecting the Netlogon service. The flaw can be triggered through specially crafted network requests sent to a Windows server operating as a domain controller.  Importantly, the vulnerability can be exploited by unauthenticated attackers, meaning no valid credentials or prior access to the targeted environment are required.  Microsoft explained the risk in its advisory, stating:  “If successful, this could cause the Netlogon service to improperly handle the request, potentially allowing the attacker to run code on the affected system without needing to sign in or have prior access.”  Because the flaw enables remote code execution and does not require authentication, security experts consider CVE-2026-41089 one of the more dangerous vulnerabilities addressed during the May 2026 Patch Tuesday release. 

Why the Netlogon Service Remains a High-Value Target 

The Netlogon service plays a critical role in Windows domain-based environments by handling authentication processes between users, computers, and domain controllers. As a core background service, it is essential to maintain secure communication and identity verification across enterprise networks.  Historically, weaknesses in Netlogon have attracted the attention of threat actors because successful exploitation can provide access to highly privileged systems. Critical flaws affecting the service can potentially allow attackers to gain control over a domain controller and, by extension, influence or compromise connected machines throughout the network.  Given the importance of the service, security professionals have long viewed any severe Windows Netlogon vulnerability as a high-priority issue requiring rapid remediation. Regardless of the differing assessments, security experts recommend that organizations prioritize patching CVE-2026-41089 as soon as possible.   The combination of its critical severity rating, the potential for unauthenticated remote code execution, and reports of activity by threat actors makes the vulnerability a significant risk for organizations operating Windows domain environments. 

The Central Board of Secondary Education (CBSE) has intensified its response to concerns about an OSM vulnerability by engaging cybersecurity specialists from IIT Madras, IIT Kanpur, and several government agencies to conduct a detailed security assessment of its On-Screen Marking (OSM) platform. The portal, introduced in 2026 for the evaluation of the Class 12 board exam, has come under scrutiny following allegations from security researchers and ethical hackers about multiple weaknesses in the system.  In an official statement shared on X on May 31, 2026, CBSE acknowledged the issue and confirmed that remedial measures were already underway. The board stated, “The identified vulnerabilities have been contained, and other exploitable weaknesses are being ruled out.”  The announcement is a notable development in the controversy surrounding the OSM platform. While CBSE had previously maintained that the system was secure, the latest statement confirms that vulnerabilities did exist and required immediate attention from cybersecurity experts. 

Decoding the OSM Vulnerability 

The controversy emerged after security researchers and ethical hackers highlighted several alleged flaws in the OSM platform used for the Class 12 board exam evaluation process. According to the concerns raised, the vulnerabilities could have exposed sensitive examination-related data and administrative controls.  Among the issues reported were: 

• A hardcoded master password allegedly embedded within publicly accessible source code, potentially enabling unauthorized access. 
• One-time passwords (OTPs) are reportedly visible through web browsers without requiring authentication. 
• The ability to reset evaluator passwords without proper authorization. 
• Potential access to or modification of student marks stored within the system. 
• An Amazon Web Services (AWS) cloud storage bucket allegedly contains scanned 2026 examination records that could be accessed publicly without login credentials. 

Ethical hacker Nisarga Adhikary further alleged that scanned answer sheets and question papers stored within the AWS repository could be viewed and downloaded without authentication. These allegations intensified concerns regarding the scale and potential impact of the reported OSM vulnerability. 

CBSE Deploys Expert Teams for Security Audit 

As part of its response, CBSE has assembled a specialized team comprising experts from IIT Madras, IIT Kanpur, and the Digital Infrastructure Corporation of India. The objective is to perform a comprehensive audit of the platform and identify any remaining vulnerabilities.  According to the board, the security teams have been working on the matter for several days. CBSE stated that all known vulnerabilities have been contained and that the platform is currently being migrated to a more secure environment as part of a broader strengthening exercise.  The board has also initiated direct communication with some of the security researchers who reported the issues. 

CBSE’s Security Measures at a Glance 

As part of its response to the reported OSM vulnerability, CBSE has deployed a specialized team comprising experts from IIT Madras, IIT Kanpur, and the Digital Infrastructure Corporation of India. The board said these cybersecurity teams have been working on the matter for several days to assess the system and strengthen its security framework.  According to CBSE, the known vulnerabilities identified in the OSM portal have been contained. The board also stated that the platform is currently being migrated to a more secure environment as part of its broader effort to enhance protection against potential cyber threats.  CBSE has engaged directly with some of the security researchers and ethical hackers who brought the issues to light. The board has also invited additional inputs from researchers and cybersecurity professionals, requesting that any relevant information or findings be shared with its security team via email at secy-cbse@nic.in. 

Board Invites Further Input from Researchers 

CBSE publicly acknowledged the role played by ethical hackers and security researchers in identifying weaknesses within the platform.  In its statement, the board said:  “We are grateful to all alert citizens and ethical hackers pointing out such weaknesses and have gotten in touch with some of them directly.”  The board further added:  “We request any others to reach out to our security teams at secy-cbse@nic.in for any further inputs.”  CBSE reiterated that the identified OSM vulnerability issues have been contained while a wider security review remains ongoing. 

Post-Result Services Begin Despite Security Concerns 

Despite the ongoing scrutiny surrounding the OSM platform, CBSE proceeded with the launch of its Class 12 post-result services on June 1, 2026, as previously scheduled.  Students who appeared for the Class 12 board exam can now access post-result services through the official portal and apply for: 

• Scanned copies of answer books 
• Verification of marks 
• Re-evaluation requests 

CBSE stated that the portal underwent security hardening measures before becoming operational on June 1. The controversy has also expanded beyond cybersecurity concerns. Student Sarthak Sidhant had earlier raised questions regarding the procurement and tendering process associated with the OSM system, adding another layer to the ongoing debate. 

A critical Ghost CMS vulnerability identified as CVE-2026-26980 has been exploited in a widespread cyber campaign that compromised more than 700 websites, including platforms associated with major institutions such as Harvard University, University of Oxford, and DuckDuckGo. Security researchers say the attacks leveraged weaknesses in the Ghost content management system to inject malicious JavaScript code aimed at facilitating ClickFix malware attacks.  The attacks were detailed by Chinese cybersecurity company QiAnXin and its XLab research team, which warned that threat actors are actively exploiting unpatched Ghost installations in an ongoing “large-scale poisoning” campaign. 

CVE-2026-26980 Enabled Unauthorized Access to Ghost CMS Sites 

The exploited flaw, tracked as CVE-2026-26980, was disclosed and patched in February 2026 in version 6.19.1 of the Ghost content management system. Ghost is a widely used open-source CMS focused on blogging, digital publishing, newsletters, and memberships. According to its developers, the platform powers more than 100,000 websites globally.  The Ghost CMS vulnerability is an SQL injection flaw affecting Ghost’s Content API. Researchers at SentinelOne previously warned that the vulnerability could allow unauthenticated attackers to extract sensitive data directly from a site’s database. This included authentication tokens, website content, and user credentials.  The flaw received a CVSS severity score of 9.4, highlighting the serious risks posed by CVE-2026-26980. The vulnerability was reportedly discovered by Anthropic using its Claude AI system. What made the Ghost CMS vulnerability especially dangerous was its ability to expose a site’s Admin API Key. Once attackers obtained this key, they could abuse Ghost’s Admin API to directly modify published articles and inject malicious code into legitimate websites without authorization.

Hundreds of Websites Infected 

According to QiAnXin XLab, attackers began exploiting CVE-2026-26980 shortly after the security patch became publicly available. Investigators noted that a DLL file involved in the campaign carried a compilation timestamp dated February 16, 2026 — the same day the patch for the Ghost CMS vulnerability was announced. The malicious activity was first detected on May 7, 2026, and by early May, researchers had already identified hundreds of compromised websites running the Ghost content management system. More than 700 websites across various industries were eventually found to be affected. The victims included organizations operating in sectors such as artificial intelligence, software development, blockchain, cybersecurity, fintech, media, SaaS, and higher education. Researchers found that nearly half of the compromised websites were personal blogs or independently operated sites. However, many others belonged to major institutions and technology-focused organizations.  QiAnXin stated that many victims were notified about the compromises, but the majority reportedly failed to respond to the alerts.  “At least two groups are currently actively conducting such poisoning operations, and some sites have even become the target of competition between the two parties, with different malicious code being implanted one after another within a single day,” the researchers said. 

Malicious JavaScript Injected Into Ghost CMS Articles 

The attackers used the Ghost CMS vulnerability to tamper with website articles by appending malicious JavaScript loaders to the bottom of pages. These loaders were designed to support ClickFix attacks — a growing social engineering tactic that tricks users into manually executing malware on their systems.  The injected code acted as a two-stage loader that retrieved additional payloads at runtime from an external domain identified as “clo4shara[.]xyz/11z77u3.php.” Researchers said the infrastructure gave attackers flexibility to swap payloads while maintaining the same loader framework across multiple compromised Ghost CMS sites.  QiAnXin explained that the PHP script functioned as a traffic distribution and cloaking system powered by Adspect, a commercial cloaking service. The script gathered browser fingerprinting data from visitors and selectively redirected targets based on predefined rules.  “Directly accessing clo4shara[.]xyz/11z77u3.php reveals a piece of code, which is actually a typical traffic distribution script,” XLab researchers explained. “Its core function is to collect various fingerprint information from the user's browser and upload it to the server, then perform actions such as redirection, popups, and downloads based on the returned instructions.”  The cloaking mechanism helped attackers avoid detection by ensuring that only intended victims received malicious payloads, while automated scanners and crawlers were shown harmless web content instead. 

Cybersecurity researchers are warning that attackers have already started exploiting a newly disclosed NGINX vulnerability, tracked as CVE-2026-42945, just days after technical details and proof-of-concept code became public. The flaw, also referred to as NGINX Rift, affects millions of potentially exposed servers and has raised concerns across the security community due to its potential impact on core internet infrastructure.  Security researcher Patrick Garrity of VulnCheck revealed on Saturday that exploitation attempts targeting CVE-2026-42945 were detected shortly after disclosure. The vulnerability was publicly announced the previous week and is considered critical because it can be abused to trigger denial-of-service conditions and may also enable unauthenticated remote code execution under specific circumstances. 

What Is NGINX and Why the Vulnerability Matters 

NGINX is one of the most widely used web servers in the world and serves as a foundational component of modern internet infrastructure. In addition to functioning as a web server, it is commonly deployed as a load balancer, reverse proxy, and HTTP cache.  The software is maintained by application delivery and networking company F5, which oversees the development of both the open-source edition, known as NGINX Open Source, and the commercial offering, NGINX Plus. The company has also integrated NGINX into several of its security and application delivery products.  Because of NGINX’s extensive global deployment, the discovery of NGINX Rift and the rapid emergence of exploitation attempts have intensified concerns about large-scale exposure. 

Technical Details Behind CVE-2026-42945 

The NGINX vulnerability CVE-2026-42945 is classified as a memory corruption flaw affecting NGINX Open Source versions 0.6.27 through 1.30.0 and NGINX Plus versions R32 through R36. Several F5 products that incorporate NGINX are also impacted, including NGINX Ingress Controller and F5 WAF for NGINX.  Researchers explained that the flaw originates in the ngx_http_rewrite_module. According to the disclosure, a remote and unauthenticated attacker can corrupt heap memory within an NGINX worker process by sending a specially crafted HTTP request.  The vulnerability is triggered through a relatively common configuration pattern involving rewrite directives that use unnamed regular expression captures such as $1 or $2, combined with a replacement string containing a question mark and followed by another rewrite, if, or set directive.  Researchers who uncovered the flaw stated:  “A bug in the ngx_http_rewrite_module lets a remote, unauthenticated attacker corrupt the heap of an NGINX worker process by sending crafted URI.”  They further explained that NGINX calculates a destination buffer using one set of escaping assumptions but writes data using another, ultimately causing writes beyond the allocated memory region.  According to the researchers:  “The write runs past the allocated buffer, producing deterministic memory corruption. The bytes written past the allocation are derived from the attacker’s URI, so the corruption is shaped by the attacker rather than random.”  The researchers also warned that repeated malicious requests could force NGINX workers into continuous crash loops, severely affecting the availability of websites and applications hosted on vulnerable systems. 

Patches and Mitigation Measures Released 

F5 has already released fixes for the NGINX vulnerability CVE-2026-42945 across multiple products. The issue has been addressed in: 

• NGINX Open Source versions 1.31.0 and 1.30.1  
• NGINX Plus versions R36 P4 and R32 P6  
• F5 WAF for NGINX v5.13.0  
• F5 DoS for NGINX v4.9.0  

In addition to software updates, F5 recommended a mitigation strategy for organizations unable to patch immediately. The company advised administrators to replace unnamed regex captures in rewrite rules with named captures to reduce exposure to NGINX Rift attacks.  Meanwhile, Linux distribution maintainers, including AlmaLinux, Ubuntu, and Debian developers, have started rolling out patched NGINX packages to address CVE-2026-42945.  With exploitation attempts already underway, security experts are urging organizations to review their NGINX configurations, apply available patches immediately, and audit rewrite rules that may expose systems to the NGINX vulnerability. 

Banks across the United States, Europe, and Japan are accelerating efforts to strengthen cybersecurity defenses after the emergence of a new artificial intelligence-powered vulnerability discovery tool raised concerns across the financial sector. The growing discussion around AI-driven cyber risks comes after Anthropic’s Mythos AI tool reportedly exposed previously unknown vulnerabilities within banking systems, prompting financial institutions and regulators to reassess their cyber resilience strategies. While access to the vulnerability-hunting AI model remains limited to select organizations, cybersecurity experts warn that the technology demonstrates how rapidly evolving AI capabilities could reshape cyber threats targeting critical financial infrastructure. According to recent cybersecurity updates highlighted by the World Economic Forum, banks with ageing legacy systems are facing increased pressure to identify and patch weaknesses before malicious actors begin exploiting similar AI-powered capabilities.

AI-Driven Cyber Risks Push Banks to Strengthen Defenses

The rise of AI-driven cyber risks has triggered warnings from financial regulators and international organizations concerned about the potential impact on global financial stability. The European Central Bank has urged banks across the eurozone to prepare urgently for future cyberattacks. Frank Elderson, a member of the ECB Executive Board, warned that institutions cannot afford to delay cybersecurity improvements simply because they lack direct access to tools like Mythos. Smaller banks are also receiving shared intelligence and vulnerability findings from larger financial institutions to improve sector-wide preparedness. The International Monetary Fund has similarly cautioned that rapidly evolving AI-enabled cyber threats could destabilize financial systems if not properly managed. A recent World Economic Forum report developed in collaboration with KPMG examined how organizations can deploy AI securely in cybersecurity operations. The report, titled Empowering Defenders: AI for Cybersecurity, outlined four levels of AI autonomy and warned that while machine-speed responses improve defense capabilities, reduced human oversight may increase operational risks if errors go undetected.

Canvas Breach Raises Questions About Ransom Payments

Another major cybersecurity development involved the company behind the widely used education platform Canvas. Instructure confirmed it had reached an agreement with hackers responsible for stealing approximately 3.5 terabytes of student and university data during a cyberattack that disrupted institutions across the US, Canada, Australia, and the UK earlier this month. The company said the agreement prevented the publication of the stolen information and included what it described as “digital confirmation” that the data had been destroyed. However, the organization did not clarify whether a ransom payment was involved. The incident has reignited debate around ransomware negotiations and cyber extortion tactics. Many cybersecurity experts warn that paying attackers does not guarantee stolen data will actually be deleted and could encourage future attacks. Research cited in the report showed that 58% of Chief Information Security Officers surveyed by a US cybersecurity company said they would consider paying hackers to minimize operational disruption. Cybersecurity analysts also warned that modern ransomware attacks increasingly involve “double extortion” tactics, where attackers steal sensitive data before encrypting systems and demanding payment.

Growing Cybersecurity Concerns Around Global Events and AI Threats

Cybersecurity experts are also warning about threats connected to major international events, including the upcoming 2026 FIFA World Cup hosted across the United States, Canada, and Mexico. Researchers believe the tournament could become a high-profile target for cybercriminals because of its global visibility and heavy reliance on digital infrastructure. Security experts have already reported increased phishing campaigns, fake ticket scams, and fraudulent websites targeting football fans. Meanwhile, new cyberattacks linked to the threat group Ghostwriter have reportedly targeted government organizations in Ukraine using phishing emails disguised as communications from a local telecommunications company. Google also disclosed what researchers described as the first AI-generated zero-day exploit designed to bypass two-factor authentication systems. Security experts believe the discovery prevented what could have become a large-scale exploitation campaign. Separately, OpenAI confirmed that two employee devices were affected during the recent TanStack supply chain attack. The company stated there was no evidence that customer data, production systems, or intellectual property had been compromised. German authorities also dismantled a revived version of Crimenetwork, a cybercriminal marketplace linked to illegal trade involving stolen data, drugs, and forged documents. Law enforcement agencies estimate the platform generated more than $4.2 million in revenue. The latest developments reflect growing concern among governments, regulators, and cybersecurity leaders that AI-powered cyber threats, ransomware operations, and increasingly sophisticated criminal ecosystems are reshaping the global cybersecurity landscape.

A newly revealed Exim BDAT vulnerability is affecting some email server setups that use Exim as their Mail Transfer Agent (MTA), prompting security attention due to its severity. Tracked as CVE-2026-45185 with a CVSS score of 9.8 and internally referred to as “Dead.Letter,” the issue is classified as a remote use-after-free vulnerability that can lead to memory corruption and potentially code execution under specific conditions involving GnuTLS.  Exim, an open-source MTA (Mail Transfer Agent) widely used on Unix-like systems for receiving, routing, and delivering email, has released a security update addressing the flaw. The vulnerability primarily affects configurations where Exim is built with GnuTLS support enabled. 

Technical Overview of the Exim BDAT Vulnerability

The Exim BDAT vulnerability (CVE-2026-45185) is rooted in how Exim handles BDAT (Binary Data) SMTP message transfers when TLS sessions are terminated unexpectedly. Specifically, the flaw occurs in the message body parsing logic when a TLS close_notify alert is received before a BDAT transfer completes. In this scenario, the use-after-free vulnerability emerges when Exim continues processing incoming data after the TLS session teardown has already freed internal memory buffers. If a client then sends an additional byte in cleartext over the same TCP connection, Exim may attempt to write into already freed heap memory. This leads to memory corruption, which can be leveraged in certain circumstances to achieve code execution. Exim maintainers summarized the triggering sequence as follows: the vulnerability appears when a TLS session is closed via close_notify during an active BDAT transfer, followed by continued data transmission on the same connection. This unexpected state transition allows the Exim BDAT vulnerability to surface in affected builds.

Affected Configurations and Scope of CVE-2026-45185 

The vulnerability affects Exim versions 4.97 through 4.99.2, but only when compiled with USE_GNUTLS=yes. Systems built with other TLS backends, such as OpenSSL, are not impacted.  Key affected conditions include: 

• Exim versions 4.97 to 4.99.2  
• Builds using GnuTLS  
• SMTP sessions utilizing the CHUNKING (BDAT) extension  
• TLS connections interrupted by close_notify during BDAT processing  

Because the flaw resides in a use-after-free vulnerability, exploitation depends on precise timing and protocol manipulation, but it remains classified as remotely triggerable over network connections. 

Security Advisory Timeline for the Exim BDAT Vulnerability 

The coordinated disclosure process for CVE-2026-45185 followed a structured timeline beginning in early May 2026: 

• 2026-05-01 17:29 UTC: Initial report submitted by Federico Kirschbaum (XBOW Security)  
• 2026-05-04 20:00 UTC: Follow-up requesting status of the report  
• 2026-05-05 ~02:53 UTC: Exim maintainers acknowledged the issue and confirmed a private fix was underway  
• 2026-05-07 14:14 UTC: Disclosure coordination discussion initiated by reporter  
• 2026-05-07 22:00 UTC: Notification sent to distribution maintainers via distros@openwall  
• 2026-05-10 20:00 UTC: Restricted fix access shared with distributors  
• 2026-05-12 14:00 UTC: Public advisory and patch release  

The official advisory, EXIM-Security-2026-05-01.1, confirmed the issue as a remote use-after-free (UAF) class vulnerability and noted that the final CVE assignment was pending at the time of release. 

Impact of the Exim BDAT Vulnerability on Mail Transfer Systems 

Because Exim functions as a widely deployed MTA, the Exim BDAT vulnerability has potential implications for mail infrastructure that relies on GnuTLS-backed TLS sessions. The flaw is particularly relevant in environments where SMTP CHUNKING (BDAT) is enabled, as it directly interacts with message body transfer behavior. The vulnerability is considered severe due to its memory corruption potential. The CVSS rating of 9.8 reflects the possibility that a successful exploit could escalate into code execution, depending on system conditions and memory layout. The issue was resolved in Exim version 4.99.3, which introduces corrected handling of TLS session teardown during BDAT transfers. The fix ensures that internal processing states are properly reset when a close_notify alert is received, preventing stale memory references and eliminating the use-after-free vulnerability condition.  According to the advisory, there is no known mitigation other than upgrading. Administrators running affected versions are strongly advised to move to Exim 4.99.3 or later as soon as possible.

A recently disclosed set of vulnerabilities in Salesforce Marketing Cloud, widely known as SFMC, has drawn attention to the security risks tied to centralized marketing infrastructure.   The flaws, which affected components tied to AMPScript, CloudPages, and email-rendering workflows, could have enabled attackers to access subscriber information, enumerate marketing emails, and potentially affect organizations across multiple tenants.  Security researchers found that weaknesses in SFMC’s templating engine and cryptographic implementation introduced opportunities for unauthorized data access across customer environments. 

AMPScript and SFMC Template Injection Risks 

Modern enterprises rely heavily on Salesforce Marketing Cloud to manage large-scale marketing campaigns, personalized customer journeys, and trackable email communications. The platform, formerly known as ExactTarget, supports dynamic content generation through technologies such as AMPScript, Server-Side JavaScript (SSJS), and internal data views connected to large subscriber databases.  While these features provide flexibility for marketers, researchers noted that they also increase the impact of any underlying vulnerability. One of the major concerns centered on SFMC’s server-side templating framework.  AMPScript and SSJS allow organizations to dynamically insert subscriber attributes such as names, email addresses, and engagement metrics directly into marketing content. However, functions like TreatAsContent introduced a dangerous behavior because they effectively evaluate user-controlled input as executable template code. Researchers explained that if attacker-controlled data was passed into these functions, it could trigger template injection inside Salesforce Marketing Cloud environments.  The issue became more severe because SFMC historically supported AMPScript execution within email subject lines. According to the findings, legacy behavior caused subject templates to be evaluated twice by default. That design opened the door for payload execution during the second rendering stage. Researchers demonstrated the risk using the following payload inside a name field:  %%=RowCount(LookupRows("_Subscribers","SubscriberKey",_subscriberkey))=%%  If processed during the second evaluation phase, the payload could execute successfully and create a reliable injection point inside the marketing workflow.  Once template execution was achieved, attackers could potentially use built-in SFMC functions such as LookupRows to query internal Data Views, including: 

• _Subscribers  
• _Sent  
• _Job  
• _SMSMessageTracking  
• _Click  

Access to these views could expose subscriber lists, email delivery records, engagement metrics, and message history associated with affected Salesforce Marketing Cloud tenants. 

CloudPages and “View Email in Browser” Vulnerability

Researchers identified an even more serious vulnerability tied to SFMC’s “view email in browser” functionality and CloudPages infrastructure. Many Salesforce customers configure branded domains such as view.example.com or pages.example.com that route back to shared SFMC infrastructure. These links typically rely on an encrypted qs parameter containing tenant and message-specific information. According to researchers from Searchlight Cyber, the older “classic” qs implementation used unauthenticated CBC encryption. The researchers found that the implementation behaved as a padding oracle, which made it possible to decrypt and re-encrypt query string parameters under certain conditions. Initially, the researchers abused the weakness using the Padre tool before later improving the process through the AMPScript MicrositeURL function.  This allowed them to forge valid QS values and access workflows such as “Forward to a Friend,” which could resolve subscriber identifiers into actual email addresses.  One of the most concerning aspects of the vulnerability was SFMC’s use of a single static encryption key shared across tenants. Researchers stated that once the cryptographic structure became understood, attackers could theoretically enumerate subscribers and access email content across multiple organizations using the same mechanism.

Legacy Encryption Weaknesses Expanded the Attack Surface 

The researchers also uncovered an older URL format that relied on per-parameter “encryption.” However, the mechanism reportedly consisted of a repeating static XOR key combined with a checksum. Although the scheme was considered legacy functionality, researchers found that it still worked on modern SFMC tenants. Because the implementation lacked strong cryptographic protections, attackers could decrypt and enumerate parameters such as JobID and ListSubscriber at high speed without relying on the slower padding-oracle technique.  The findings highlighted how legacy systems inside large cloud platforms can continue to create security exposure long after newer protections are introduced. 

Impact of the Salesforce Marketing Cloud Vulnerability 

Researchers concluded that the combined vulnerabilities could have enabled attackers to: 

• Enumerate and exfiltrate subscriber records  
• Access sent marketing emails and engagement data  
• Forge cross-tenant QS tokens  
• Access emails belonging to other organizations  
• Exploit hard-coded cryptographic material  
• Abuse argument-injection flaws tied to the MicrositeURL function  
• Manipulate CloudPages and other SFMC web workflows  

To address the issues, Salesforce assigned multiple CVEs covering several root causes, including insecure cryptographic implementations, hard-coded keys, and argument injection vulnerabilities affecting MicrositeURL and CloudPages components.  According to Salesforce, the vulnerabilities were reported on 16 January 2026. Mitigations were deployed between 21 January and 24 January 2026. The company stated that it had identified no confirmed malicious exploitation at the time of disclosure.  As part of the remediation process, Salesforce migrated Marketing Cloud Engagement encryption to AES-GCM, rotated encryption keys, and disabled the double evaluation behavior tied to AMPScript subject-line rendering.  The company also invalidated all legacy tracking and CloudPages links created before 21 January 2026 at 23:00 UTC. Those links expired globally on 23 January 2026 at 21:00 UTC.