Apple’s recent security updates address a critical batch of flaws in its AirPlay protocol—collectively dubbed AirBorne—that could let attackers execute “wormable zero-click” exploits across Apple and third-party devices on the same network. Below we’ll unpack the most dangerous of these CVEs, dive into some of the low-level mechanics, show you how to test your own devices for exposure, and walk through practical mitigation steps. You can find the exact CVE Identifiers in the table, with a link to our annotated CVE report that include a Q & A based on all available data as well as a AI Assistant to consult for mitigation steps.

What Are the AirBorne CVEs?

Researchers at Oligo disclosed 23 vulnerabilities in Apple’s AirPlay protocol and SDK, yielding 17 CVE assignments. The gravest issues allow Remote Code Execution (RCE) without any user click, meaning malware could leap from one device to another—and from home-brew speakers to corporate MacBooks—with no interaction.

Beyond RCE, other CVEs enable Local Arbitrary File Read, Sensitive Information Disclosure, and Denial-of-Service crashes (e.g. flooding RTSP SETUP commands to crash the WindowServer).

A Peek Under the Hood

How AirPlay Parses Data

AirPlay marries HTTP/RTSP transports with Apple’s plist (“property list”) format for structured data. For example, sending a POST to /getProperty carries an XML or binary plist payload:

                POST /getProperty HTTP/1.1
               Host: 192.168.1.42:7000
               Content-Type: application/x-apple-plist

               <?xml version="1.0"?>
               <!DOCTYPE plist PUBLIC "...">
               <plist version="1.0">
                    <dict>
                        <key>property</key><string>volume</string>
                    </dict>
               </plist>

• Type-Confusion (CVE-2025-24129): Oligo found that CFPropertyListCreateWithData can return any CFType, but AirPlay code blindly treats it as a CFDictionary. Passing, say, a CFArray causes a crash or arbitrary memory read/write when CFDictionaryGetValue is invoked on the wrong type.
• Use-After-Free (CVE-2025-24252): A carefully crafted plist triggers a free in one part of CoreFoundation, then reuses the dangling pointer to overwrite function pointers—yielding a full “write-what-where” primitive and zero-click RCE.
• Stack Overflow (CVE-2025-24132): A malformed field in an AirPlay SDK command overruns a fixed-size buffer on the stack, letting attackers inject shellcode into any speaker, receiver, or even CarPlay head unit that implements the SDK.

Testing Your Devices for Exposure

Important: All tests below assume you’re on the same Wi-Fi network as the target device. Never scan or probe networks without permission.

• Scan for Open AirPlay Ports
  AirPlay commonly listens on TCP 7000 (plus 7010–7012 for AirPlay 2). To find devices:

                nmap -p 7000,7010-7012 --open -sV 192.168.1.0/24

• Check Receiver Settings
  1. iPhone/iPad: Settings → General → AirPlay & Handoff → AirPlay Receiver.
  2. macOS: System Settings → Sharing → AirPlay Receiver.
     If set to “Anyone on the same network” or “Everyone,” you’re at greatest risk.
• Send a Malformed plist
  Use curl to probe /getProperty. A device that crashes or responds with an HTTP 500 error may still be on a vulnerable version:

                curl -X POST \
                  -H "Content-Type: application/x-apple-plist" \
                  --data '<?xml version="1.0"?><!DOCTYPE plist><plist><array/></plist>' \
                  http://<DEVICE_IP>:7000/getProperty

• Confirm OS/SDK Version
  1. Mac/iPhone: Check Settings → About → Software Version (must be at least iOS 18.4 / macOS 15.4).
  2. Third-Party Gear: Consult your vendor’s firmware download page—many haven’t patched the AirPlay SDK.

Mitigation & Best Practices

• Update Immediately
  • Apple devices:
    • iOS 18.4+, iPadOS 18.4+, macOS Sequoia 15.4+, tvOS 18.4+, visionOS 2.4+
  • Third-party devices: Apply the latest firmware from the manufacturer.
• Disable the AirPlay Receiver
  If you don’t use AirPlay, switch the receiver off entirely.
• Restrict AirPlay Access
  • In Settings: set “Allow AirPlay for” to Current User only.
  • On corporate networks: firewall TCP 7000 so only known controller devices can connect:

                # example using ufw on Linux-based routers
                sudo ufw allow proto tcp from 192.168.1.100 to any port 7000
                sudo ufw deny proto tcp from any to any port 7000

• Network Segmentation
  Keep IoT and media-streaming devices on a separate VLAN or guest SSID, away from sensitive computers.
• Audit & Monitor
  • Log connections to port 7000.

Final Thoughts

Staying ahead of threats like AirBorne requires more than just one-off patches—it demands continuous visibility into emerging vulnerabilities, expert analysis of attack techniques, and clear guidance on hardening your environment. That’s exactly what BaseFortify delivers: our platform aggregates the latest CVE data, distills deep technical research into actionable playbooks, and issues tailored alerts so you never miss a critical update. Ready to level up your security posture? Register for free today at https://basefortify.eu/register and start fortifying your infrastructure with confidence.

Resources

• Oligo Security Research – “AirBorne: Vulnerabilities in Apple’s AirPlay Protocol and SDK”
• WIRED – “Millions of Apple AirPlay-Enabled Devices Can Be Hacked via Wi-Fi”
• Security.nl – “Apple dicht ‘wormable zero-click’ kwetsbaarheden in AirPlay-protocol”
• Apple Security Updates – AirPlay Patches for iOS, iPadOS, macOS, tvOS & visionOS
• Nmap – Official Site & Documentation