AI
From Browser Fuzzing to 23 AirPlay Vulnerabilities
Port 7000 was open on every MacBook in their office. Avi and Uri found that any public website could reach that service via the 0.0.0.0 IP address. They wrote a 20-line Python fuzzer and crashed the Control Center service. That crash led them to report 23 vulnerabilities to Apple between October 2024 and April 2025. Seven of those got CVEs assigned.
Reversing the Protocol: Type Confusion and Null Pointers
The team extracted AirPlay binaries from the macOS dyld cache and reverse engineered the command handler. Two bug classes appeared repeatedly. Type confusion: the server expected a dictionary but accepted any type, crashing the process. Null pointer dereferences: session commands accessed objects before a session was set up. Sixteen of the 23 vulnerabilities were these two types. Apple’s ticketing system blocked them for submitting too many reports at once.
SDK Devices: Stack Overflow in Bose and CarPlay
AirPlay SDK runs on hundreds of vendor devices. Only 2 of the 23 vulnerabilities applied to the SDK, but one was a stack overflow with no stack canaries. Uri simulated a Bose speaker firmware on a Raspberry Pi and used an Arduino to fake the MFI authentication chip. The same exploit gave root privileges on a real Bose home speaker and later on a CarPlay head unit. Both devices share the same vulnerable code.
macOS Use-After-Free: The First Wormable Zero-Click on Mac
The critical macOS bug was a use-after-free in the FairPlay decryption flow. When decryption failed, the encryption context was freed but its pointer stayed in a global storage. Heap spraying replaced the freed chunk with attacker-controlled data, creating a write-what-where primitive. A flag called “is remote control only” suppressed the AirPlay approval popup, making the exploit zero-click. This was the first wormable zero-click RCE on macOS.
Four Attack Vectors: Internet, Intranet, Browser, and Proximity
AirPlay attacks can arrive from four directions. The internet: hundreds of thousands of unpatched AirPlay devices appear on Shodan. The intranet: anyone on the same Wi-Fi can send commands. The web browser: every website can reach AirPlay on localhost through the 0.0.0.0 IP. Physical proximity: Apple’s AWDL interface accepts connections from nearby devices over Wi-Fi or Bluetooth without a shared network. No prompt appears when the bypass flag is set.
Q&A
How did Apple respond to the disclosure? They took it seriously, worked closely with the researchers for over 19 days, and awarded a bounty and a badge. ▶ 34:50
What was the fuzzing setup? A 20-line Python fuzzer that sent commands based on protocol documentation, covering all known network routes. ▶ 37:02
How did they simulate the Bose device? They used publicly available firmware on a Raspberry Pi and an Arduino to emulate the MFI authentication chip. ▶ 37:55
Notable Quotes
port 7000 was open on each and every MacBook in our office Avi Lumelsky · ▶ 4:07
we got root privileges on a home speaker by Bose Avi Lumelsky · ▶ 18:09
the first warmable zero click on Mac OS Avi Lumelsky · ▶ 25:36
if you specify this weird flag, the is remote control only uh flag. So it essentially does not pop up this uh popup Avi Lumelsky · ▶ 25:08
Key Takeaways
- 23 AirPlay vulnerabilities chained into a wormable zero-click RCE on macOS.
- The same code affects macOS, CarPlay, and IoT devices.
- Many AirPlay-enabled devices will never receive patches.
About the Speaker(s)
Avi Lumelsky leads AI security research at Oligo Security. His cybersecurity skills were honed in elite Israeli intelligence units and his work focuses on privacy in the age of AI.