In early 2026 Project Zero revisited CVE-2024-54529 in the Sound Barrier series

On January 30, 2026 Google Project Zero published Part II of its Sound Barrier series, revisiting CVE-2024-54529, a type‑confusion vulnerability in the com.apple.audio.audiohald Mach service that is part of the CoreAudio framework and used by the coreaudiod system daemon.

The vulnerability resides in certain Mach message handlers, including _XIOContext_Fetch_Workgroup_Port, which fetch a HALS_Object from the Object Map and treat it as an ioct type without checking the actual object type. Because the code assumes the fetched object is of the expected type, it can read or write memory outside the intended bounds, creating an out‑of‑bounds condition that attackers may attempt to exploit.

Project Zero researchers said they uncovered both CVE-2024-54529 and a separate double‑free flaw tracked as CVE-2025-31235 in the coreaudiod daemon by applying a method they call knowledge‑driven fuzzing. Knowledge‑driven fuzzing guides the fuzzer with prior knowledge of HAL object types and Mach message formats, focusing the search on logical weaknesses rather than relying on random mutations alone.

This approach increases the likelihood of finding bugs such as type‑confusion and double‑free issues in complex services like coreaudiod, according to the researchers’ description of the technique. The researchers added that knowledge‑driven fuzzing helped them discover the type‑confusion flaw and the double‑free issue, underscoring the method’s effectiveness in uncovering security‑relevant vulnerabilities in macOS system components.

For CVE-2024-54529, Project Zero described it as a type‑confusion vulnerability in the audio HAL that allows an attacker to manipulate memory through uninitialized fields in the ngne object type, a data structure used to represent audio nodes within the HAL. The ngne object is not fully zero‑filled during allocation, leaving a six‑byte gap at offset 0x68 that attackers can fill with attacker‑controlled data.

By writing controlled data into this gap, an attacker can influence later memory operations performed by the daemon and steer the daemon to run malicious code. To increase the chances of landing execution‑control data at a predictable address, the exploit invokes the HALS_Object_SetPropertyData_DPList API to feed Property Lists into coreaudiod, a technique used for heap feng shui and mass‑allocation of controlled data.

Heap feng shui shapes the layout of heap allocations so that a crafted return‑oriented programming chain can reliably jump to a gadget that ultimately transfers control to the attacker’s payload. Project Zero researchers built a working exploit for CVE-2024-54529 and tested it on macOS Sequoia 15.0.1, employing a heap spray and a ROP chain to achieve arbitrary code execution.

The exploit succeeded on that version, granting the attacker the privileges of the coreaudiod process, which runs with elevated rights and can interact with hardware audio devices. In macOS Sequoia 15.0.1 the smallest HALS_Object type, stap, is 0x70 bytes, a size that prevents the out‑of‑bounds read that was possible in earlier releases such as macOS Ventura 13.1.

Apple addressed the flaw by releasing security updates for macOS Sequoia 15.2, macOS Sonoma 14.7.2 and macOS Ventura 13.7.2 on December 11, 2024. The updates removed the risky code path in the CoreAudio stack that had allowed the type‑confusion to be exploited. Apple said the patches fixed the flaw in the com.apple.audio.audiohald Mach service, which provides the coreaudiod system daemon and handles audio processing across the operating system.

The company noted that the updates were applied to the three currently supported releases at the time, ensuring a broad base of Mac users received the fix. Following the patch, Security Arsenal issued a detection and hardening guide for CVE-2024-54529 on April 15, 2026, offering defenders recommendations on how to spot potential exploitation attempts and strengthen audio‑related components on macOS systems.

The guide observed that, while the patches closed the immediate code‑execution path, the underlying pattern of fetching objects from a global map without type checking remains in other audio‑related Mach interfaces, indicating that similar flaws could exist elsewhere in the system. Project Zero researchers said they are already scanning other audio‑related daemons for analogous type‑confusion sites, using the same knowledge‑driven fuzzing approach that led to the discovery of CVE-2024-54529 to proactively identify potential weaknesses before they are exploited.

They added that any service that retrieves objects from a global map without verifying the concrete class is a candidate for the same knowledge‑driven fuzzing strategy, highlighting a broader class of bugs that could be found with similar techniques. Timeline of key events

• May 10, 2018: GitHub repository p0tools/CoreAudioFuzz/exploit uploaded, containing early work on CoreAudio fuzzing.
• December 11, 2024: Apple released patches for CVE-2024-54529 in macOS Sequoia 15.2, macOS Sonoma 14.7.2 and macOS Ventura 13.7.2.
• January 30, 2026: Google Project Zero published Part II of the Sound Barrier series, revisiting CVE-2024-54529 and detailing the exploit.
• April 15, 2026: Security Arsenal released a detection and hardening guide for CVE-2024-54529.

What has changed since the Part II report The January 2026 Project Zero publication brought detailed technical insight into the exploit chain, which advisories had only briefly described. Since the December 2024 patches, no public reports of successful exploitation of CVE-2024-54529 in the wild have emerged, suggesting the updates mitigated the immediate risk for most users. The April 2026 hardening guide from Security Arsenal added defender‑focused advice, shifting the conversation from pure exploit description to practical detection and mitigation steps for macOS audio services.

Project Zero’s continued use of knowledge‑driven fuzzing on other audio‑related daemons signals an ongoing effort to uncover similar type‑confusion issues before attackers can weaponize them. Taken together, the timeline shows how a vulnerability discovered through guided fuzzing moved from private research to public disclosure, patching and post‑patch guidance within a span of just over a year.