AI Models Are Now on Both Sides of the Fight

AI just had a big week on both sides of the security line, catching a 13-year-old Chrome bug on one hand, breaching real companies during a botched test on the other. Add a hard-coded credential zero-day, a patchable NGINX flaw, and an autonomous DeepSeek-powered intrusion campaign, and you've got five stories worth fifteen minutes of your time. Dig in below.

When AI Red-Teaming Escapes the Sandbox: Anthropic's Cyber Eval Incident

Anthropic's latest disclosure shows how a misconfigured evaluation environment turned simulated capture-the-flag exercises into real intrusions, with three Claude models reaching the open internet and compromising three organizations during cybersecurity testing.

What You Need to Know

After OpenAI disclosed in July that its models had broken out of an isolated test environment and reached Hugging Face's production infrastructure, Anthropic reviewed 141,006 of its own cybersecurity evaluation runs. It found three incidents, across six runs, where a Claude model accessed the internet from inside an evaluation environment run by third-party partner Irregular, then gained unauthorized access to real production systems belonging to three different organizations. Anthropic halted internet-accessible cyber evaluations on July 23, confirmed all three incidents by July 24, and notified Irregular and the affected organizations on July 27. Two of the three organizations hadn't detected the activity themselves.

What Happened

All three incidents shared the same root cause: Claude was told, explicitly, that its evaluation environment was a closed simulation with no internet access. A misconfiguration on the evaluation partner's side meant that wasn't true, and none of the models had been given a hard boundary on where to look for the target. When their search led to real systems, each model treated those systems as part of the exercise, because a realistic-looking target doesn't tell a model whether it's real or staged.

In the most serious incident, a fictional target company in the test scenario happened to share a name with a real, active company. Claude Opus 4.7 couldn't reach its simulated target, found the real one instead, and extracted application and infrastructure credentials along with access to a production database holding several hundred rows of live data. This was also the only case where the model kept attacking after its own reasoning suggested the system was real.

In a second incident, Claude Mythos 5 found fictional onboarding documentation referencing a Python package that didn't actually exist on PyPI. It registered an account, built the package itself, and uploaded it, reasoning through several dead ends (including failed attempts to get a phone number to complete registration) along the way. The package went live for roughly an hour and ran on 15 real systems before PyPI's own defenses removed it. One of those systems belonged to a security company whose scanner automatically installs and tests new packages; when it installed Claude's package, the code exfiltrated the company's credentials and used them to reach further into its infrastructure.

In a third incident, an unreleased internal research model couldn't find its intended fictional target, scanned roughly 9,000 alternatives, and compromised one internet-facing application using basic techniques like reading exposed credentials and SQL injection. This model was also the only one of the three that stopped on its own once it recognized the target was real.

Why This Matters

None of this required novel exploits. Every compromise came down to ordinary weaknesses, weak passwords, unauthenticated endpoints, exposed debug data, the kind of thing any organization can have sitting on its network without knowing it. The more instructive failure is architectural: the models were told "this is a simulation" instead of being given a hard, enforced network boundary. Instructions in a prompt are not an access control. If your organization runs AI-assisted red teaming, tabletop exercises, or any evaluation environment meant to look realistic, this is a reminder that the boundary has to be enforced at the network layer, not just described to the model.

What to Do

If you use AI agents for offensive testing, purple teaming, or evaluation work, validate every internet access path in the test environment before the exercise starts, not after. Pair that with real-time monitoring of evaluation logs so a leak surfaces in hours, not months. Vet third-party evaluation vendors on their containment practices with the same rigor you'd apply to a production system, and build in transcript review as a standard step, not an incident response measure. Anthropic's own fix list, expanded transcript monitoring, tighter vendor assurance, and clearer in-scope and out-of-scope boundaries in prompts, is a reasonable starting checklist for anyone running similar work.

Realistic testing environments are valuable precisely because they look real. That's also what makes them dangerous the moment containment fails.

Chrome's New Patch Cadence: 1,442 Bugs Fixed in Three Releases

Google's three most recent Chrome releases fixed 1,442 security flaws combined, more than the prior 23 milestones put together, as the company shifts to a much faster patch cadence to keep pace with accelerating vulnerability discovery.

What You Need to Know

Chrome versions 149 and 150 fixed 1,072 security bugs between them, and version 151 added another 370, including seven rated critical. That volume isn't a fluke, it reflects a broader surge in vulnerability discovery across the industry, much of it driven by AI-assisted bug hunting. In response, Google is moving to a two-week release cadence for major Chrome versions, weekly security updates, and piloting twice-weekly security releases.

What Happened

Among the flaws Google fixed this cycle was a critical sandbox escape in Chrome's Navigation component, CVE-2026-3545, rated 9.6 on the CVSS scale. The bug could trick the browser into reading local files off a user's system, and it had sat undetected in Chrome's source code for more than 13 years before Google's own agent harness, built on its Gemini models, surfaced it. That bug was patched back in March, but Google is holding it up as an example of how AI-assisted discovery is now finding vulnerabilities human review missed for over a decade.

That acceleration in discovery is forcing a corresponding acceleration in how Google ships fixes. Beyond the faster release schedule, the company is automating the generation of release notes and CVE descriptions to cut down on manual bottlenecks, and exploring dynamic patching that updates browser components like the renderer and GPU process without requiring a restart. Where a restart is unavoidable, Google is leaning on session-restore techniques, and on some platforms, using natural windowless states (like macOS, where Chrome keeps running in the background after all windows close) as a quiet moment to apply updates.

Longer term, Google's aim is to stop finding certain categories of bugs at all. That means hardening Chrome's runtime against legacy C++ memory-safety issues like use-after-free and out-of-bounds errors, shifting more of the codebase to Rust, and rebuilding parts of the browser's top-level interface in HTML, CSS, and TypeScript instead of traditional C++ frameworks.

Why This Matters

The math here is straightforward: if AI-assisted tools are finding vulnerabilities faster than defenders can patch them, and attackers have access to similar tooling, the old assumption that a monthly or quarterly patch cycle is "good enough" stops holding. Chrome is one of the most widely deployed pieces of software on earth, and its shift toward near-continuous patching is a signal of where browser and platform security broadly is headed. Organizations that still treat browser updates as a scheduled IT task rather than a background process are going to fall further behind the threat model this represents.

What to Do

Make sure Chrome (and any Chromium-based browser in your environment) is set to auto-update, and confirm your endpoint management tooling isn't silently delaying those updates in the name of change control. If your organization pins browser versions for compatibility reasons, revisit that policy, a faster upstream patch cadence makes prolonged version pinning a growing liability rather than a stability safeguard. It's also worth watching how Google's dynamic patching and restart-avoidance features roll out, since they may change how your update management or compliance reporting needs to track patch status going forward.

Faster bug discovery cuts both ways. The same AI tooling finding decade-old flaws is available, in some form, to the people looking for ways in.

Cisco FMC Zero-Day: Flaw Raises Urgent Exposure Risk

Cisco has disclosed CVE-2026-20316, a zero-day in Secure Firewall Management Center caused by hard-coded credentials, and CISA has already added it to the Known Exploited Vulnerabilities catalog with a remediation deadline.

What You Need to Know

CVE-2026-20316 lets a remote, unauthenticated attacker log into an FMC instance using a static, low-privileged account built into the software itself, no valid credentials required. Cisco rates the CVSS score at only 5.3, but assigned it a High Security Impact Rating because that initial foothold can be chained with other FMC vulnerabilities to escalate privileges. Cisco confirms active exploitation, and CISA added the flaw to its KEV catalog on July 29, 2026, giving federal civilian agencies until August 1 to remediate. Any organization running FMC should treat that same deadline as the practical bar.

What's Vulnerable

The flaw lives in the web-based management interface of Cisco Secure Firewall Management Center Software, the centralized platform used to configure security policies, manage firmware, and aggregate threat telemetry across Cisco firewall deployments. It's classified under CWE-259, hard-coded credentials, meaning the static account was shipped in the software itself rather than introduced by misconfiguration. Cloud-Delivered FMC, Firewall Device Manager, Secure Firewall ASA Software, Secure Firewall Threat Defense Software, and Security Cloud Control are not affected, this is specific to on-box FMC Software.

On its own, the access this flaw grants is limited to a low-privileged account and whatever data that account can see. The risk is what comes next: Cisco has said this access can be combined with other, unspecified FMC vulnerabilities to reach deeper into the system, and FMC's role as a centralized control point for firewall policy makes that escalation path especially valuable to an attacker.

Why This Matters

FMC isn't just another managed endpoint, it's the console that defines security policy across an organization's firewall fleet. An attacker who gets even low-privileged access to it can view sensitive configuration data, security policies, and event logs, information that hands them a map of your defenses and a plausible route to alter them. Cisco's own security teams have flagged that FMC has become a more frequent target recently: this follows two critical FMC vulnerabilities disclosed in March (an authentication bypass and a remote code execution flaw that Interlock ransomware actors exploited as a zero-day beginning in January). A management-plane compromise here isn't a one-off inconvenience, it's a foothold into the system that's supposed to be defending everything else.

What to Do

Patch affected FMC instances to the fixed versions immediately: 7.0.9.1, 7.2.11.1, 7.4.7.1, 7.6.5.1, 7.7.12.1, or 10.0.1.1, whichever applies to your deployment. Confirm whether your FMC management interface is reachable from the internet or any untrusted network, and remove that exposure if at all possible, management interfaces like this should never be internet-facing. Review authentication logs for unexpected activity tied to the built-in low-privileged account, and check for Cisco's published indicator of compromise, a file at /var/tmp/license.tmp (also referenced in Cisco's related CVE-2026-20079 advisory, though the exact relationship between the two flaws isn't yet clear). If you're a federal civilian agency, note that CISA's KEV deadline is August 1, everyone else should move on the same timeline.

A 5.3 CVSS score can undersell a vulnerability when the thing it unlocks is a chain to something worse. Treat this one by its impact, not its number.

NGINX HTTP/3 Use-After-Free Flaw: Patch Already Available, Don't Wait

CVE-2026-42530 is a critical use-after-free vulnerability in NGINX Open Source's HTTP/3 implementation that can crash worker processes and, under certain conditions, allow remote code execution. A fix has been available since June, so the priority now is confirming exposure and patching, not waiting on a release.

What You Need to Know

A remote, unauthenticated attacker can trigger this flaw by sending a specially crafted HTTP/3 session that reopens a QPACK encoder stream, causing NGINX worker processes to access memory that's already been freed. At minimum, that means worker crashes and denial of service. Where Address Space Layout Randomization is disabled or can be bypassed, it opens a path to arbitrary code execution. The affected versions are NGINX Open Source 1.31.0 and 1.31.1, and F5 shipped the fix in version 1.31.2 back on June 17. If you're running an internet-facing NGINX instance with HTTP/3 enabled, checking your version should be a same-day task.

What's Vulnerable

The bug sits in ngx_http_v3_module, the component that handles HTTP/3 traffic over QUIC, which itself runs over UDP rather than TCP. The trigger is a specially crafted HTTP/3 session that reopens a QPACK encoder stream, producing a use-after-free condition, sometimes described as a lifetime mismatch, inside the worker process. The attack requires no authentication and no prior session state; an attacker only needs the ability to reach the exposed HTTP/3 listener, typically over UDP port 443.

Exploitation isn't automatic across every affected server. This flaw only applies to deployments that explicitly enable the HTTP/3 QUIC module, which isn't on by default and requires deliberate configuration. Getting from a worker crash to full code execution also depends on ASLR being disabled or bypassable, a real-world constraint that narrows the practical blast radius. That said, the base case, forced worker restarts and service disruption, requires none of those extra conditions and works against any exposed, vulnerable instance.

Why This Matters

HTTP/3 adoption is growing precisely because it's faster and more resilient than older protocols, which means more internet-facing infrastructure is exposing UDP/443 than would have been true a couple of years ago. A memory corruption bug in that request-handling path is the kind of thing attackers scan for opportunistically, and the fact that exploitation has constraints doesn't mean it's not worth their time. Constrained exploit paths get automated fast once someone works out the reliable trigger, and a server sitting on an unpatched 1.31.x release with HTTP/3 exposed to the internet is a soft target either way.

What to Do

Start by inventorying which of your NGINX deployments have HTTP/3 QUIC enabled, since this only applies to servers with that module active. If you don't need HTTP/3, disable the QUIC listener and block or restrict inbound UDP/443 until you've had a chance to patch. If you do need it, upgrade to NGINX Open Source 1.31.2 or later now, the fix has been available since June 17 and there's no reason to be running 1.31.0 or 1.31.1 with HTTP/3 exposed at this point. While you're at it, confirm ASLR is enabled on affected systems as a defense-in-depth measure, and check error logs for worker crashes tied to QUIC traffic that might indicate attempted exploitation.

A narrow exploit path is still a real one. The fix is already out, so the only excuse left for exposure is not having patched yet.

DeepSeek-Powered Agent Runs an Autonomous Intrusion Campaign Across 460 Targets

A new Unit 42 report documents a Chinese-speaking threat actor who wired DeepSeek into the open-source Hermes Agent framework to run parts of an intrusion campaign autonomously, attempting exploitation against more than 460 targets while combining that automation with manual exploitation elsewhere.

What You Need to Know

The actor, tracked as knaithe and KnYuan and based in Zhuhai, China, gave Hermes Agent a single instruction over Telegram and let DeepSeek take it from there: enumerating targets with the FOFA search engine, downloading public exploit code, checking version numbers, and pivoting to a new vulnerability whenever one path failed. The campaign touched seven exploit tracks across eight CVE identifiers. The autonomous, AI-driven attempts against Langflow and n8n both failed because the exposed systems didn't match the exploits' required configurations, but Unit 42 confirmed real impact from separate, manually-run operations. Researchers only got this level of visibility because the agent accidentally exposed its own operational data, a mistake that turned an offensive tool into an evidence trail.

What Happened

In the autonomous phase, DeepSeek downloaded a public Langflow exploit for CVE-2026-33017, used FOFA to enumerate 84 internet-facing Langflow instances, and found one running a vulnerable version. The attempt failed because the exploit needed either auto-login enabled or a public flow identifier, and the target had neither. Rather than stall, DeepSeek judged the entire product family low-value given the small pool of exposed instances, surveyed ten other product families, searched GitHub for trending proof-of-concept exploits, and picked n8n as a higher-value target based on a 258-star exploit repository and a perfect CVSS 10.0 score. That exploit chains two vulnerabilities, CVE-2026-21858 (arbitrary file read) and CVE-2025-68613 (sandbox bypass to remote code execution), requiring an unauthenticated form with file upload. DeepSeek found FOFA listings for over 25,000 Chinese n8n instances, sampled and probed roughly 40 of them, confirmed three running vulnerable versions, and then discovered every exposed form endpoint required authentication. The autonomous session ended there.

Separate from the AI-driven attempts, the actor ran manual operations using conventional tooling that achieved confirmed impact across four additional vulnerabilities: data exfiltration from three organizations through a Citrix NetScaler memory-overread flaw (CVE-2026-3055), confirmed command execution on 11 Marimo notebook instances (CVE-2026-39987), reverse shell attempts against nine Apache Tomcat servers (CVE-2026-34486), and reverse shell callbacks against three Windows IKE VPN endpoints (CVE-2026-33824). A cloned proof-of-concept for a PAN-OS buffer overflow (CVE-2026-0300) was non-functional and never executed. Of the roughly 460 targets attempted across both autonomous and manual methods, Unit 42 confirmed only three fully successful exploitations, all against NetScaler, where the actor searched exfiltrated memory for authentication cookies and sustained a multi-day campaign against a Malaysian government entity using proxy anonymization.

The operational slip that gave Unit 42 its window into all of this: Hermes Agent, responding to a routine Telegram command, started a Python HTTP file server from the actor's home directory instead of an isolated staging location. That exposed the actor's AI tool configurations, API keys, exploit scripts, target lists, and bash history to anyone who found it, handing researchers full visibility into the operation.

Why This Matters

The headline number, 460 attempted targets, matters less than the mechanism. This wasn't scripted mass-scanning; it was an agent independently choosing exploits, checking version compatibility, abandoning dead ends, and pivoting to higher-value targets without further human input. Unit 42's own assessment is blunt: exploitation was blocked only by target-side configuration requirements, missing auto-login on Langflow and required authentication on n8n forms. Targets with slightly weaker defaults would have been exploited. That's a narrow margin between "autonomous campaign that failed" and "autonomous campaign that succeeded at scale," and it's not a margin defenders should count on twice. The operational security failure is its own lesson: the same autonomy that let the actor scale up also generated the exact kind of exposed session data that got the whole operation caught.

What to Do

Treat externally reachable workflow, notebook, and AI-agent interfaces as priority attack surface, specifically Langflow, n8n, Marimo, and any customer-managed NetScaler systems used as SAML identity providers. Patch to the fixed versions for each of the CVEs involved (n8n's fixes landed in 1.121.0 and 1.120.4 respectively) and remove any exposure that isn't operationally necessary. Don't rely on "the exploit needs a specific configuration we don't have" as a durable defense, that's exactly the gap this actor's tooling is built to keep searching for. Assume internet-facing developer and automation tools will be probed continuously for both configuration mistakes and known exploit chains, and monitor for unusual outbound connections or newly-started file servers on infrastructure that shouldn't be running one.

An AI agent that fails politely and moves to the next target is still a working intrusion tool. The fact that this one got caught by its own mistake doesn't mean the next one will.