Loading story…
Researchers detailed two Safari WebKit exploitation paths that turned renderer memory corruption into reliable arbitrary read/write primitives on macOS and iOS. Google Project Zero showed how CVE-2020-9802, a JavaScriptCore JIT flaw, could be exploited starting from addrof and fakeobj primitives, then bypass WebKit mitigations including StructureID randomization, the Gigacage, and PACCage. The write-up demonstrated leaking a valid StructureID with a fake JSArray and then abusing TypedArray handling in the DFG JIT to escape the Gigacage and gain fast, stable arbitrary memory access.
Theori separately analyzed a Safari AudioWorklet type confusion introduced in Safari 14.1, where WebKit failed to verify that a returned JavaScript object was a JSAudioWorkletProcessor. That missing type check allowed attacker-controlled objects to be confused and used to corrupt JSArray butterfly pointers, again yielding addrof, fakeobj, and arbitrary read/write capabilities. The exploit reportedly worked on iOS 14.6 and macOS 11.4 even after the source patch was public, highlighting patch-gap risk and reinforcing concerns that existing WebKit hardening measures could still be bypassed in practice.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
Theori published an analysis of a Safari AudioWorklet type confusion vulnerability in WebKit, explaining that the bug was introduced with Safari 14.1 and that a missing jsDynamicCast check enabled memory corruption and exploitation. The write-up said the exploit remained reachable on iOS releases after the patch became public and reportedly worked on iOS 14.6 and macOS 11.4.
Google Project Zero published the second part of its JITSploitation series, detailing how to turn a JavaScriptCore JIT bug tracked as CVE-2020-9802 into stable arbitrary memory read/write in Safari despite mitigations such as StructureID randomization, the Gigacage, and the PACCage.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers detailed **CVE-2022-32792**, a Safari/WebKit JavaScriptCore vulnerability in the `B3ReduceStrength` optimization phase that mishandled integer range analysis for sign-extension operations such as `SExt8`, `SExt16`, and `SExt32`. The flaw, disclosed after Manfred Paul exploited it at Pwn2Own, caused pre-patch code to treat sign extension as effectively preserving the original range, which could wrongly remove overflow and underflow checks from `CheckAdd`, `CheckSub`, and `CheckMul` operations in JIT-compiled code. Apple fixed the issue in WebKit by adding `IntRange::sExt` and updating `rangeFor` so sign extension is modeled correctly. The published walkthrough showed how the bug could be turned from an `Int32` underflow into a bounds-check bypass and out-of-bounds array access, then into corruption of adjacent array metadata; by overlapping double and object arrays, the exploit produced **`addrof`** and **`fakeobj`** primitives that could be extended to arbitrary read/write and eventual code execution in Safari/WebKit.
Jun 29, 2026
Google Project Zero published several vulnerability reports covering memory-safety and type-confusion flaws in major JavaScript engines, including Mozilla **SpiderMonkey**, Google **V8**, and Apple **JavaScriptCore**. The issues described unsafe conditions such as leaked `JS_OPTIMIZED_OUT` values, V8 map migration that failed to respect element kinds and caused type confusion, incorrect garbage-collection assumptions in JavaScriptCore's DFG pipeline, unsafe `ObjectGroup` handling in SpiderMonkey's IonMonkey, and a JavaScriptCore `CodeBlock` use-after-free tied to dangling watchpoints. Project Zero also disclosed a **macOS sandbox escape** involving type confusion in `coreaudiod` and the **CoreAudio** framework, extending the set of reports beyond browser engines into operating-system security boundaries. Taken together, the disclosures highlight recurring exploitation risks from **type confusion**, **use-after-free**, and JIT/compiler logic errors that can enable unsafe code execution, memory corruption, or sandbox bypass across widely deployed platforms.
Jul 12, 2026
Researchers detailed exploitation of **`CVE-2020-6418`**, a type confusion flaw in Google Chrome’s V8 JavaScript engine that affects versions before **`80.0.3987.122`**. The bug lies in Turbofan’s handling of `JSCreate` within `InferMapsUnsafe`, where incorrect side-effect modeling can cause modified object Maps to be treated as trustworthy, skipping required Map checks and enabling out-of-bounds memory access. The write-up shows that a `Proxy` supplied through `Reflect.construct()` can trigger the condition and produce out-of-bounds read/write primitives inside the V8 sandbox. The research further demonstrates a practical exploitation path that avoids the common WebAssembly RWX approach by redirecting a JIT-compiled function’s `code_entry_point` to attacker-controlled immediate values already embedded in executable JIT code. The authors said they recreated the vulnerability in a newer V8 version using the original patch context and completed a demo exploit in `d8`, while a later reference highlights continued public interest in using AI assistance to develop Chrome exploit chains around browser vulnerabilities.
Jun 29, 2026