Apple iOS CVE-2026-86881

Exploitation REQUIRES the attacker to already control a compromised (or rogue) intermediate certificate authority that the target Apple device trusts - this is the explicit prerequisite in the description, not an incidental detail. Given that, the attacker can issue certificates with arbitrary extended key usages that the flawed validation logic accepts. Affects unpatched iOS/iPadOS <26.7 and <27, macOS <15.8/<26.7/<27, tvOS <27, watchOS <27, and visionOS <27. The dominant limiting factor is the CA-compromise requirement: without a trusted-but-malicious intermediate CA there is no attack, which sharply narrows the realistic threat population despite the PR:N/UI:N network vector.

This is a certificate validation flaw (CWE-295) in Apple's cross-platform certificate handling, scored CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) by the vendor. The high base score is driven by network vector, no privileges, and high confidentiality+integrity impact. However, multiple secondary signals argue against treating this as an emergency: EPSS is only 0.14% (4th percentile), there is no CISA KEV listing, and no public exploit code is identified - so the status is 'no public exploit identified at time of analysis.' Most importantly, the description embeds a substantial precondition the CVSS PR:N does not capture: the attacker must ALREADY possess a compromised intermediate certificate authority. That is a rare, high-value prerequisite that in practice makes this a targeted-scenario weakness rather than a broadly automatable one. The vector's AC:L is therefore arguably optimistic - obtaining a compromised intermediate CA is a significant real-world barrier, so effective attack complexity is higher than the score implies. Net: genuinely serious for the narrow population who face a CA-compromise threat model (enterprise MDM, high-assurance TLS pinning), but low likelihood of widespread opportunistic exploitation. Patched by Apple across all listed OS versions; patching is the correct disposition but this need not jump the queue ahead of pre-auth RCEs.

An adversary who has compromised (or fraudulently operates) an intermediate CA that a target Apple device trusts issues a certificate bearing arbitrary extended key usages - for example marking a TLS server cert as valid for code signing or another restricted purpose. Because affected Apple OSes fail to properly constrain EKUs during validation, the device accepts the certificate for uses the CA hierarchy should have prohibited, enabling impersonation or misuse in TLS/authentication flows. No public exploit code is identified, and success hinges entirely on already controlling a trusted intermediate CA.