iOS 27 security fixes: fingerprinting and tracking CVEs

Last updated: 2026-10-03

On September 14, 2026, Apple released iOS 27 and iPadOS 27. The iOS 27 security notes list 126 CVE IDs in 122 entries. Fourteen of the entries describe an installed app obtaining data or access that iOS withholds from apps: persistent device and account identifiers, signals for fingerprinting, the list of other installed apps, the user's location from system logs, tracking across apps and websites without permission, and access that bypasses Privacy preferences. Fingerprinting is what Apple's developer rules call using "signals from the device to try to identify the device or a user" (Apple, User Privacy and Data Use). Seven of the fourteen are also fixed in iOS 26.7 and iPadOS 26.7, released the same day.

Which iOS 27 security fixes concern tracking and fingerprinting?

Sources: Apple's notes for iOS 27, iOS 26.7 and iOS 18.7.10, opened 2026-10-03; the NVD records, such as CVE-2026-84612, list the same fixed versions. "None listed": no earlier iOS release's notes list the CVE. Apple added the Accounts entry to the iOS 18.7.10 notes on September 14, 2026. Rows are selected by impact text; 126 is a count of IDs and measures no severity.

What could an app do before the iOS 27 privacy fixes?

Five entries concern identifiers that persist. DeviceCheck is Apple's framework to "Reduce fraudulent use of your services by managing device state and asserting app integrity"; its fix is "improved access control". Three entries (App Store, AuthKit, CloudKit) concern "a persistent account identifier", and the iCloud entry concerns identifying "a user across reinstalls". An identifier that stays the same after an app is deleted and reinstalled serves the same purpose as a fingerprint: it links separate sessions to one device or person.

Three entries name fingerprinting. Photos Storage was fixed "with additional entitlement checks", Sandbox Profiles "with additional sandbox restrictions" and Power Management "with improved state management". Apple names no signal in any of them. Two more flaws let an app learn which other apps are installed, a list that differs from phone to phone and so can serve as a fingerprinting signal.

The Symptom Framework flaw let a malicious app determine "a user's current location", fixed with "improved private data redaction for log entries". The Watch App entry uses Apple's tracking wording, "track users across apps and websites without permission". On iOS that permission is the App Tracking Transparency prompt. The Accounts and Time Zone flaws let an app bypass "Privacy preferences"; Apple names no preference in either.

Apple's notes name no app, give no technique and report no exploitation. A search I ran on 2026-10-03 found no write-up by the credited researchers. Among the fourteen, Stanislav Jelezoglo is credited for Watch App, Photos Storage and CloudKit, and Ilya Andr (andrd3v) for Power Management, iCloud and, with CJ Vana, Sandbox Profiles. Apple's Impact lines state what an app may have been able to do before the fix; the notes do not show whether any app or SDK used these paths.

Does Apple allow apps or SDKs to fingerprint on iOS?

Apple's answer to "Can I fingerprint or use signals from the device to try to identify the device or a user?" is "No." The same page adds that apps that fingerprint, "or that reference SDKs (including but not limited to Ad Networks, Attribution services, and Analytics) that are, may be rejected from the App Store." Apps and SDKs must also declare, in a privacy manifest, a reason for each use of five API categories (file timestamps, system boot time, disk space, active keyboards and user defaults). Apple's required reason API page states: "Regardless of whether a user gives your app permission to track, fingerprinting is not allowed." Apple's descriptions of seven of the fourteen fixes name an authorization issue, a permissions issue or entitlement checks: in those seven, Apple places the defect in the checks iOS applies before it gives an app access.

An SDK runs inside every app that bundles it, with that app's access, so a path open to an app on an unpatched iOS version was open to the SDKs compiled into it. The EFF study of ad SDKs found four Android ad SDKs that send precise location in ad requests by default once the host app holds location permission, and the EngageLab SDK flaw let another app on the same Android phone read and write the host app's private files.

What does a scan of an iOS app show for these CVEs?

An iOS app's binary contains the name of each Apple framework it links, such as DeviceCheck, and contains the Objective-C class names of the third-party SDKs compiled into it; the IPA also contains the privacy manifest (PrivacyInfo.xcprivacy) of the app and of each SDK that ships one. The CanITrustThat (CITT) IPA extractor records the linked frameworks, the class names, the entitlements and the plists, privacy manifests included. That is presence evidence; it does not show use of a specific CVE. A traffic capture on a test device shows which identifiers and device attributes were sent, to which host, and whether before or after consent. The API that produced a value is outside what a capture shows.

In a CITT scan, every static finding cites its file and line and every traffic finding cites its capture (what a scan checks; the limits of a scan). I run these investigations for lawyers and for researchers working with lawyers, on one app or a list of apps in bulk. Sign up for a CanITrustThat account to run your own research, let us run an investigation for you, or browse the scanned apps.