I'd get more clicks, likes, shares, and comments if I cast Apple as the villain here, in some sort of adversarial simplified hero arc story.
The story of the cluster of security vulnerabilities in Apple's AirPlay system is more interesting, than that!
It should be a wake-up call for other makers of IoT (Internet of Things) devices; basically anything that runs a software system and talks to a network.
Security researchers at Oligo Security discovered about two dozen defects of various types in devices supporting AirPlay, including two RCE (remote command execution) vulnerabilities in the AirPlay service itself (CVE-2025-24252 and CVE-2025-24132) which are "wormable". (I'll circle back here and post a link to their report in the comments below.)
Wormable means that malicious software could infect a device and use it as a platform to probe and infect other devices.
These types of defects are basically the worst case scenario for the vendor of any widely-used software system. Not only would many or possibly all of your customers be adversely affected, but your platform could be used to attack any other devices, too.
As the first step in mitigating potential damage, Oligo Security reported their findings to Apple, who then issued software updates to fix the defects in their systems including iPhone, Mac, Vision Pro, HomePod, Apple TV, iPad, and even Apple Watch.
Apple has a robust system for delivering software updates to the devices they sell, and customers can even opt-in to automatic system updates, so why is this not the end of the story?
Defects discovered. Defects patched. Done, and done!
Apple's not the only vendor shipping products that use AirPlay.
AirPlay is more than a feature of an iPhone.
AirPlay is:
🟠 a protocol
🟠 an AirPlay SDK (software development kit)
🟠 a marketplace of many vendors and devices
Patching the phones, tablets, and laptops, goes a long way toward mitigating the potential for a worm, because those are the vectors, they move around from network to network.
Still, hundreds of millions of other devices including tv, stereo, speakers, and car entertainment systems, made by companies other than Apple, implement AirPlay.
Some of those vendors use an implementation of the AirPlay software provided by Apple (recently patched versions: AirPlay audio SDK 2.7.1 and AirPlay video SDK 3.6.0.126 released to MFi Program on March 31, 2025).
When the AirPlay 2 SDK was designed (circa 2018) the state of the art for the embedded systems market was such that highly portable software modules were written in either "vanilla" C or the object oriented C++.
The AirBorne defects include several related to memory management, such as buffer overflows.
In recent years Apple has been keen to promote the use of memory-safe languages like Swift, which can prevent defects like this from lurking in software systems like AirPlay.
It's likely the AirPlay team is already looking at their options for rebuilding the next version of AirPlay in a memory-safe language.
Although Swift is clearly Apple's memory-safe language of choice, the need to provide AirPlay client software for vendors implementing AirPlay on many operating systems including BSD, Linux, and Windows might nudge Apple into a different choice, for AirPlay 3, maybe Rust or a language more closely derived from C.
Every firmware team should be thinking about how to migrate their firmware from C or C++ to memory-safe languages, sooner, rather than later.