When Anthropic unveiled Mythos and Project Glasswing, the reaction was immediate and polarized. Some dismissed it as fear-driven marketing, while others treated it as a credible shift in the threat landscape.
Like with many things, the truth is probably somewhere in the middle. I wanted to test that for myself, and since I recently got access to OpenAI’s Trusted Access for Cyber program, I decided to take it for a spin.
GPT-5.4 identified the bugs and helped assemble a working exploit chain, but it wasn’t a simple “build me an exploit” prompt. Guiding it required domain knowledge, iterative probing, and knowing which paths were actually exploitable.
On modern browsers like Safari, exploitation is less about finding bugs and more about finding bugs that still matter after multiple layers of defense.
The bug I’m going to talk about today sits in a more interesting category. The bug itself looked contained, and in many ways it was. It did not provide a path to RCE or a sandbox escape. What it did instead was cross a different boundary entirely: it broke the Same-Origin Policy.
If you visited a malicious page from any Apple device, it could read authenticated cross-origin data from other sites you use, including access tokens and other sensitive data, making account takeover trivial.
The video below shows the PoC we sent Apple, demonstrating leakage of sensitive data from both Apple Connect and iCloud / Apple ID endpoints. Although this demo focuses on Apple services, the issue affects all websites. This means that by visiting a malicious website, sensitive data from other domains is at risk of being leaked.
The Sandbox Russian Doll
Browser exploitation in 2026 is a lot like being trapped in a Russian doll.
You start in the smallest doll, and every time you escape one layer you discover you are still trapped inside another one.
Finding a low-level memory bug is not the same thing as finding an exploit. Most of these bugs die in the gap between “memory corruption happened” and “something meaningful crossed a security boundary.”
On the outside you have the browser process model. Even if renderer code goes wrong, the browser is trying very hard to keep that damage inside the web content process.
Inside that you have the web security model: Same-Origin Policy, CORS, opaque responses, cookie scoping, and credential modes. Even if a page can trigger a cross-origin request, the renderer, and especially the Gigacage, should not be able to access the response bytes. Right?…
The Bug
The original bug lives in the refresh logic for non-shared resizable WebAssembly memory.
When a non-shared WebAssembly.Memory grows in BoundsChecking mode, JavaScriptCore can replace the underlying memory handle. That part is not the bug. The bug is what happens after that to the JS-visible resizable buffer returned by memory.toResizableBuffer().
The bug is simple enough that once I saw it, it was hard to unsee it. Safari’s grow path effectively does this:
And the refresh step effectively does this:
After memory.grow(), WebKit updates the buffer metadata, but leaves m_data pointing at the old freed allocation.
So after a grow, JavaScript can hold a buffer whose reported size is new, whose handle is new, but whose actual data pointer still references the old freed Primitive Gigacage allocation.
That turns into a stale typed-array window over freed memory.
On its own, this is already a real bug. But we’re still stuck inside the JavaScriptCore gigacage, effectively sandboxed. Without a second bug to break out into the renderer, it doesn’t chain into anything meaningful. What we have is a solid first-stage primitive, but no real security impact on its own.
Why it did not look exploitable at first
The stale window is confined to the Primitive Gigacage, which immediately limits what you can do with it. Many typical targets either never land there, lack useful structure, or fail to produce any cross-boundary effect.
So early on, it had all the hallmarks of a bug that looks promising but rarely goes the distance:
- easy source-level root cause
- visible stale memory behavior
- real reclaim
- no clean escape path
This is where a lot of low-level browser bugs die.
What changed the problem was a very different framing: maybe I did not need to escape the cage at all.
Maybe I just needed the browser to place something valuable inside it.
The Pivot
Instead of asking “how do I get from my stale WASM view to some protected browser state?” I started asking a better question:
“What browser code takes data that JavaScript is not allowed to read, but still copies that data into normal renderer memory?”
Because that is all I need.
I don’t need to break the abstraction.
I just need the browser to break it for me.
That naturally narrows the search space to subsystems that:
- handle sensitive cross-origin data, and
- still allocate ArrayBuffer-backed memory as part of their internal pipeline
That points straight at Fetch. The Fetch API clearly indicates that the response is opaque, meaning that its headers and body are not available to JavaScript.
Opaque Responses Are Supposed to Be Opaque
At the API level, the Fetch model here is straightforward.
If I do a cross-origin request with:
fetch(url, { mode: “no-cors”, credentials: “include” });
The browser may send the request, including cookies depending on context, but JavaScript receives an opaque response.
That means:
- I can hold the Response object
- but I cannot read the body bytes
And WebKit enforces that in the obvious place:
FetchBodyOwner::readableStream() blocks opaque bodies via isBodyNullOrOpaque().
So at first glance, everything looks fine. The body is hidden. The policy is enforced. Same-Origin Policy survives another day.
Except it does not.
The Fetch Behavior that Broke the Modal
The surprising part is Response.clone().
If FetchResponse::clone() is called while the response is still loading, WebKit will internally create a readable stream so it can tee the body between the original response and the clone.
That internal path does not apply the same opaque-body check first.
And once that happens, hidden response bytes start becoming very real renderer objects.
This is the part that made me stop and stare at the source, because the mismatch is right there.
The normal body path blocks opaque responses:
But FetchResponse::clone() does this while the response is still loading:
That is why it works.
The visible accessor path says “opaque bodies do not get a stream.” The clone path says “if it is still loading, create a stream so both clones can tee it.”
That second path is exactly what I needed.
The data flows through normal ArrayBuffer creation paths:
- buffered chunks go through tryCreateArrayBuffer()
- later chunks go through takeAsArrayBuffer()
- shared buffer data gets copied into ordinary ArrayBuffer allocations inside the renderer
So the policy ends up split in two:
- the public Fetch API says the body is opaque
- the renderer still materializes the opaque body into readable byte arrays during clone-time streaming
Combined with the stale WASM window, it becomes a SOP break.
The Chain
At a high level, the exploit became:
- Force the target WASM memory into the BoundsChecking path.
- Call memory.toResizableBuffer().
- Grow the memory.
- Keep the stale resizable buffer whose pointer still targets freed Primitive Gigacage pages.
- Trigger a cross-origin fetch(…, { mode: “no-cors”, credentials: “include” }).
- Call response.clone() while the response is still loading.
- Let Fetch internals materialize the hidden body bytes into ordinary renderer ArrayBuffers.
- Reclaim the stale WASM-covered pages with those allocations.
- Read the cross-origin bytes through the stale view.
That is the entire trick.
I never needed response.text(). I never needed response.arrayBuffer(). I never needed the public API to hand me the body.
The browser copied the body into memory for its own internal bookkeeping, and the stale WASM view read it directly.
That is why this bug stopped being “some weird WASM UAF” and became “this completely breaks the Same-Origin Policy.”
The file:// Detour
One of the weirdest parts of the research was that the request side behaved differently depending on where I launched it from.
In my testing, cross-origin requests were much easier to get moving from file:// than from a normal https attacker page.
That sounds backwards until you look at WebKit’s handling of local origins.
Document.cpp has explicit special-casing around local documents and settings like:
- allowUniversalAccessFromFileURLs
- allowFileAccessFromFileURLs
MiniBrowser exposes those knobs too, which made file:// very useful as a research environment. It let me focus on the memory side and confirm the leak path before I had a clean web-facing story.
But I did not want a local-file party trick.
I wanted a real web exploit.
And from a normal https page, the same request pattern was not giving me the reliability I wanted.
That is where about:blank saved me.
Why about:blank saved the final POC
The final PoC opens an about:blank popup and performs the fetches from there:
This ended up mattering a lot.
At first I thought this was just an origin-inheritance trick. That part is real:
So about:blank does inherit the opener’s origin.
But that alone does not explain why the popup path behaved differently.
What actually seems to matter is Safari’s cookie / first-party bookkeeping. Fetch subresource requests copy document->firstPartyForCookies() into the request:
And WebKit’s cookie blocking logic bails out immediately if that first-party domain is empty:
That is a very different path from a normal attacker-controlled https page. From a regular https://attacker.example origin, the first party is the attacker site, so a request to the victim site looks third-party and Safari’s tracking-prevention logic can suppress cookies.
From the about:blank popup path, the security origin still comes from the opener, but the popup’s top-level URL / first-party context is no longer a normal registrable https site in the same way. In practice, that was enough to make credentials: “include” requests behave differently and get me the authenticated traffic pattern I needed.
So the important point is not “about:blank disabled CORS.” It did not. The important point is:
- the popup kept the opener’s origin
- the request still went through normal Fetch/CORS code
- Safari’s first-party cookie logic treated that popup context differently
That was the difference between “cross-origin request happens but is useless” and “cross-origin request comes back with authenticated bytes worth stealing.”
Why this was fun
This is my favorite kind of browser bug.
Not because the root cause was complicated. It was not. The WASM bug was almost embarrassingly direct.
And not because the final chain was huge. It was not.
It was fun because it is exactly the kind of bug modern browser architecture is supposed to suppress.
A stale pointer inside a cage is supposed to stay a stale pointer inside a cage.
An opaque response is supposed to stay opaque.
Those are both reasonable assumptions.
The exploit works because both assumptions were true only locally.
JavaScriptCore gave me a stale view that looked hard to use. WebCore Fetch gave me sensitive bytes that looked impossible to read.
Put them together and Safari’s Same-Origin Policy fell apart.
Disclosure
We reported our findings to Apple. Shortly after, a fix shipped, suggesting the issue was already known internally.
The vulnerability (CVE-2026-20664) is addressed in iOS 26.4 and iPadOS 26.4 (23E6254 and later), and macOS Tahoe 26.4 (25E253 and later). Make sure your systems are up to date.
Closing Thoughts
The biggest thing on my mind after working with these models is the leverage they provide, and what that means for N-days. A security patch in popular software used to hide the underlying exploit behind time, effort, and expertise. Now that you can scale tokens instead of effort, that barrier is mostly gone.
This doesn’t turn exploitation into a trivial task. You still need someone who understands what they are looking at, can filter noise, and can steer the process when it stalls. But AI changes the unit of work. Instead of deep, sequential effort, you get parallel exploration and rapid iteration. The constraint shifts from raw effort to how effectively an operator can guide multiple lines of inquiry at once.
`
The post Hacking Safari with GPT 5.4 appeared first on Blog.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Ron Masas. Read the original post at: https://www.imperva.com/blog/hacking-safari-with-gpt-5-4/
Click Here For The Original Source.
