CVE-2026-11263 is a low-severity Chromium WebAuthentication flaw affecting Google Chrome on Android before version 149.0.7827.53, published by NVD on June 4, 2026, and mapped by NIST on June 8 to Chrome running on Android. The short answer to the CPE question is: probably not. The interesting part is not that NVD omitted a platform, but that this entry exposes how awkward Chrome’s vulnerability plumbing has become when one advisory, one browser family, and one mobile-only impact have to fit into a machine-readable taxonomy built for cleaner product boundaries.
That matters because CPEs are no longer just database decoration. They feed scanners, asset inventories, SBOM correlation engines, patch dashboards, and compliance exceptions. When the product string is even slightly ambiguous, the confusion does not stay inside NVD; it shows up as false positives on desktops, missed exposure on managed Android fleets, and another round of “is this real?” tickets for security teams already drowning in Chrome CVEs.
At first glance, CVE-2026-11263 looks like a candidate for a missing CPE because the description says “Google Chrome on Android,” while the linked Google advisory is titled as a desktop stable-channel update. That mismatch is enough to make any vulnerability analyst pause. Desktop Chrome and Android Chrome share much of Chromium, but they are not operationally identical products in patch management systems.
NVD’s change record, however, shows an actual configuration rather than a flat product listing. It added Google Chrome versions up to, but excluding, 149.0.7827.53, and paired that with the Android operating-system CPE. In CPE logic, that is the important distinction: vulnerable Chrome, in the affected configuration, is Chrome running on Android.
That is a reasonable modeling choice. The flaw is not described as affecting Android itself; Android is the platform constraint. A scanner that understands NVD configuration logic should read this as “Chrome below the fixed version when installed on Android,” not “all Chrome everywhere” and not “Android as a standalone vulnerable operating system.”
The problem is that many real-world tools are less subtle. They ingest the application CPE, flatten the configuration, or treat the presence of the Chrome CPE as enough to alert. That is how a mobile-only browser bug can end up on a Windows workstation vulnerability report, despite the database record technically carrying the platform condition.
Chrome for Android also moved to Chrome 149 on June 2, with version 149.0.7827.59 rolling out through Google Play over the following days. Google’s Android release notes commonly say Android releases contain the same security fixes as their corresponding desktop releases unless otherwise noted. That convention explains why a CVE whose description says Android can still point to a desktop advisory as the vendor security reference.
This is not elegant, but it is normal for Chrome. Google tends to use the desktop stable post as the large security ledger, while Android release posts focus more on rollout and stability. For a human reader, that is merely annoying. For an automated enrichment pipeline, it creates the appearance of contradiction.
The result is a record that looks backward: the linked advisory is desktop, the affected product is Android Chrome, and the fixed Android build visible to users may be 149.0.7827.59 rather than the 149.0.7827.53 threshold in the CVE text. That does not necessarily mean the CPE is wrong. It means the version boundary in the CVE corresponds to the security-fix baseline, while the Android package shipped as a later build number.
But that prerequisite is also why dismissing the bug outright would be a mistake. Browser exploitation is often a chain, not a single magic trick. A renderer compromise gets an attacker into the browser’s sandboxed execution environment; the next prize is often data movement, policy bypass, sandbox escape, or access to something the renderer should not be able to observe.
Here, the alleged consequence is cross-origin data leakage through a crafted HTML page. In browser security, cross-origin is not a minor adjective. It describes one of the core walls separating one website’s data from another’s. If a compromised renderer can abuse WebAuthentication policy enforcement to leak information across that boundary, the bug becomes one component in a broader post-compromise playbook.
That also explains the split between Google’s low severity and CISA-ADP’s medium CVSS 3.1 score of 6.5. Chromium’s severity label considers exploitability in the browser’s own model and the prerequisite renderer compromise. CVSS, by contrast, expresses the network reachability, low attack complexity, required user interaction, and high confidentiality impact once the conditions are met. Both readings can be true at the same time.
That origin binding is the whole point. A credential meant for one site should not be casually usable by another, and browser UI plus policy enforcement are supposed to prevent a malicious page from tricking the user or the authenticator into the wrong relationship. When a CVE says “insufficient policy enforcement” in WebAuthentication, the phrase deserves attention even if the severity label is low.
The public description does not say that attackers can steal passkeys, impersonate users, or bypass WebAuthn outright. We should not inflate it into that. The stated impact is cross-origin data leakage after renderer compromise, not wholesale credential theft.
Still, for administrators, the affected component matters. WebAuthentication is no longer a niche developer feature. Enterprises are actively pushing passkeys and FIDO2 security keys as alternatives to passwords and SMS-based MFA. Bugs in that surface should be patched quickly because they sit inside the trust fabric that vendors are asking users to rely on more heavily each year.
A managed Android phone can be the device that approves a sign-in, holds a passkey, opens a corporate web app, or syncs browser state with a user’s desktop profile. If Chrome on that device is stale, it is not “just a mobile issue.” It is another exposed edge of the same identity perimeter.
For pure Windows desktop vulnerability management, CVE-2026-11263 should not be treated as a Windows Chrome finding unless a vendor or scanner has additional evidence that desktop platforms are affected in the same way. The public CVE description says Chrome on Android. That should be the anchor.
For Microsoft Edge, the calculus is similar but not identical. Edge is Chromium-based, so security teams often watch Chrome CVEs as early indicators for Edge exposure. But the Android-specific wording matters. Unless Microsoft ships a corresponding Edge advisory or the vulnerable Chromium code path is confirmed in Edge for Android, teams should avoid overclaiming while still tracking whether their Chromium-based mobile browsers receive the relevant upstream fix.
This happens constantly with browser CVEs. Chrome is a browser, Chromium is a project, Android System WebView may share code, Electron apps embed Chromium, Edge carries its own release train, Linux distributions repackage Chromium, and mobile releases use app-store delivery rather than enterprise desktop update channels. CPE was never going to make that ecosystem feel tidy.
For CVE-2026-11263, the best reading is that the Android platform CPE is already present and that the Chrome application CPE is appropriately version-bounded. If someone is asking “are we missing a CPE?” the better question is “are we preserving the AND relationship between Chrome and Android when we ingest this record?”
That distinction changes the action. If the issue were a missing CPE, the fix would be to ask NVD for another product mapping. If the issue is configuration flattening, the fix belongs in scanner logic, asset tagging, and exception handling. Security teams should not paper over a tooling problem by treating every Chrome install as equally affected.
On consumer devices, that means Google Play updates. On managed fleets, it means checking Android Enterprise policy, managed Google Play app status, device compliance reporting, and any OEM lag that might delay update availability. If Chrome is disabled in favor of another browser, the same Chromium lineage question should be asked of that browser rather than assumed away.
For desktops, CVE-2026-11263 should be handled as part of the broader Chrome 149 update story, not as a standalone Android finding. The June desktop release fixed hundreds of issues, including critical memory-safety flaws unrelated to this WebAuthentication bug. Even if this specific CVE is Android-scoped, the Chrome 149 desktop update still deserves normal urgency because the advisory is much larger than one low-severity item.
That is the small irony here. The Android-only CPE question is narrow, but the patch event is not. Anyone using Chrome on Windows, Mac, or Linux should already be moving through the June 2026 stable-channel update for reasons that have nothing to do with CVE-2026-11263.
The danger is not that the record lacks a CPE. The danger is that a security program will collapse the nuance into a noisy, wrong, or incomplete finding.
That matters because CPEs are no longer just database decoration. They feed scanners, asset inventories, SBOM correlation engines, patch dashboards, and compliance exceptions. When the product string is even slightly ambiguous, the confusion does not stay inside NVD; it shows up as false positives on desktops, missed exposure on managed Android fleets, and another round of “is this real?” tickets for security teams already drowning in Chrome CVEs.
The CPE Is Doing More Work Than It First Appears
At first glance, CVE-2026-11263 looks like a candidate for a missing CPE because the description says “Google Chrome on Android,” while the linked Google advisory is titled as a desktop stable-channel update. That mismatch is enough to make any vulnerability analyst pause. Desktop Chrome and Android Chrome share much of Chromium, but they are not operationally identical products in patch management systems.NVD’s change record, however, shows an actual configuration rather than a flat product listing. It added Google Chrome versions up to, but excluding, 149.0.7827.53, and paired that with the Android operating-system CPE. In CPE logic, that is the important distinction: vulnerable Chrome, in the affected configuration, is Chrome running on Android.
That is a reasonable modeling choice. The flaw is not described as affecting Android itself; Android is the platform constraint. A scanner that understands NVD configuration logic should read this as “Chrome below the fixed version when installed on Android,” not “all Chrome everywhere” and not “Android as a standalone vulnerable operating system.”
The problem is that many real-world tools are less subtle. They ingest the application CPE, flatten the configuration, or treat the presence of the Chrome CPE as enough to alert. That is how a mobile-only browser bug can end up on a Windows workstation vulnerability report, despite the database record technically carrying the platform condition.
Google’s Advisory Trail Makes the Record Look Stranger Than It Is
The source of the confusion is Google’s release cadence. Chrome 149 was promoted to the stable channel for Windows, Mac, and Linux on June 2, 2026, with 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and Mac. That desktop advisory lists a sprawling security payload: 429 security fixes, including CVE-2026-11263 as a low-severity WebAuthentication issue.Chrome for Android also moved to Chrome 149 on June 2, with version 149.0.7827.59 rolling out through Google Play over the following days. Google’s Android release notes commonly say Android releases contain the same security fixes as their corresponding desktop releases unless otherwise noted. That convention explains why a CVE whose description says Android can still point to a desktop advisory as the vendor security reference.
This is not elegant, but it is normal for Chrome. Google tends to use the desktop stable post as the large security ledger, while Android release posts focus more on rollout and stability. For a human reader, that is merely annoying. For an automated enrichment pipeline, it creates the appearance of contradiction.
The result is a record that looks backward: the linked advisory is desktop, the affected product is Android Chrome, and the fixed Android build visible to users may be 149.0.7827.59 rather than the 149.0.7827.53 threshold in the CVE text. That does not necessarily mean the CPE is wrong. It means the version boundary in the CVE corresponds to the security-fix baseline, while the Android package shipped as a later build number.
“Low” Does Not Mean “Ignore,” Especially After Renderer Compromise
CVE-2026-11263 is not the kind of bug that should trigger panic by itself. Google classifies it as low severity in Chromium terms. The attack scenario requires a compromised renderer process, which means the attacker has already cleared a substantial hurdle before this flaw becomes useful.But that prerequisite is also why dismissing the bug outright would be a mistake. Browser exploitation is often a chain, not a single magic trick. A renderer compromise gets an attacker into the browser’s sandboxed execution environment; the next prize is often data movement, policy bypass, sandbox escape, or access to something the renderer should not be able to observe.
Here, the alleged consequence is cross-origin data leakage through a crafted HTML page. In browser security, cross-origin is not a minor adjective. It describes one of the core walls separating one website’s data from another’s. If a compromised renderer can abuse WebAuthentication policy enforcement to leak information across that boundary, the bug becomes one component in a broader post-compromise playbook.
That also explains the split between Google’s low severity and CISA-ADP’s medium CVSS 3.1 score of 6.5. Chromium’s severity label considers exploitability in the browser’s own model and the prerequisite renderer compromise. CVSS, by contrast, expresses the network reachability, low attack complexity, required user interaction, and high confidentiality impact once the conditions are met. Both readings can be true at the same time.
WebAuthentication Is Exactly Where Policy Bugs Become Sensitive
WebAuthentication, or WebAuthn, sits in a sensitive corner of the browser. It is the standards-based machinery behind passkeys, hardware security keys, and phishing-resistant authentication flows. Its security value depends on careful binding between an authenticator, a relying party, and the origin that requested authentication.That origin binding is the whole point. A credential meant for one site should not be casually usable by another, and browser UI plus policy enforcement are supposed to prevent a malicious page from tricking the user or the authenticator into the wrong relationship. When a CVE says “insufficient policy enforcement” in WebAuthentication, the phrase deserves attention even if the severity label is low.
The public description does not say that attackers can steal passkeys, impersonate users, or bypass WebAuthn outright. We should not inflate it into that. The stated impact is cross-origin data leakage after renderer compromise, not wholesale credential theft.
Still, for administrators, the affected component matters. WebAuthentication is no longer a niche developer feature. Enterprises are actively pushing passkeys and FIDO2 security keys as alternatives to passwords and SMS-based MFA. Bugs in that surface should be patched quickly because they sit inside the trust fabric that vendors are asking users to rely on more heavily each year.
Windows Admins Still Have a Stake in an Android Chrome Bug
WindowsForum readers might reasonably ask why an Android Chrome CVE belongs in their patch queue at all. The answer is that modern Windows administration rarely stops at Windows. Intune, Defender, Entra ID, conditional access, device compliance, and identity-driven security have pulled Android endpoints into the same operational orbit as desktops and laptops.A managed Android phone can be the device that approves a sign-in, holds a passkey, opens a corporate web app, or syncs browser state with a user’s desktop profile. If Chrome on that device is stale, it is not “just a mobile issue.” It is another exposed edge of the same identity perimeter.
For pure Windows desktop vulnerability management, CVE-2026-11263 should not be treated as a Windows Chrome finding unless a vendor or scanner has additional evidence that desktop platforms are affected in the same way. The public CVE description says Chrome on Android. That should be the anchor.
For Microsoft Edge, the calculus is similar but not identical. Edge is Chromium-based, so security teams often watch Chrome CVEs as early indicators for Edge exposure. But the Android-specific wording matters. Unless Microsoft ships a corresponding Edge advisory or the vulnerable Chromium code path is confirmed in Edge for Android, teams should avoid overclaiming while still tracking whether their Chromium-based mobile browsers receive the relevant upstream fix.
The Real CPE Risk Is Scanner Flattening, Not NVD Omission
The NVD configuration is more nuanced than many downstream workflows will preserve. That is the heart of the issue. A CPE expressed as Chrome plus Android can be correct in the database and still produce noise when exported into tools that prefer one product, one version, one verdict.This happens constantly with browser CVEs. Chrome is a browser, Chromium is a project, Android System WebView may share code, Electron apps embed Chromium, Edge carries its own release train, Linux distributions repackage Chromium, and mobile releases use app-store delivery rather than enterprise desktop update channels. CPE was never going to make that ecosystem feel tidy.
For CVE-2026-11263, the best reading is that the Android platform CPE is already present and that the Chrome application CPE is appropriately version-bounded. If someone is asking “are we missing a CPE?” the better question is “are we preserving the AND relationship between Chrome and Android when we ingest this record?”
That distinction changes the action. If the issue were a missing CPE, the fix would be to ask NVD for another product mapping. If the issue is configuration flattening, the fix belongs in scanner logic, asset tagging, and exception handling. Security teams should not paper over a tooling problem by treating every Chrome install as equally affected.
Patch Operations Should Follow the Installed Browser, Not the Advisory Headline
The operational guidance is refreshingly simple: update Chrome for Android to a fixed Chrome 149 build or later. The CVE says versions before 149.0.7827.53 are affected; Google’s June 2 Android stable release was 149.0.7827.59 and rolled out through Google Play. In practice, administrators should verify installed Android Chrome versions rather than rely on the desktop advisory title.On consumer devices, that means Google Play updates. On managed fleets, it means checking Android Enterprise policy, managed Google Play app status, device compliance reporting, and any OEM lag that might delay update availability. If Chrome is disabled in favor of another browser, the same Chromium lineage question should be asked of that browser rather than assumed away.
For desktops, CVE-2026-11263 should be handled as part of the broader Chrome 149 update story, not as a standalone Android finding. The June desktop release fixed hundreds of issues, including critical memory-safety flaws unrelated to this WebAuthentication bug. Even if this specific CVE is Android-scoped, the Chrome 149 desktop update still deserves normal urgency because the advisory is much larger than one low-severity item.
That is the small irony here. The Android-only CPE question is narrow, but the patch event is not. Anyone using Chrome on Windows, Mac, or Linux should already be moving through the June 2026 stable-channel update for reasons that have nothing to do with CVE-2026-11263.
The Database Got the Platform Mostly Right, but Your Dashboard May Not
This is one of those vulnerability records where the government database is probably less confused than the dashboards built on top of it. NVD’s configuration says Chrome under the fixed version, constrained to Android. The public description says Android. The vendor release trail explains why a desktop advisory appears in the references.The danger is not that the record lacks a CPE. The danger is that a security program will collapse the nuance into a noisy, wrong, or incomplete finding.
- CVE-2026-11263 should be treated as affecting Google Chrome on Android before the fixed Chrome 149 security baseline.
- NVD’s Chrome application CPE combined with the Android operating-system CPE is a plausible configuration, not an obvious omission.
- Tools that ignore the AND relationship may incorrectly flag Windows, macOS, or Linux Chrome installs for this specific CVE.
- The linked desktop advisory is not proof that this WebAuthentication issue affects desktop Chrome; it is part of Google’s shared Chrome security-release process.
- Android fleet owners should verify Chrome 149.0.7827.59 or later where available, while desktop administrators should still deploy the broader Chrome 149 security update for its many other fixes.
- WebAuthentication bugs deserve prompt patching even when rated low, because they sit near identity, passkeys, and origin-bound trust decisions.
References
- Primary source: NVD / Chromium
Published: 2026-06-09T07:00:08-07:00
NVD - CVE-2026-11263
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-06-09T07:00:08-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: radar.offseq.com
CVE-2026-11263: Insufficient policy enforcement in Google Chrome - Live Threat Intelligence - Threat Radar | OffSeq.com
Detailed information about CVE-2026-11263: Insufficient policy enforcement in Google Chrome affecting Google Chrome. Get real-time updates, technical details, a
radar.offseq.com
- Related coverage: security.snyk.io
- Related coverage: govcert.gov.hk
GovCERT.HK - Security Alerts
Security Alert (A26-06-08): Multiple Vulnerabilities in Google Chromewww.govcert.gov.hk
