At the recent DefCon conference, we had the opportunity to present Pwn My Ride, a comprehensive exploration of the Apple CarPlay attack surface. With vehicles becoming increasingly connected, the security of in-car systems like CarPlay is critical. Our talk focused on dissecting the protocols that enable CarPlay’s functionality and revealing multiple attack vectors that could be exploited against various CarPlay multimedia systems.
A key focus was CVE-2025-24132, a stack buffer overflow vulnerability within the AirPlay protocol that is exposed when a device connects to the car’s multimedia system. We demonstrated several methods to reach the stage where this vulnerability can be triggered and ultimately exploited on devices that use the AirPlay audio SDK before 2.7.1, AirPlay video SDK before 3.6.0.126, and CarPlay Communication Plug-in before R18.1, and CarPlay Communication Plug-in R18.1. In this post, we share the core findings from our research, providing insight into the risks facing connected car technologies and emphasizing the need for robust security measures.
Understanding CarPlay
CarPlay supports both wired and wireless connections, but our research focuses on wireless CarPlay. At its core, wireless CarPlay is built on the AirPlay protocol.
To establish a wireless connection, the system uses the iAP2 protocol, which operates over Bluetooth. iAP2 plays a crucial role by negotiating the WiFi password for the CarPlay device and triggering the relevant apps to start. Once this negotiation is complete, the iPhone connects to the CarPlay device’s WiFi network.
After that, the iPhone initiates screen mirroring via AirPlay while connected to the CarPlay device’s WiFi. This layered architecture of iAP2 over Bluetooth and AirPlay over WiFi forms the foundation of wireless CarPlay communication and is central to understanding the attack surface we explored.
- The iAP2 protocol is used to exchange WiFi credentials
- After credentials exchange, The AirPlay protocol is used over WiFi to mirror the iPhone screen
iAP2 protocol
Bluetooth Pairing
In order to communicate over bluetooth, devices first need to pair. Bluetooth pairing behaves differently across vendors and operating systems, and that variability matters for security. During pairing, devices advertise capabilities (NoInputNoOutput, KeyboardOnly, DisplayOnly, KeyboardDisplay, DisplayYesNo), but from a user’s perspective this boils down to two experiences: No-PIN (Just Works) and PIN/Passkey (or numeric confirmation).
No-PIN: the phone and device pair automatically, no code is shown or entered, this method provides virtually no protection.
PIN/Passkey: requires a short numeric secret to be entered or confirmed on one or both devices. For our scenario, this adds a prerequisite - the attacker needs to visually see the multimedia screen for the initial pairing.
Through our testing we discovered that many devices and systems still default to Just Works Pairing (No-PIN), which simplifies attacks, making them frictionless and harder to detect.
After pairing, the two devices are accessible to each other's iAP2 bluetooth services with the accessory exposing constant identifiers: the service UUID 00000000-deca-fade-deca-deafdecacaff and the client/iPhone exposing UUID 00000000-deca-fade-deca-deafdecacafe.
iAP2 protocol internals
iAP2 is the Bluetooth transport that negotiates the Wi-Fi password and kicks off Wireless CarPlay. It’s a framing protocol used between the phone and the head-unit so they can open a session, exchange the credentials, and hand off to AirPlay over Wi-Fi.
In iAP2, every packet begins with a distinctive two-byte magic value 0xFF 0x5A, followed by a two-byte field specifying the total packet length. Immediately after comes the control byte, which signals the current state of the connection. In practice, the SYN flag appears only during the initial link synchronization phase, while ACK is present in virtually all subsequent packets to confirm receipt of data.
The sequence number is randomly initialized when a session starts and increases with each message sent. On the other side, the acknowledgement number in a packet reflects the highest sequence number received, ensuring reliable delivery. This structure allows both ends to track progress and request retransmissions when needed.
Each packet also contains a session ID, which determines the logical channel it belongs to:
- 0 for control and authentication,
- 1 for data transfer
- 2 for External Accessory (EA) streams.
To ensure data integrity, iAP2 includes two checksums: one for the header and another for the payload.
def iap2_calc_checksum(buffer: bytes) -> bytes:
if buffer and len(buffer) > 0:
checksum = sum(buffer) & 0xFF
checksum = (0x100 - checksum) & 0xFF
checksum = struct.pack("B", checksum)
return checksum
else:
print("Error: NULL buffer or length is 0!")
return b""
The iAP2 payload has its own structure, beginning with a fixed two bytes 0x40 0x40, followed by a two-byte field indicating the payload length. What follows is the actual payload data.
Once the iAP2 connection is established, this payload space is used to carry iAP2 command messages. These commands drive the higher-level protocol operations, including authentication, device identification, media control, and more.
iAP2 Authentication Flaw
iAP2 uses one-way authentication: the phone authenticates the head-unit, but the head-unit does not authenticate the phone. Put plainly, the car checks that it’s talking to a legitimate device, but the device will accept any client that speaks iAP2. That means an attacker with a Bluetooth radio and a compatible iAP2 client can impersonate an iPhone, request the Wi-Fi credentials, trigger app launches and issue any iAP2 command.
Authentication starts when the client issues the 0xAA00 (authentication start) command. The server replies with its certificate, the client generates and sends a 20-byte random challenge, and the server signs that challenge and returns the signature so far this proves the server’s identity. The weak link is the final step: the client itself then reports the result by sending 0xAA04 for failure or 0xAA05 for success. Because we control the client implementation, we can always send 0xAA05 regardless of whether the server’s signature was actually validated, which makes this flow ineffective at verifying the client.
iAP2 Full Session
Putting it all together: an iAP2 session begins with Bluetooth pairing. Once paired, the accessory sends a link synchronization (SYN) packet, which the client echoes back to confirm the connection parameters. With the link established, the devices can begin exchanging iAP2 commands. Most commands require the devices to first authenticate and identify.
Authentication follows the process described earlier. After successful authentication, the accessory sends its full identification profile to the client, including device details, firmware versions, and supported application protocols.
Only once both authentication and identification are complete can meaningful iAP2 commands flow between the devices. In our case, the first command we issued was RequestAccessoryWiFiConfigurationInformation (0x5702), prompting the client to provide the accessory with its Wi-Fi SSID and password.
RequestAccessoryWiFiConfigurationInformation response containing WiFi credentials.
Param1: SSID
Param2: Password
CVE-2025-24132
CVE-2025-24132 is a stack buffer overflow vulnerability in the AirPlay SDK, discovered by the Oligo Security Research team as part of a bigger research into the AirPlay protocol.
We demonstrated our exploit of CVE-2025-24132 on multiple different devices using the AirPlay SDK achieving remote code execution with root privileges. Although patches for CVE-2025-24132 were published on April 29, 2025, only a few select vendors actually patched. To our knowledge, as of this post, no car manufacturer has applied the patch. For that reason, and in the interest of giving vendors more time to remediate, we are still withholding the full technical details of the vulnerability for now.
The vulnerability is part of the AirPlay SDK, thus vulnerable over wifi. Our research into the iAP2 protocol and the different pairing implementations by different vendors, make this vulnerability a zero click no-auth vulnerability on many devices. Attackers can just pair to a car, authenticate via iAP2, get the WiFi credentials, connect to the car HotSpot and run the stack buffer overflow.
Attack Scenarios
CarPlay-> USB - Wired CarPlay requires physical access
CarPlay->Wireless->WiFi - Many vendors use a predictable or known WiFi password. In this case attacker can simply connect to the device WiFi and run the exploit
CarPlay->Wireless->Not Discoverable - Some devices are not bluetooth discoverable by default. If this is the case user interaction is needed in order for attackers to pair
CarPlay->Wireless->Discoverable->Pin Pairing - If the device does not support the “Just Works” pairing, an attacker needs to see the 4 digit pin displayed on the screen in order to pair. This does not require user interaction in most cases.
CarPlay->Wireless->Discoverable->Just Works Pairing - No prerequisites are required. Attackers can simply pair, get the WiFi password using iAP2, connect to WiFi and run the exploit.
“Not my code” ≠ “Not my problem”
When a vulnerability is discovered in a widely used SDK like Apple’s AirPlay, the challenge isn’t just fixing the bug – it’s ensuring every vendor that depends on the SDK actually implements the fix and gets it to end users. In cars, this is especially difficult. Unlike a phone or laptop that updates overnight, vehicle update cycles are slow, fragmented, and often require a dealership visit or manual USB install. Some head units support over-the-air (OTA) updates, but many still do not.
Even after Apple released a patched SDK, each automaker must adapt, test, and validate it for their own systems – coordinating across head-unit suppliers, internal software teams, and sometimes middleware providers. Each step introduces potential delays and requires robust collaboration.
The result is a long tail of exposure. While high-end models with robust OTA pipelines may be patched quickly, many others take months, years, or never receive the update at all. That leaves millions of vehicles potentially exposed – long after an “official” fix exists.
If your team is navigating these patching challenges, our researchers can help you shorten the cycle and reduce long-term risk.
Demo