CVE-2026-17873

This vulnerability is not a typical Chrome bug. It lives in the gap between Chrome's security policies and WebKit's enforcement layer, and that gap is fundamentally invisible to Chrome's development and detection infrastructure. Chrome for iOS must run on top of WebKit per Apple's platform requirements. This means Chrome implements security policies—origin checks, access control restrictions, resource loading limits—that WebKit is supposed to enforce underneath. When those two layers disagree about what a policy means in practice, you get a DAC bypass that requires no user interaction beyond loading a webpage. That's what happened here: insufficient policy enforcement in a specific WebKit-to-Chrome code path allowed a crafted HTML document to access resources that should have been blocked. The critical insight is that Chrome's security team cannot inspect, fuzz, or directly test how WebKit enforces these policies. They write security assumptions about an opaque layer, and when those assumptions drift—as they do silently through iOS updates, WebKit refactors, or behavioral changes—there's no instrumentation to catch it. This isn't a memory corruption bug you can find with sanitizers. It's a logic-layer mismatch across a trust boundary Chrome cannot verify from its own code. For defenders, this changes the threat model. Standard browser hardening advice—keep the browser updated, disable JavaScript, limit extensions—doesn't address the structural problem: your browser's security telemetry is blind to what's happening inside WebKit at enforcement time. Exploitation would leave no crash logs, no console errors, no artifacts Chrome's incident response tools can detect. An attacker who understands the specific policy boundary can exploit it silently across the entire iOS Chrome population. Prioritize updating Chrome for iOS to version 151.0.7922.72 or later. Beyond patching, flag any Chrome security review processes that don't include explicit cross-layer policy verification for iOS-specific code paths. The long-term risk isn't this single bypass—it's the class of vulnerabilities where Chrome trusts WebKit to enforce guarantees Chrome cannot verify, and has no way to know when those guarantees fail.

Reviewed through automated stages and approved by a human before publication.