CVE-2026-65343 is a use-after-free in Apple's system components, patched in version 26.6.1 with 'improved memory management.' The CVSS 7.5 combined with EPSS 0.00222 creates an unusual profile: high impact but low probability of exploitation in the wild. This gap likely reflects reachability constraints — the vulnerable code path is probably in a privileged subsystem that's difficult to hit reliably, or Apple's own red team found exploitation harder than the technical severity suggests.
The 'system termination' outcome, not code execution, is significant. This points to a crash in a privileged process rather than a sandbox escape — still serious, but a meaningfully narrower blast radius than worst-case. If an attacker can trigger the UAF, they get denial of service, not arbitrary code execution.
The persistent question is why UAF keeps appearing in Apple's ecosystem despite years of Swift and ARC investment. The answer isn't that language migration failed — it's that Swift was never deployed comprehensively across the OS. The vulnerability almost certainly lives in a C/C++ subsystem that interfaces with Swift code: WebKit, the networking stack, a media codec handler. These are the seams where memory-safe code touches unsafe code, and they're the persistent attack surface precisely because rewriting high-performance C++ rendering engines in Swift isn't practical.
The economic reality is brutal: organizations migrate to memory-safe languages and defer auditing the remaining unsound code. That creates orphaned sediment at the boundaries — code nobody owns, nobody fuzzes proactively, and that gets patched reactively when CVEs surface. Apple's security team is clearly hunting this pattern (the low EPSS suggests they found it internally before threat actors did), but the seam problem is structural to partial adoption. It persists not because the industry lacks solutions, but because the economic model of migrating incrementally guarantees it.
For defenders: verify 26.6.1 deployment across your fleet, prioritize iPads in exposed roles (browsers, mail clients, anything rendering remote content), and treat the low EPSS as a 'not yet' rather than a 'never' — the vulnerability class is well-understood, and variants will continue surfacing at these same seams.