A new vulnerability in Apple’s macOS and iOS systems has been disclosed by Google’s Project Zero, revealing how attackers could exploit serialization to bypass crucial memory protections.
Quick Summary – TLDR:
- Google Project Zero uncovered a vulnerability in Apple’s NSKeyedArchiver serialization framework.
- The flaw could allow attackers to bypass Address Space Layout Randomization (ASLR) protections.
- Exploitation requires crafted serialized data and no memory safety violations.
- Apple patched the issue in its March 31, 2025 security update.
What Happened?
Google security researcher Jann Horn, from the Project Zero team, revealed a novel technique that could enable memory address leaks on Apple devices without using traditional memory bugs or timing attacks. The vulnerability affects both macOS and iOS and takes advantage of how Apple’s NSKeyedArchiver serialization framework handles certain data structures.
Super cool potential ASLR leak via dictionary hashing by @tehjh! https://t.co/JyYUllUiQE
— Natalie Silvanovich (@natashenka) September 26, 2025
Although no real-world exploits were detected, the vulnerability provides an advanced method for attackers to weaken ASLR, a key defense used to protect memory from being predictably targeted.
How the Exploit Works?
The vulnerability hinges on how Apple’s Core Foundation framework manages pointer-keyed data structures. Specifically, it involves the behavior of the CFNull singleton and NSDictionary hash tables when custom hash handlers are not used.
Key Exploitation Techniques:
- CFNull Singleton Exposure: The CFNull object, commonly used in Apple systems, uses its memory address as a hash key. If this hash is not customized, it can leak pointer information.
- NSDictionary Manipulation: Attackers craft NSNumber keys that deliberately align with specific hash buckets. This allows them to predict and track how the data structure behaves.
- Serialization Order Analysis: By re-serializing the data and analyzing the order of the dictionary keys in the output, attackers can infer where objects are stored in memory.
In practice, about 50KB of carefully designed serialized data containing various NSNull and NSNumber keys is sent to an application. When that application deserializes and then re-serializes the content, the returned output reflects patterns that can reveal the memory address of the CFNull singleton.
Why This Matters?
Even though this technique does not directly compromise devices, it creates an avenue for advanced attacks. When combined with other exploits, it could be used to defeat ASLR protections, which are designed to randomize memory layouts and make memory corruption attacks harder to carry out.
By leaking memory addresses, attackers can gain the information needed to perform more accurate and reliable memory exploits, which might otherwise be impossible.
Apple’s Response and Fix
Apple fixed this issue as part of its March 31, 2025 security update. The update includes changes to the serialization framework to prevent object addresses from being used as lookup keys and introduces keyed hash functions to reduce leakage.
Project Zero chose to report the vulnerability directly to Apple rather than through its public bug tracker, citing the lack of clear real-world impact at the time.
Not Just a Theoretical Exercise
While the bug hasn’t been exploited in the wild, its discovery is important. It highlights how seemingly benign design choices, like using object pointers as hash keys, can introduce serious security risks.
The research also builds on earlier work around hash collision attacks and shows how subtle, indirect behaviors in frameworks like NSKeyedArchiver can be repurposed for information disclosure.
SQ Magazine Takeaway
Honestly, this one made me pause. It’s a textbook case of how clever attackers can abuse totally legit features in software to crack open security protections. Even without a real-world exploit, this discovery shows just how important it is to think deeply about how we use pointers, hashes, and serialization. Apple did the right thing by fixing it promptly, but this is a reminder for all developers: even internal app behaviors can create unexpected security gaps.
