The iPad Bluetooth crash: CVE-2026-113906

My iPad was actively discoverable and accepting an incoming Bluetooth connection when traffic from a nearby, unpaired peer crashed its Bluetooth service. The trigger did not require an app installed on the iPad. The input arrived over the radio, and the device’s own crash records identified what failed. There was no existing trusted pairing to undo: under those tested connection conditions, the service could be interrupted before one was required.

Apple lists CVE-2026-113906 as a nearby-attacker denial of service caused by a null pointer dereference, fixed through improved validation. It credits Chris Bailey - Short Circuit alone in the entry. The fix is listed in the October 26, 2026 updates for iOS and iPadOS 27.2 and 26.7.2.

Apple uses the same technical description for both Bluetooth identifiers and does not publicly map my Mac and iPad submissions to one identifier or the other. The mobile research below provides context for the two related credits; the release list is specific to CVE-2026-113906.

Apple’s CVE-2026-113906 Bluetooth entry

A disappearing connection was not enough

The mobile report covered an iPad mini 6 running the then-current iPadOS 26.5 release. Its device crash records identified the Bluetooth background service and agreed on the exception, failing location and call chain—the sequence of operations leading to the fault. The records came from separate service processes, so they documented the failure recurring rather than one old crash being counted repeatedly.

That located the fault inside the handling of incoming Bluetooth traffic. A connection dropping could have several explanations; matching device crashes gave me a specific one to investigate. The iPad also had its own binary analysis, which matters when comparing a fault with behavior on another product.

I retrieved diagnostic records after the radio tests. That access was for collecting evidence; the trigger did not require an app installed on the iPad or attacker code running locally. The separate Mac work explained a related code pattern, while the iPad records established the failure on the mobile device itself.

The missing state was the same problem on the smaller screen

Inside the Bluetooth service, the failing operation needed state belonging to an appropriate logical channel. Channels organize different kinds of traffic within a connection, and an operation that makes sense for one kind may be meaningless for another. The software could find the channel being referenced and still be unable to provide the particular state the operation required.

The validator recognized that mismatch and returned no usable object. Its caller then tried to read from the returned value without checking whether it represented an object at all. That is the null pointer dereference in Apple’s advisory. Null can be a perfectly sensible way to communicate that a lookup or validation failed. Trying to read information through it is where the service ran out of options.

The mobile report compared the relevant compiled code with the Mac version. The programs had different layouts, so the numerical locations in the crash records differed. The sequence responsible for using the absent result was structurally the same. That comparison supplied a reason to treat the failures as related beyond the vague observation that Bluetooth had crashed on two Apple products.

Pairing answers a different question

Pairing establishes a trusted relationship between Bluetooth devices. It is the part users tend to recognize: the system agrees to treat a particular peer as one it can remember and reconnect with. A radio connection and the early exchanges needed to manage communication are separate work. Some of that work necessarily happens before the software can assume it is speaking to an already trusted partner.

The affected processing was reachable without that prior pairing in my tested configuration. That does not mean pairing was bypassed or that the test device acquired the privileges of a trusted accessory. It means the service had to process traffic from a peer that had not completed that trust relationship, and it failed to handle the request safely. There was no need to become a trusted device first in order to interrupt the service.

The connection conditions were part of the result

The submission separated the state I directly tested from other normal-use situations that might expose the same processing. The successful mobile tests used an actively discoverable iPad that accepted an incoming Bluetooth connection. The report also recorded unsuccessful connection attempts. Those outcomes belong in the same evidence set; I do not get to count only the part that looks good in the summary.

Privacy behavior complicated identifying and reaching the device over the radio. That is separate from what happened after a connection succeeded. A failed attempt to reach the iPad does not exercise the vulnerable operation and therefore cannot tell us whether that operation would reject the input safely. Conversely, a repeatable service failure after connection does not prove that connections will always succeed.

The early test also had variability after connection. Examining the compiled program exposed a separate condition before the failing channel-state access. Depending on the state encountered along that path, processing could leave before reaching the crash. That gave the inconsistent results an explanation: an early exit was sometimes preventing the test from exercising the defective operation. It had not repaired the missing check farther along.

Later verification runs that established a connection and delivered the relevant input produced matching crashes. That is the useful progression in the evidence: a fault observed on the device, an explanation for why reaching it varied, and subsequent device records supporting the same failure. The report separates that empirical result from what could be concluded by reading the compiled code. I did not have a direct measurement of every transmission at every layer, so a universal success-rate claim would be bullshit.

A service crash has its own consequences

The observed failure was in the Bluetooth service, not a demonstration of the whole iPad rebooting. There was no demonstrated theft of messages or files, execution of an attacker’s program, or control of the operating-system kernel. This research established an availability failure, and Apple’s public description is consistent with that scope.

I measured the service failure, not the downstream effect on every accessory and application. A restart may restore availability, but it does not undo the interval in which the service was unavailable or the recovery work left to its clients. Under the tested connection conditions, an unpaired nearby peer could cause that interruption. That is the security impact I can support.

The mobile credit and its two update branches

Apple lists CVE-2026-113906 in these October 26 releases:

Those are two supported release branches carrying a fix for one CVE. The broader Bluetooth entry, CVE-2026-112566, appears in additional Apple platform advisories. Its companion article concentrates on the channel-validation failure and the controls that distinguished it from other ways a Bluetooth test can fail.

Read the channel-validation analysis and CVE-2026-112566 coverage

I’m proud of the two Bluetooth credits, both of which name Chris Bailey - Short Circuit as the only publicly credited researcher. Thank you to Apple’s security and engineering teams for addressing the reports. Apple’s entries do not report exploitation in the wild. Install the applicable supported update and verify the installed version.

Read the overview of all seven Apple credits

Apple’s advisories checked October 26, 2026.