PatchGap · Weakness Pattern
A privileged action is authorized against a proxy for identity, not the real principal
WP-WRONG-PRINCIPAL-AUTHZ
AuthorizationBypass
35 CVEs
35 mapped
CWE-863CWE-862CWE-284CWE-441
2024-11 → 2026-09
A capability check passes because a correlated stand-in looks right — a related object merely exists, the wrong end of a channel is trusted, permissions are computed for the source document instead of the destination, or a principal captured earlier is reused after it changed — rather than because the exact principal that owns the capability was checked at the moment of the action. The result is a cross-frame / cross-origin / cross-process authorization bypass.
Invariant
Authorize a privileged action against the exact principal that owns the capability — the specific frame, document, origin, or process — resolved at the instant the action is performed; never against a correlated proxy (a related object’s existence, the wrong end of a channel, the source rather than the destination) or a principal captured earlier and since changed.
Mechanism
Browser IPC and navigation code constantly has to answer “is this actor allowed to do this?” — and the bug is answering it with something that merely correlates with the right answer instead of the answer itself. Recurring shapes: a guard checks that a related object EXISTS rather than that the caller OWNS it (“is there a popup?” instead of “does this frame own the popup?”); trust is inferred from the DESTINATION of a channel rather than the SENDER (“the peer is a broker, so the message is trusted”); a permission/state snapshot is computed for the SOURCE (previously-committed) document and carried into the DESTINATION document’s context, leaking one origin’s grants to the next; a capability is bound to a process class that should never have it (a PDF/utility process handed a renderer capability) because the binder omits the per-process check; or a live principal (origin,
WebContents, Page) is captured at API-call time and trusted many async hops later at action time, after it has navigated or been destroyed. In every case the front-end and the actual security boundary disagree about which principal is being authorized, and web content that arranges the mismatch acts with a privilege it was never granted.Fix shape
Add (or move) the check so it keys on the real principal, resolved at the moment of the privileged action: compare identity/ownership explicitly (
LocalFrameToken equality of the owning frame; sender-is-non-broker before conferring trust; is_pdf() / page-type gate before binding a capability); compute permission state for the DESTINATION document, not the source (or send none and recompute); and pin an async flow to the exact initiating Page/Document, aborting the moment it navigates, is destroyed, or is cached, rather than re-reading a now-stale live origin.CVEs in this pattern
28 components · DevTools, WebUI, FileSystem, Navigation, Transactions Platform, Core, Permissions, Storage, WebAppInstalls, Chromoting, Workers, WebView, Updater, TrustedWebActivities, Passwords, SiteIsolation, Downloads, PushAPI, Extensions, Tracing, Scroll, NFC, Contextual Tasks, WebAPKs, HID, PictureInPicture, BrowserTag, WebKit| CVE | What | Component | Vendor | Severity | Month | |
|---|---|---|---|---|---|---|
| CVE-2026-91739 | AuthorizationError in Transactions Platform | Transactions Platform | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-91734 | AuthorizationError in Core | Core | chrome | High | 2026-09 | 🔧 |
| CVE-2026-93383 | InfoDisclosure in Permissions | Permissions | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-93378 | AuthorizationError in Storage | Storage | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-91735 | AuthorizationError in WebUI | WebUI | chrome | High | 2026-09 | 🔧 |
| CVE-2026-91723 | Race in WebAppInstalls | WebAppInstalls | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-84328 | AuthorizationError in FileSystem | FileSystem | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-84334 | AuthorizationError in Chromoting | Chromoting | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87466 | AuthorizationError in Workers | Workers | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87481 | AuthorizationError in WebView | WebView | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87492 | AuthorizationError in DevTools | DevTools | chrome | High | 2026-09 | 🔧 |
| CVE-2026-87506 | LogicError in WebUI | WebUI | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87509 | AuthorizationError in Updater | Updater | chrome | Low | 2026-09 | 🔧 |
| CVE-2026-87552 | AuthorizationError in TrustedWebActivities | TrustedWebActivities | chrome | High | 2026-09 | 🔧 |
| CVE-2026-87583 | Spoofing in Passwords | Passwords | chrome | Low | 2026-09 | 🔧 |
| CVE-2026-87584 | AuthorizationError in WebUI | WebUI | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87606 | AuthorizationError in SiteIsolatio | SiteIsolation | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87611 | AuthorizationError in FileSystem | FileSystem | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87649 | Spoofing in Downloads | Downloads | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87652 | AuthorizationError in PushAPI | PushAPI | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-87658 | InfoDisclosure in Extensions | Extensions | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-93375 | LogicError in Tracing | Tracing | chrome | High | 2026-09 | 🔧 |
| CVE-2026-95287 | AuthorizationError in Navigatio | Navigation | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95289 | AuthorizationError in Scroll | Scroll | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95290 | AuthorizationError in NFC | NFC | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95297 | AuthorizationError in Contextual Tasks | Contextual Tasks | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95302 | AuthorizationError in WebAPKs | WebAPKs | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95314 | AuthorizationError in HID | HID | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95320 | AuthorizationError in Navigatio | Navigation | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95340 | AuthorizationError in PictureInPicture | PictureInPicture | chrome | Low | 2026-09 | 🔧 |
| CVE-2026-95352 | AuthorizationError in DevTools | DevTools | chrome | Low | 2026-09 | 🔧 |
| CVE-2026-95362 | LogicError in DevTools | DevTools | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95368 | AuthorizationError in DevTools | DevTools | chrome | Low | 2026-09 | 🔧 |
| CVE-2026-95375 | AuthorizationError in BrowserTag | BrowserTag | chrome | Medium | 2026-09 | 🔧 |
| CVE-2024-44309 | CrossOrigin in WebKit | WebKit | webkit | Medium | 2024-11 | 🔧 |
Hunt for siblings
For each capability/permission check, identify which principal it actually tests and whether that is the principal that owns the capability at action time. Flag checks that test a related object’s existence, the channel destination, an inherited/source-document snapshot, or a captured-then-stale live principal.
grep / ripgrep
# Authorization checks and the principal they key on:
rg -n 'IsAllowed|CanAccess|allowsFirstPartyForCookies|BindingContext|CheckOrigin|frame_token|process_type|is_pdf' \
content/browser components/ third_party/blink/renderer
# Then: confirm the check uses the OWNING/DESTINATION principal resolved at action time, not a proxy.Mitigations that would catch this class
- Make the authorization predicate take the principal as an explicit argument (frame token, origin, process type) so a call site cannot pass a proxy by omission
- Resolve identity at the moment of the side-effect, never a value captured at request time and trusted across async hops
- For navigations, compute permission/capability state for the committing (destination) document and treat inherited state as untrusted
- Fuzz/enumerate cross-frame, cross-origin and cross-process message paths with a mismatched principal (another frame’s token, a sibling broker, a source-vs-destination origin swap)