TL;DR
Oligo Security Research has discovered a new set of vulnerabilities in Apple’s AirPlay Protocol and the AirPlay Software Development Kit (SDK), which is used by third-party vendors to integrate AirPlay into third-party devices.
The vulnerabilities enable an array of attack vectors and outcomes, including:
- Zero-Click RCE
- One-Click RCE
- Access control list (ACL) and user interaction bypass
- Local Arbitrary File Read
- Sensitive information disclosure
- Man-in-the-middle (MITM) attacks
- Denial of service (DoS)
These vulnerabilities can be chained by attackers to potentially take control of devices that support AirPlay – including both Apple devices and third-party devices that leverage the AirPlay SDK.
The vulnerabilities and the attack vectors they enable have been named “AirBorne” by Oligo Security researchers, as the attacks that they make possible are transmitted via wireless networks or peer–to-peer connections, and allow attackers to fully take over devices and use that access as a launchpad for further exploitation.
Oligo has demonstrated that two of the vulnerabilities (CVE-2025-24252 and CVE-2025-24132) allow attackers to weaponize wormable zero-click RCE exploits. This means that an attacker can take over certain AirPlay-enabled devices and do things like deploy malware that spreads to devices on any local network the infected device connects to. This could lead to the delivery of other sophisticated attacks related to espionage, ransomware, supply-chain attacks, and more.
Because AirPlay is a fundamental piece of software for Apple devices (Mac, iPhone, iPad, AppleTV, etc.) as well as third-party devices that leverage the AirPlay SDK, this class of vulnerabilities could have far-reaching impacts.
For perspective:
- While not every Apple device worldwide is vulnerable to RCE via AirBorne, Apple stated in January 2025 that there are 2.35 billion active Apple devices across the globe.
- In 2018 Apple indicated that there were over 100 million active MacOs users globally.
- Other Apple devices like iPhones, Apple TV, vision pro are affected by different AirBorne vulnerabilities. Devices like iPhones require users to enable the AirPlay receiver in the phone settings.
- Additionally, the number of third-party audio devices that support AirPlay can be estimated in the 10s of millions.
- While the exact number of CarPlay-enabled devices is not known, it is widely-used and available in over 800 vehicle models.
Apple and Oligo have worked together to thoroughly identify and address the vulnerabilities with the goal of protecting end-users. Apple has released its latest versions of software to address the vulnerabilities and has allowed time for those devices to be updated. Throughout the responsible disclosure process, Oligo provided Apple with the relevant documentation, processes and code associated with these vulnerabilities.
Oligo disclosed 23 vulnerabilities to Apple in total, leading to 17 CVEs being issued. A complete list and description of these CVEs, as well as specific attack scenarios they enable, can be found below.
Types of Attacks
The vulnerabilities found by Oligo - independently or chained together - can enable a variety of possible attack vectors, including Remote Code Execution (RCE), Access Control List (ACL) and user interaction bypass, Local Arbitrary File Read, Sensitive Information Disclosure, Man-in-the-Middle (MITM) attacks, and Denial of Service (DoS) attacks.
For this document we have chosen to focus on RCE attacks on devices using MacOS, the AirPlay SDK, and CarPlay. In future posts, we may examine other types of attacks and other devices relating to AirPlay.
Remote Code Execution (RCE) Attacks
Using AirBorne, attackers can achieve RCE on vulnerable devices, based on certain factors, such as Apple and third-party device settings, as well as user preferences.
To provide examples, below are some of the different RCE attacks that are possible for devices configured with different settings.
MacOS - Zero-Click RCE
CVE-2025-24252 is a use-after-free (UAF) vulnerability that can be used as a UAF or manipulated into an “arbitrary free” action that enables an attacker to execute code remotely on MacOS devices.
When CVE-2025-24252 is chained with CVE-2025-24206 (user interaction bypass), it allows for a zero-click RCE on MacOS devices that are connected to the same network as an attacker with the AirPlay receiver on and set to the “Anyone on the same network” or “Everyone” configuration. The vulnerability allows for wormable exploits under these circumstances, given it enables an attack path that can spread from one machine to another with no human interaction.
A potential scenario: a victim device is compromised while using public WiFi, then connects to their employer’s network – providing a path for the attacker to take over additional devices on that network.
The below video demonstrates our “write-what-where” primitive in action, overwriting the Music app in real time. We opted to include an extra click to launch the application so that you can clearly see the effect. Because our primitive can target any memory address, there are many ways to exploit this use-after-free that do not require opening an application.
MacOS - One-Click RCE
CVE-2025-24271 is an Access Control List (ACL) vulnerability that can enable an attacker to send AirPlay commands without pairing. When CVE-2025-24271 is chained with CVE-2025-24137, it allows for a one-click RCE on MacOS devices that are connected to the same network as an attacker with the AirPlay receiver on and set to the “Current User” configuration.
NOTE: CVE-2025-24137 was patched by Apple in macOS Sequoia 15.3 on January 27, 2025:
AirPlay SDK - Speakers and Receivers - Zero-Click RCE
CVE-2025-24132 is a stack-based buffer overflow vulnerability. This vulnerability allows for a zero-click RCE on speakers and receivers that leverage the AirPlay SDK. These devices are vulnerable to zero-click RCE under all configurations. The vulnerability allows for wormable exploits under these circumstances, given it enables an attack path that can spread from one device to another with no human interaction.
Examples of successful attack outcomes include more playful actions like displaying an image on the device or playing music, to more serious actions like using the device’s microphone to listen to nearby conversations, such as eavesdropping via a device in a high-profile conference room.
Car-Play Devices - Zero-Click and One-Click RCE
CVE-2025-24132 is a stack-based buffer overflow vulnerability and also applies to CarPlay devices. This vulnerability allows for a zero-click RCE under certain conditions. Examples of attack outcomes include distracting drivers through image display and playing audio, or potentially actions like eavesdropping on conversations and tracking a vehicle’s location.
- WiFi Conditions: Using the WiFi hotspot in the CarPlay device, an attacker could execute an RCE attack given that they are in close proximity to the CarPlay unit. If the device has a default, predictable or known wifi hotspot password, it is possible to gain access and then execute the RCE.
- Bluetooth Conditions: Some CarPlay device vendors exchange the WiFi credentials via Bluetooth over the IAP2 protocol, requiring a PIN to pair devices. An attacker could execute an RCE attack given that they are 1) in close proximity to the CarPlay unit, and 2) be able to see and enter the pin displayed on the AirPlay device. In some cases, this is a one-click RCE, as a click may be required by the victim.
- USB Conditions: Non-wireless CarPlay devices are vulnerable via physical connection (USB).
Examples of attack outcomes include distracting drivers through image display and playing audio, to more nefarious actions like eavesdropping on conversations and tracking a vehicle’s location.
Other Attacks
Because of the potential impact of the RCE vulnerabilities, this document is primarily focused on providing details on them.
However, as mentioned, other attack vectors and exploits beyond RCE are possible using this set of vulnerabilities. These include Remote Code Execution (RCE), Access Control List (ACL) and user interaction bypass, Local Arbitrary File Read, Sensitive Information Disclosure, Man-in-the-Middle (MITM) attacks, and Denial of Service (DoS) attacks.
We may be providing more information and insight on these other attack vectors and exploits in future blogs and presentations.
Why we looked at AirPlay
We started this research following our work on the 0.0.0.0 day vulnerability. While scanning for open ports that may be accessible by 0.0.0.0 we noticed that most of the devices on our internal network had the AirPlay port 7000 open. Curious to understand the protocol, we started looking at the basic commands the AirPlay server handles. To our surprise, many protocol commands were fully accessible in the default settings. During our initial look at the protocol, we noticed some patterns within the command that handles flows that were effectively “code smell”. These questionable flows led to us digging in further and carrying out this extensive research.
Technical Overview
How The Attack Vector Works
AirPlay communicates over port 7000 using a proprietary API that blends aspects of HTTP and RTSP protocols. In this system, many commands, especially those requiring additional parameters are sent as HTTP data payloads encoded in the plist format.
A property list, or plist, is a structured data format widely used within the Apple ecosystem to serialize and store data. plists represent data as a hierarchical collection of key-value pairs, allowing for the organization of complex information. They support various data types, including strings, numbers, dates, booleans, arrays, and dictionaries, and can be serialized in either XML or binary format.
Apple’s Core Foundation APIs play a crucial role in handling plist files. These APIs provide comprehensive functionality for reading, writing, and serializing plists.
Since plists are the main way of sending arguments to the AirPlay receiver, understanding them and their structure is crucial for understanding the protocol. Moreover, many of the vulnerabilities directly relate to the plist argument parsing flows.
One example of a type-confusion vulnerability caused by improper handling of the plist parameters is CVE-2025-24129. Since it was already published In January we feel comfortable sharing some technical details about it. Technical details for the rest of the vulnerabilities including ones that were published today will be at a later post after we are sure that most users are updated to the latest version and are no longer affected.
Type Confusion demonstrated using CVE-2025-24129
URI: /getProperty
Method: POST
The getProperty command in AirPlay is used to retrieve specific properties or settings from the receiver, such as current volume levels or device name.
The method CFPropertyCreateWithData creates a propertylist from the HTTP data sent by the client. The method can return different CFType values depending on the data provided by the user (CFArray/CFString etc).
As we can see in the image above, a property list is created using CFPropertyListCreateWithData the type (CFType) of the resulting plist is not checked and assumed to be a dictionary.
If the created plist is not a CFDictionary - Calling methods like CFDictionaryGetValue with the plist, will crash the process.
Exploitability: CFDictionaryGetValue is part of the CoreFoundation library, making the exploitability of this issue dependent on the CoreFoundation version. The difference in exploitability between core foundation versions is true for most of the type confusions we found
Vulnerabilities that did not receive CVE-IDS
The Oligo Security research team reported 23 vulnerabilities to Apple. All of the flaws have ultimately been fixed, but not all of them received CVE-IDs. In some cases, Apple has grouped certain vulnerabilities into a single CVE based on their remediation method and time of resolution, rather than by vulnerability type, impact, or location in the AirPlay Protocol code.
Two examples of vulnerabilities and did not receive CVE-IDs are below.
/setProperty Route Crash
URI: /setProperty
Method: PUT
Configurations: All
User Interaction: 1 click to accept connection
The setProperty command in AirPlay allows the sender to configure specific properties or settings on the receiver, adjusting elements like volume, playback options, or other device-specific features.
Most AirPlay POST/PUT commands expect an HTTP request with data formatted as a plist.
The server expects a value key in the /setProperty plist payload
The value variable is used to create the response without checking if it is null:
If the user did not send the value key in the request, it will remain null.
Calling CFDictionarySetValue with null results in an unhandled exception causing the ControlCenter process to crash.
Remote user logout using WindowServer Crash
The SETUP method in AirPlay, which uses RTSP (Real-Time Streaming Protocol), is part of the process that initiates a media stream from an AirPlay sender (such as an iPhone/iPad) to a receiver (such as an Apple TV).
Sending multiple SETUP commands creates multiple video streams. Since the number of streams is not limited we can create streams in a while loop. Sending many streams will increase the memory consumption and response time of the WindowServer service. After a few seconds of sending the SETUP commands, the watchdog kills the WindowServer service, logging out the user.
This vulnerability allows attackers on the network to remotely log out a user on the same network or in close proximity.
AirBorne Vulnerabilities
AirBorne exposes devices to multiple attacks, with the vulnerabilities each posing unique security risks. Below, we analyze each category of what the vulnerabilities allow and the potential impact.
ACL and User Interaction Bypass
AirPlay uses two main features to handle permissions:
- ACL -- limits access based on the AirPlay Receiver configuration.
- Click to Accept – certain actions require users to click “Accept” and approve an AirPlay connection
We discovered multiple ACL bypass vulnerabilities and issues and one user interaction bypass issue that makes many exploits possible with AirBorne vulnerabilities when a macOS device is configured to the default settings of AirPlay receiver on and set to “Current User”.
CVE-2025-24206 also makes many attacks zero-click by bypassing the “Accept” click requirement.
User interaction bypass
ACL issues and bypass
Remote Code Execution (RCE)
The most severe vulnerabilities in the bundle enable remote code execution, allowing attackers to completely take over vulnerable devices. These vulnerabilities are what makes AirBorne wormable. After compromising one device, attackers can use the same vulnerability to propagate to other devices and networks, furthering their impact and damage.
Below are the vulnerabilities that can be used to take over devices (RCE).
Local Arbitrary file Read
Another vulnerability allows local users to read files belonging to other users. By leveraging this flaw, attackers could read sensitive data, extract credentials, or potentially gain control over processes running with higher privileges.
Sensitive Information Disclosure
Another critical flaw can lead to the exposure of sensitive data over the network. This flaw exposes sensitive log data to any user on the network allowing attackers to fingerprint devices and obtain sensitive information about users and devices.
Vulnerabilities that can be used to obtain sensitive data:
Additional Vulnerabilities
The following vulnerabilities enable a variety of different actions for attackers, such as denial of service (DoS). Given the high number of CVEs associated with AirBorne, it was not possible to carry out extensive research into potential exploitability.
While the vulnerabilities described above can have various impacts, crashing the AirPlay server creates an opening for a man-in-the-middle attack. For example, let’s consider a board meeting that is just starting. The CEO wants to AirPlay the meeting to the TV in the office. Attackers can use one of the DOS vulnerabilities to:
- Exploit one of the DOS vulnerabilities to crash the TV’s AirPlay receiver
- Spoof the TV’s identity on the network using mDNS
- Wait for the CEO to start streaming to the fake AirPlay server
- Relay the CEO’s stream from the fake server back to the real TV
- Capture and record the entire meeting’s content from the intercepted stream
How to Protect Yourself
For organizations, it is imperative that any corporate Apple devices and other machines that support AirPlay are updated immediately to the latest software versions. Security leaders also need to provide clear communication to their employees that all of their personal devices that support AirPlay need to also be updated immediately.
Our suggested remediation steps
- Users are advised to update their devices to mitigate potential security risks.
- Disable AirPlay Receiver: We recommend fully disabling the AirPlay receiver if it is not in use.
- Restrict AirPlay Access: Create firewall rules to limit AirPlay communication (Port 7000 on Apple devices) to only trusted devices, enhancing network security and reducing exposure.
- Restrict AirPlay Settings: Change the “Allow AirPlay for” to “Current User”. While this does not prevent all of the issues mentioned in the report, it does reduce the protocol’s attack surface.
Responsible Disclosure and Thanks
Thank you to Apple’s security team for working with us throughout the responsible disclosure process and for promptly addressing these vulnerabilities in AirPlay-enabled devices.
About Oligo Security Research
Oligo Security Research is a group of experienced threat researchers with a focus on finding new vulnerabilities and attack vectors in the different kinds of software that power the world. Some of the team’s most notable discoveries include: the first known attack campaign targeting AI workloads exploited in the wild (ShadowRay), a nearly 20-year old bug in popular web browsers that enabled RCE (0.0.0.0 Day), and shadow vulnerabilities in popular AI frameworks, including Meta-Lllama, Ollama. You can view all of the team’s recent work here.
Media Inquiries
For any questions about these or other vulnerabilities uncovered by Oligo Research, please contact press@oligosecurity.io.
