Vulnerability Safari: How a Bug in WebAssembly Bypasses Same-Origin Policy

The discovery of a critical bug in Safari that violates the Same-Origin Policy

When Anthropic presented Mythos and Project Glasswing, reactions were immediate and polarized. Some dismissed the news as mere fear-based marketing, while others considered it a credible change in the threat landscape. The truth, probably, lies in between. I decided to test this situation for myself, taking advantage of recent access to OpenAI's Trusted Access for Cyber program. I found that GPT-5.4 identified the bugs and helped assemble a working exploit chain. However, it was not just a matter of a prompt like "create an exploit for me." It required guiding it with domain-specific knowledge, iterative probing, and the ability to recognize which paths were actually exploitable.

The context of security in modern browsers

In modern versions of browsers like Safari, exploitation is less about discovering bugs and more about discovering bugs that are still relevant after numerous layers of defense. The bug I will discuss today falls into a particularly interesting category: it does not provide a path for remote code execution (RCE) or sandbox escape, but rather crosses a different boundary, violating the Same-Origin Policy. If I had visited a malicious page from any Apple device, it could have read authenticated cross-origin data from other sites you use, including access tokens and other sensitive information, making account theft trivial.

The matryoshka structure of the sandbox

Exploiting browsers in 2026 is very similar to being trapped in a Russian matryoshka doll. You start in the smallest matryoshka, and every time you exit a level, you realize you are still trapped in another. Finding a low-level memory bug is not the same as finding an exploit. Many of these bugs "die" in the gap between "memory corruption has occurred" and "something significant has crossed a security boundary."

The bug in the update logic

The original bug resides in the update logic for non-shared, resizable WebAssembly memory. When a WebAssembly.Memory grows in BoundsChecking mode, JavaScriptCore can replace the underlying memory handle. This is not the bug. The bug is what happens afterward due to memory.toResizableBuffer(). Safari updates the buffer metadata after memory.grow(), but leaves m_data pointing to the old freed allocation. As a result, after memory growth, JavaScript can hold a buffer whose reported size and handle are new, but whose actual data pointer still refers to the old freed Primitive Gigacage allocation. This results in a stale typed view onto freed memory.

Why the bug did not seem exploitable initially

The stale view is confined within JavaScriptCore's Gigacage, limiting what can be done with it. Many typical targets never land there, lack useful structure, or produce no cross-boundary effect.

The turning point

Instead of asking myself "how can I get from my stale WASM view to a protected browser state?", I started asking a better question: "What browser code takes data that JavaScript is not allowed to read, but still copies into normal renderer memory?". This narrowed the search space to subsystems that handle cross-origin sensitive data and still allocate ArrayBuffer-backed memory as part of their internal pipeline. This points directly to Fetch.

The mode violation

The surprising part is Response.clone(). If FetchResponse::clone() is called while the response is still loading, WebKit would internally create a readable stream so it can siphon the body between the original response and the clone. The normal body path blocks opaque responses, but the FetchResponse::clone() path does not initially apply the same opaque body check. Once that happens, the bytes of the hidden response start becoming very real renderer objects.

The exploit chain

At a high level, the exploit became: 1. Force the target WASM memory into the BoundsChecking path. 2. Call memory.toResizableBuffer(). 3. Grow the memory. 4. Keep the stale resizable buffer whose pointer still aims at freed Primitive Gigacage pages. 5. Trigger a cross-origin fetch(…, { mode: “no-cors”, credentials: “include” }). 6. Call response.clone() while the response is still loading. 7. Let Fetch internals materialize the hidden body bytes into ordinary renderer ArrayBuffers. 8. Reclaim the WASM-stale-covered pages with those allocations. 9. Read the cross-origin bytes through the stale view.

The file:// detour

One of the strangest parts of the research was that request-side behavior varied depending on where it was launched from. In my testing, cross-origin requests were much easier to trigger from file:// than from a normal https attack page. This seems counterintuitive until you look at how WebKit handles local origins. Document.cpp has explicit special cases around local documents and settings like allowUniversalAccessFromFileURLs and allowFileAccessFromFileURLs.