Discovering Vulnerabilities With Claude

Discovering and exploiting vulnerabilities in critical, real-world software with Claude \ Anthropic Skip to main content Chapter 01 : One-click remote code execution in Chrome

Over the past few months, we’ve used an unreleased, internal research model to find critical vulnerabilities in some of the world’s most widely used software, such as browsers and operating systems. In this post, we share details of five attack chains, which led to remote code execution and other critical impacts with little to no user interaction. These attack chains demonstrate the model’s ability to create sophisticated, multi-step exploits in both open-source and proprietary software. Any vulnerabilities in these products could affect billions of users. They’re also among the most security-critical software in the world, making them a bellwether for testing models’ vulnerability research and cyber capabilities. We reported each vulnerability to the affected vendor under our coordinated vulnerability disclosure , which gives developers 90 days to patch and a further 45 days before we discuss details beyond what is already included in a public advisory. 1. One-click remote code execution in Chrome After initial prompting, Claude wrote a full exploit chain enabling an attacker to execute arbitrary code as the user, outside the browser’s sandbox. Our proof of concept launches the Calculator app from a stock default-configuration Chrome browser on macOS within seconds of the page loading, without any further user interaction: Claude discovered a vulnerability in Chrome’s JavaScript engine, V8, that allowed a malicious web page to corrupt V8’s heap memory. Claude discovered a second vulnerability to break out of V8’s memory region sandbox and defeat ASLR. This step located Chrome’s code in memory and used a return-oriented programming (ROP) chain to take full control of the renderer process. The compromised renderer was confined by Chrome’s process sandbox. Claude then discovered a race condition in CacheStorage. The compromised renderer used the race condition to read memory outside the sandbox and learn the memory layout of the privileged browser process. Finally, Claude discovered a use-after-free in FedCM, Chrome’s federated sign-in feature, that allowed the exploit to execute arbitrary code outside the sandbox.

We have reported our findings to Google: 62 CVEs have been assigned and patched as of Chrome 156 , with all of them rated critical or high severity. Among them are 13 sandbox escapes and 21 vulnerabilities that could have been used to compromise the renderer. 2. A one-click exploit chain in Safari After initial prompting, Claude wrote an exploit chain that let any website’s JavaScript completely bypass the same-origin policy (SOP). The exploit could access a user’s Safari history, cookies, and other sensitive data, and could send authenticated HTTP requests to other domains and read the responses. For example, if the user is signed in to their email account, the attacker can now read their email; if they’re logged into their bank account, the attacker can view account balances or attempt transfers. To do this, Claude defeated several layers of protection built into Safari: Claude discovered a use-after-free (UAF) vulnerability in JavaScriptCore, Safari’s JavaScript engine, which is written in C++. Certain TypedArray operations wrote through stale pointers to freed memory, overwriting TypedArray metadata. WebKit’s Gigacage mitigates this type of attack by isolating TypedArray data in a separate region of memory. Claude discovered that certain variables in this region were used to index into other regions, which gave it an arbitrary read/write primitive outside the Gigacage. All website JavaScript runs in the WebContent sandbox, which keeps bugs like the UAF from reaching sensitive browser data on disk. Claude discovered a vulnerability in the sandbox's IPC mechanism that let the exploit read Safari’s stored history, cookies, and session databases from disk. Finally, Claude used the UAF to overwrite a variable in memory and disable the SOP, allowing the attacker’s page to read data from any other origin.

The chain is interesting because it is a data-only attack that never relies on arbitrary code execution. Instead, it uses full read/write access to the browser process’s memory to modify a security flag, an object size, and a URL. Several of the weaknesses are not vulnerabilities on their own but intended behaviors that become exploitable when combined. Apple acknowledged our report the same day we submitted it and implemented a fix promptly. That fix is available to users. 3. Android lock screen bypass After initial prompting, Claude wrote an exploit that let an attacker extract photos and other personal information from a stolen Android phone without unlocking it. The work combined three methods: source code analysis of the open-source parts of Android, reverse engineering and deobfuscation of the Google Play services binaries, and live testing on a physical Google Pixel 9. This turned up a wide range of vulnerabilities in both the open-source and proprietary components. Claude then chained three of them into the final exploit. Android has several layers of protection against this attack. Claude found a way around each one: A locked Android phone is designed not to transfer data over USB. Claude found that a USB host with a specific setting bypassed this. The device-to-device transfer protocol refuses data commands from unauthorized peers. Claude found a way to skip the authorization check and start the pairing process. Pairing is protected by an authenticated key agreement that asks the user to verify a six-digit code. Claude found a flaw that skipped this verification and behaved as if the user had tapped “Allow.” USB transfers are not supposed to carry file contents, as enforced by a hardcoded check. Claude found a fallback mechanism that sent raw bytes over USB and was not covered by the check. The exploit requested file contents through it.

This issue has been addressed by Google. 4. Windows remote denial of service After initial prompting, Claude wrote an exploit that would have allowed an attacker to remotely crash any Windows machine that responds to HTTP/3 requests using the native Windows implementation. The difficulty in this case was in identifying the vulnerability in the first place. Following that initial prompting, we reported this vulnerability directly to Microsoft,...