iPhone Bug Let Apps Record After You Tapped “Don’t Allow”, With No Orange Dot

How an App Talked Its Way Past "Don't Allow"

Apps on an iPhone don’t open the microphone themselves. A system audio service, which Apple’s logs call audiomxd, runs the recording for each app and decides whether real sound goes through. An app the user refused still gets audio, only it’s silence.

To make that decision, the service keeps an identity token for each app, a record of which process is asking. Calap found an undocumented setting, property 2009, that let an app overwrite its own stored token with any 32 bytes. Nothing checked whether the app had the right to speak for another process.

So he wrote in the audio service’s own token, which the system hands to any app that sends the service a trivial request. The service compared the stored identity with its own, found a match and concluded it was talking to itself. It skipped the permission check and sent real microphone samples. It is a bit like a bouncer who waves you in because you are holding up his own ID card.

No jailbreak or memory corruption was involved. The test app had no special entitlements, only the standard microphone usage text every recording app needs for the prompt to appear. Recording had to start while the app was on screen, and the background version used the ordinary “audio” background mode. Calap installed both versions from Xcode, so they never went through App Review, and whether Apple’s review would have caught such an app is unknown.

His post documents that the orange dot stayed off but doesn’t explain why. He tested iPhone and iPad builds; Apple shipped the same fix for the Mac, Apple Watch, Apple TV and Vision Pro.

Which Updates Fix It

According to Apple’s security notes, these versions and everything after them carry the fix:

• iPhone and iPad on iOS/iPadOS 26: 26.6.1, from 17 August (notes)
• Older iPhones and iPads on iOS/iPadOS 18 (Apple lists the iPhone XS, XS Max, XR and iPad 7th generation): 18.7.11, from 26 October (notes)
• Mac: macOS Tahoe 26.6.2, from 17 August (notes), and macOS Sequoia 15.8, from 14 September (notes)
• Apple Watch, Apple TV, Vision Pro: watchOS 27, tvOS 27 and visionOS 27, all from 14 September
• iOS/iPadOS 27 and macOS Golden Gate 27: not listed (next chapter)

On an iPhone or iPad, Settings > General > Software Update shows the installed version and any update waiting. On a Mac, the version is under the Apple menu > About This Mac.

The National Vulnerability Database carries a medium score of 5.0 out of 10, assigned by the US cybersecurity agency CISA. Apple’s own notes describe the impact as “An app may be able to leak sensitive user information”. That is one way to describe an app recording you after you said no.

None of Apple’s notes says the bug was used in attacks. Apple does flag that when it knows of it, as it did for a separate CoreGraphics flaw in the same October update for older iPhones.

Indicator tricks themselves are not new. In February, Jamf showed how Predator spyware hides the camera and microphone dots, but only on a phone that is already “fully compromised, including kernel-level access”. Calap’s app needed none of that, only one function call.

The iOS 27 Question

Calap reproduced the bug on iOS 26.6 and on a beta of iPadOS 27. Apple’s 14 September notes list the fix for tvOS 27, watchOS 27 and visionOS 27, but not for iOS and iPadOS 27 or macOS Golden Gate 27, which came out the same day. No later iOS 27 or Golden Gate note mentions it either, up to the 27.2.1 updates released on 9 November. Calap’s own list of his Apple bugs shows the same set of versions.

That doesn’t mean iOS 27 is vulnerable. Apple may have shipped it with the fix and not listed it. The notes don’t say, and the write-up doesn’t say whether Calap tested a final iOS 27 build.

If you are on iOS 27, the latest version is worth having anyway. iOS 27.2, from 26 October, fixed another bug Calap reported, CVE-2026-86990, which Apple says could let “a malicious app” access “the camera without user permission” (notes). He hasn’t published details of that one.

Two Reports, One Fix

Apple credits two people for CVE-2026-65339: Calap and Nik Tsytsarkin of Meta Red Team X, Meta’s offensive security team. In Apple’s view, Tsytsarkin reported it first. Calap’s disclosure timeline shows it took some arguing to get there.

He reported the flaw on 31 July, with a working proof of concept. The August fix credited only Tsytsarkin. On 20 August, Apple closed Calap’s report, telling him the issue had been fixed before he reported it, in a 13 July beta of iOS 26.6, and that it found no security issue in what he sent.

Calap answered with a comparison of Apple’s builds. His proof of concept worked on iOS 26.6 as released on 27 July, two weeks after that beta, and the new check appears only in 26.6.1. Apple reopened the report three days later and marked it as a duplicate the day after. On 14 September it added his name to the August notes. Apple’s first answer, that there was no security issue, did not survive a look at Apple’s own code.

Apple then asked him to hold the write-up while it shipped more fixes, the last for older iPhones on 26 October. He published two weeks after that release, as agreed.

We’ve asked Apple whether iOS 27 shipped with the fix and about its handling of the report, and asked Calap whether he tested a final iOS 27 build. We’ll update this article when they reply.