Anthropic says Claude found five exploit chains and critical vulnerabilities

Five investigations, not an independent audit

Anthropic has published an account of using an unreleased internal research model to look for vulnerabilities in widely used software. The company describes five exploit chains: one in Chrome, one in Safari, an Android lock-screen bypass, a remote denial-of-service flaw in Windows, and remote command execution in Linux. These are Anthropic’s claims about its own work, not independently verified results in the available documentation.

The report provides technical details and says the vulnerabilities were disclosed to the relevant vendors. Anthropic says the issues described were fixed, but the amount of public detail differs across the five cases and does not support treating every chain as a third-party-reproduced demonstration. The model used was internal and unreleased, so the results do not show that anyone can achieve the same capabilities with a publicly available model.

The important distinction is between discovering a flaw, building a proof of concept, and demonstrating an impact under a specific configuration. The report gives examples of these stages, but Anthropic’s account is not an external assessment of the success rate, resources required, or how well the method generalizes to other products. Nor is it enough to attribute all the analysis, selection, and verification involved in security research to the model alone.

Chrome and Safari: chains that combine multiple flaws

For Chrome, Anthropic describes a chain that began with a memory-corruption flaw in V8, the JavaScript engine. According to the report, the attack proceeded through other defects to cross memory boundaries and browser isolation, eventually reaching code execution outside the sandbox. The demonstration cited by the company opened the Calculator app in Chrome on macOS using the default configuration. That example illustrates the claimed impact under a specific setup; it does not show that every installation or version was vulnerable.

The publication says Google assigned 62 CVE identifiers to the findings and that, as of the report, they had been fixed in Chrome 156; Anthropic describes them as critical or high severity. The company also attributes 13 sandbox escapes and 21 flaws that could have compromised the renderer to this group. These figures are Anthropic’s reported count and should not be read as 62 independent, complete exploit chains.

For Safari, the report describes a different attack: the goal was to bypass the same-origin policy, which normally prevents one website from reading data belonging to other sites. Anthropic describes a combination of a use-after-free in JavaScriptCore, read and write access outside a protected memory region, and a vulnerability in the sandbox’s IPC mechanism. The chain reportedly allowed access to local browser data and changes to a security flag that disabled the same-origin policy. The company specifies that the attack did not rely on arbitrary code execution; it combined memory access with changes to program state.

This case illustrates why an isolated flaw may not explain the full risk. Some of the conditions described may have been intended behaviors that became exploitable when combined with other weaknesses. Anthropic says Apple acknowledged the report and implemented a fix that is available to users. The article does not provide an external assessment of how many users were exposed or the extent of any real-world exploitation.

Android, Windows, and Linux: three targets, three kinds of impact

For Android, Anthropic describes a bypass that reportedly could have extracted photos and other personal information from a locked Pixel 9 phone. The investigation combined analysis of open-source code, reverse engineering of Google Play components, and testing on a physical device. The reported chain crossed several protections involving USB transfers, pairing authorization, code verification, and a check on file transfers. According to the publication, Google addressed the issue. The report does not provide, in the available extract, a complete list of affected versions or exposed devices.

For Windows, the finding was an out-of-bounds read in the kernel’s QUIC implementation. Anthropic says a remote attacker could send a few packets to a server responding to HTTP/3 requests and cause it to crash and restart. The company says Microsoft fixed the flaw and assigned it CVE-2026-33096. The work described relied on analysis of an executable and reverse-engineering tools; the reported impact was denial of service, not remote takeover.

For Linux, Anthropic reports a use-after-free vulnerability caused by a race condition in the kernel networking stack on systems with an MPTCP listener. The alleged chain had two stages: disclose a kernel address, then alter control flow to run a command as an administrator. The company says the vulnerability was assigned CVE-2026-98432, fixed in the project, and backported to maintained stable branches. Anthropic estimates that its proof of concept took about 48 minutes to obtain a kernel address and another five minutes to reach command execution. Those timings describe that demonstration; they are not a general performance guarantee.

The three examples are not interchangeable. The Windows case involved remote service disruption, while the Chrome and Linux examples describe code or command execution under the specified conditions. Android focused on accessing data without unlocking the device. Assessing risk requires considering the product, version, configuration, and installed fixes—not just the severity label.

The method: many scanners, followed by verification

Anthropic attributes some of the findings to a platform that runs numerous analysis agents in parallel. The company says it measures how much each scanner contributes and tracks code coverage. The strategies described include looking for flaws function by function, pursuing specific goals—such as exposure of customer data—and checking whether an application violates its documented threat model.

The report also mentions automated variant analysis: after a finding is confirmed, the system searches for similar cases. Anthropic says findings go through a standardized verification and risk-rating process. This matters because generating a hypothesis about a flaw is not enough to establish that it is reproducible or exploitable. However, the publication does not describe the full acceptance criteria in detail, the number of false positives, or a controlled comparison with human teams or alternative tools.

As advice for developers, Anthropic recommends integrating security scanning into code review as well as addressing known vulnerabilities. The preventive logic is that reviewing new changes may help catch defects before they are incorporated. But a recommendation or automated scan does not guarantee that every flaw will be found or that the resulting software is vulnerability-free. Effectiveness depends on scan coverage, available context, human review, and the team’s response.

The publication also emphasizes scaling compute during testing and using a diverse set of scanners. These are methodological and configuration choices that, according to the company, increased the number of vulnerabilities found in its process. They do not mean that adding resources will always produce better results or that a model will generate correct findings without review. The report’s emphasis on verification itself shows that detection and confirmation are separate stages.

What the report means for defenders—and what it does not show

The most relevant result for security teams is that, according to Anthropic, a model was able to connect multiple flaws in complex products and build proofs of concept with different impacts. Automated research could expand the ability to review code and speed up variant analysis. The same capability also has offensive potential, so the findings reinforce the importance of managing patches, limiting exposure, and testing systems only with authorization.

Anthropic argues that these skills, once concentrated in specialist teams, may now be within reach of models with little human involvement. That is the company’s interpretation of its experiments; the report does not provide an independent comparison quantifying how much human work was required or how much faster the process was than conventional methods. Nor does it show that an inexperienced attacker could easily reproduce the five chains.

The report identifies the model as an internal research system that has not been released. These results therefore should not automatically be applied to public Claude models or taken to mean that a publicly accessible interface will behave the same way. Tool access, compute time, initial information, safety limits, and human supervision can all substantially change the outcome.

Caution is especially important when comparing this publication with other security incidents. Anthropic’s report about vulnerabilities in third-party products does not confirm that an external company breached Anthropic’s internal systems, and it provides no information about an alleged Cathedral attack. These are separate matters. The available information here is not enough to establish who accessed which systems, how long it took, or what data may have been obtained.

For organizations managing software, the practical takeaway is not to assume that a model will find every flaw. Maintain an asset inventory, install updates, review exposed components, and validate findings in an authorized environment. Teams can use automated tools as support, while retaining access controls, human review, and coordinated disclosure procedures. The report offers specific examples of risks and fixes Anthropic says were communicated; it is not a security guarantee or a universal demonstration of capability.

How to interpret the operational value of these findings

The technical details are useful because they distinguish types of impact and show how flaws can reinforce one another. In a defensive review, a chain may matter more than an isolated defect if it combines a memory vulnerability with a way to cross a security boundary. Even so, response priorities should be based on actual exposure, deployed versions, patch availability, and mitigation options—not just on a striking demonstration.

Teams can use the published findings to check inventories and updates for the affected products, without trying to reproduce a chain against systems they do not own or have permission to test. Any investigation of a vulnerability should take place in a controlled lab, with authorization and versions prepared for testing. Security proofs of concept can cause unintended effects if run in production or against third-party infrastructure.

The recommendation to add reviews to the development process does not eliminate the need for defense in depth. Automated checks can detect known patterns or flag suspicious code, while human analysis provides context and assesses risk. Neither mechanism alone guarantees complete coverage. Their value lies in combining detection, validation, remediation, and follow-up.

In short, the report offers detailed evidence of what Anthropic says it achieved in internal research and of the disclosure and remediation steps it attributes to vendors. It is a relevant signal about the evolution of model-assisted security research, but its scope should remain limited: one company’s results, involving specific systems and an unreleased model, with no independent replication documented in the available sources.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.