Chrome on Android releases before 150.0.7871.47 are affected by CVE-2026-13929. Update affected Android devices and verify that the complete installed Chrome version is 150.0.7871.47 or later. The supplied record does not establish that this CVE affects Chrome on Windows or Microsoft Edge.
For WindowsForum readers, that product boundary is operationally important. Security and help-desk teams should reject false-positive Windows Chrome or Edge remediation tickets based solely on the Chrome or Chromium name, while routing valid Android Chrome findings to the mobile-management owner.
Chrome describes CVE-2026-13929 as insufficient policy enforcement in DevTools in Chrome on Android before version 150.0.7871.47. Under the documented conditions, a local attacker could use a malicious file to bypass navigation restrictions. Chrome classified the vulnerability as Medium.
The visible CISA-ADP CVSS 3.1 assessment assigns a base score of 5.5 with the vector:
That assessment records:
The public description does not specify the exact action required from the user. It does not say whether exploitation depends on opening, selecting, importing, previewing, or otherwise processing the malicious file. The linked Chromium issue is permission-restricted, so a more detailed exploit sequence cannot be established from the public material.
CISA-ADP’s Stakeholder-Specific Vulnerability Categorization contribution records exploitation as none, automatable exploitation as no, and technical impact as partial. Those are point-in-time assessment values. They support prompt but proportionate remediation and should not be presented as a guarantee that exploitation could never occur.
The complete four-part version matters. A result showing only “Chrome 150” cannot establish whether the installed build is before, at, or after 150.0.7871.47.
NVD’s affected-product configuration associates the vulnerable Chrome version range with Android. That supports applying the threshold to Chrome on Android rather than treating it as a general rule for every Chrome installation or every Chromium-derived browser.
Shared Chromium ancestry is not enough to establish product applicability. Another browser may share related code, but its exposure and corrected version must be established by its own vendor or affected-product data.
For an individual Android device:
A version result should be handled as follows:
No alternate setting change should be substituted for the version check unless authoritative product guidance specifically establishes it as effective for CVE-2026-13929. The supplied material gives administrators a clear affected range and corrected threshold, making version-based remediation the defensible control.
This matters because vulnerability-management systems may match findings using incomplete product names or version comparisons. A scanner may see “Google Chrome” on a Windows endpoint and associate it with a Chrome CVE without enforcing the Android platform condition. That is not sufficient evidence for this finding.
A valid match under the supplied record requires:
Microsoft Edge must also be handled separately. The fact that Edge is Chromium-based does not establish that it contains the affected implementation, exposes the same Android path, or uses Chrome’s fixed version number. Administrators should rely on Microsoft’s product-specific advisories before assigning this CVE to Edge.
The same caution applies to Android WebView, ChromeOS, macOS, Linux, and other Chromium-derived browsers. None should inherit this Android Chrome threshold through association alone.
Those limitations do not make the vulnerability harmless. The assessment assigns high integrity impact, and Chrome’s description says an intended navigation restriction could be bypassed. Updating is a direct and comparatively low-disruption way to move an Android installation outside the affected range.
The appropriate response is therefore neither an emergency shutdown nor indefinite delay:
Chrome is the source of the CVE description, the Android scope, the affected-version boundary, the Medium classification, and the displayed CWE-20 Improper Input Validation classification.
CISA-ADP supplied the visible CVSS 3.1 assessment of 5.5 and the SSVC values. The record history also shows that CISA-ADP added and later removed a separate CWE-602 contribution. That change should not be described as replacing, validating, or otherwise altering Chrome’s CWE-20 classification.
NVD presents the record and affected-product configuration, but the supplied material does not show an NVD-authored CVSS assessment. Reports should therefore label 5.5 as the CISA-ADP score displayed by NVD, not simply as an “NVD score.”
Exact calendar dates are not necessary to apply the remediation and have been omitted because the previously stated June 30, 2026 date is not sufficiently supported by the supplied material for this revision. The useful early-coverage sequence is limited to provenance: Chrome supplied the core vulnerability information, CISA-ADP contributed the visible assessment data, and NVD presented the record and platform-specific configuration.
Chrome on Windows and Microsoft Edge are not established as affected by this record. Keeping that distinction visible prevents false-positive desktop tickets from consuming attention while vulnerable Android installations remain in service.
The forward-looking task is to monitor authoritative updates for a revised affected range, additional technical detail, a new exploitation assessment, or product-specific guidance from other browser vendors. Until such information appears, the defensible response remains focused: route the issue to the Android owner, update Chrome, verify version 150.0.7871.47 or later, and do not extend the finding to Windows Chrome or Edge without supporting evidence.
For WindowsForum readers, that product boundary is operationally important. Security and help-desk teams should reject false-positive Windows Chrome or Edge remediation tickets based solely on the Chrome or Chromium name, while routing valid Android Chrome findings to the mobile-management owner.
Scope and Impact
Chrome describes CVE-2026-13929 as insufficient policy enforcement in DevTools in Chrome on Android before version 150.0.7871.47. Under the documented conditions, a local attacker could use a malicious file to bypass navigation restrictions. Chrome classified the vulnerability as Medium.The visible CISA-ADP CVSS 3.1 assessment assigns a base score of 5.5 with the vector:
AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:NThat assessment records:
- A local attack vector
- Low attack complexity
- No privileges required
- Required user interaction
- Unchanged scope
- No confidentiality impact
- High integrity impact
- No availability impact
The public description does not specify the exact action required from the user. It does not say whether exploitation depends on opening, selecting, importing, previewing, or otherwise processing the malicious file. The linked Chromium issue is permission-restricted, so a more detailed exploit sequence cannot be established from the public material.
CISA-ADP’s Stakeholder-Specific Vulnerability Categorization contribution records exploitation as none, automatable exploitation as no, and technical impact as partial. Those are point-in-time assessment values. They support prompt but proportionate remediation and should not be presented as a guarantee that exploitation could never occur.
What is not established
The supplied record does not establish a sandbox escape, arbitrary code execution, credential theft, arbitrary-file access, confidentiality loss, denial of service, a specific file-delivery channel, or a complete exploit workflow. It also does not identify the protected destination or internal browser operation reached through the navigation bypass. Reporting should therefore remain focused on the documented integrity impact, prerequisites, platform, and version range.The Version Boundary
The affected condition combines three elements:- Product: Google Chrome
- Platform: Android
- Version: Earlier than 150.0.7871.47
| Browser target | Version condition | Status under this CVE | Required response |
|---|---|---|---|
| Chrome on Android | Earlier than 150.0.7871.47 | Affected | Update and verify the complete installed version |
| Chrome on Android | Exactly 150.0.7871.47 | Meets the stated threshold | Record the verified version |
| Chrome on Android | Later than 150.0.7871.47 | Outside the listed affected range | Record the verified version |
| Chrome on Android | Only “Chrome 150” is known | Unverified | Obtain the complete four-part version |
| Chrome on Windows | Not identified as affected | Not established by this record | Do not create a finding solely from this CVE |
| Microsoft Edge | Not identified as an affected product | Not established by this record | Evaluate through Microsoft’s product-specific information |
NVD’s affected-product configuration associates the vulnerable Chrome version range with Android. That supports applying the threshold to Chrome on Android rather than treating it as a general rule for every Chrome installation or every Chromium-derived browser.
Shared Chromium ancestry is not enough to establish product applicability. Another browser may share related code, but its exposure and corrected version must be established by its own vendor or affected-product data.
Remediation and Verification
The direct remediation is to move every affected Chrome on Android installation to version 150.0.7871.47 or later.For an individual Android device:
- Obtain the complete installed Chrome version using the version information available in Chrome or the device’s application information.
- Compare all four version components with 150.0.7871.47.
- If the installed version is earlier, install the current Chrome update using the update method supported for that device.
- Reopen Chrome after the update if necessary.
- Check the complete installed version again.
- Close the finding only when the device reports 150.0.7871.47 or later.
A version result should be handled as follows:
| Observed result | Disposition |
|---|---|
| Earlier than 150.0.7871.47 | Remediation remains open |
| 150.0.7871.47 or later | Meets the stated version threshold |
| Incomplete version such as “Chrome 150” | Unverified |
| Missing, stale, or conflicting version | Unresolved until fresh evidence is obtained |
| Chrome is not installed | Not applicable to that device; record product absence separately |
Windows Chrome and Edge Are Not Established as Affected
CVE-2026-13929 should not be assigned automatically to Chrome on Windows. The affected-product information identifies Chrome on Android, and the record does not extend the vulnerability to desktop Chrome merely because the product names are similar.This matters because vulnerability-management systems may match findings using incomplete product names or version comparisons. A scanner may see “Google Chrome” on a Windows endpoint and associate it with a Chrome CVE without enforcing the Android platform condition. That is not sufficient evidence for this finding.
A valid match under the supplied record requires:
- Google Chrome is installed.
- The platform is Android.
- The complete installed version is earlier than 150.0.7871.47.
Microsoft Edge must also be handled separately. The fact that Edge is Chromium-based does not establish that it contains the affected implementation, exposes the same Android path, or uses Chrome’s fixed version number. Administrators should rely on Microsoft’s product-specific advisories before assigning this CVE to Edge.
The same caution applies to Android WebView, ChromeOS, macOS, Linux, and other Chromium-derived browsers. None should inherit this Android Chrome threshold through association alone.
WindowsForum routing note
A Windows-focused security queue may still receive this vulnerability because the same IT organization manages Microsoft identities, endpoint access, vulnerability tickets, or mobile devices. The correct response is administrative rather than technical remediation on Windows:- Exclude unsupported Windows Chrome and Edge matches.
- Preserve the Android platform condition in the ticket.
- Route confirmed Android Chrome exposure to the mobile-management owner.
- Keep the finding tied to the complete installed Chrome version.
- Avoid broad language such as “Chrome is vulnerable across the enterprise.”
That wording keeps genuinely affected Android devices visible without creating unnecessary desktop remediation work.
Managed-Fleet Checklist
The following checklist is an operational application of the documented product and version boundary, not a procedure for any particular device-management platform.- Inventory Google Chrome installations on managed Android devices.
- Collect the complete four-part installed version.
- Flag every Android Chrome installation earlier than 150.0.7871.47.
- Treat missing, truncated, stale, or conflicting version information as unresolved.
- Remediate lower versions through the organization’s supported application-update process.
- Collect fresh version evidence after remediation.
- Close a finding only when Chrome reports 150.0.7871.47 or later.
- Record devices that cannot be checked or updated, along with an owner and next action.
- Exclude Windows Chrome findings that were created only through generic product-name matching.
- Evaluate Microsoft Edge and other Chromium-derived products separately.
- Continue monitoring authoritative product and vulnerability information for changes in scope or exploitation status.
Severity Calls for Prompt, Proportionate Action
CVE-2026-13929 has a visible CISA-ADP CVSS 3.1 score of 5.5, and Chrome classified it as Medium. The local attack vector and user-interaction requirement distinguish it from a remote, zero-click browser compromise.Those limitations do not make the vulnerability harmless. The assessment assigns high integrity impact, and Chrome’s description says an intended navigation restriction could be bypassed. Updating is a direct and comparatively low-disruption way to move an Android installation outside the affected range.
The appropriate response is therefore neither an emergency shutdown nor indefinite delay:
- Patch affected Chrome on Android installations.
- Verify the complete version after remediation.
- Keep unknown or lower versions open.
- Avoid describing the issue as an active remote zero-day.
- Avoid minimizing the integrity impact simply because user interaction is required.
Concise Limits and Provenance
The record combines information from several contributors, and those sources should remain distinct.Chrome is the source of the CVE description, the Android scope, the affected-version boundary, the Medium classification, and the displayed CWE-20 Improper Input Validation classification.
CISA-ADP supplied the visible CVSS 3.1 assessment of 5.5 and the SSVC values. The record history also shows that CISA-ADP added and later removed a separate CWE-602 contribution. That change should not be described as replacing, validating, or otherwise altering Chrome’s CWE-20 classification.
NVD presents the record and affected-product configuration, but the supplied material does not show an NVD-authored CVSS assessment. Reports should therefore label 5.5 as the CISA-ADP score displayed by NVD, not simply as an “NVD score.”
Exact calendar dates are not necessary to apply the remediation and have been omitted because the previously stated June 30, 2026 date is not sufficiently supported by the supplied material for this revision. The useful early-coverage sequence is limited to provenance: Chrome supplied the core vulnerability information, CISA-ADP contributed the visible assessment data, and NVD presented the record and platform-specific configuration.
Verify the Version and Keep the Scope Clean
CVE-2026-13929 has a narrow, measurable response. Chrome on Android before 150.0.7871.47 is affected. Update those installations and verify the complete version afterward. A device reporting only a major release, an old inventory result, or no current version remains unresolved.Chrome on Windows and Microsoft Edge are not established as affected by this record. Keeping that distinction visible prevents false-positive desktop tickets from consuming attention while vulnerable Android installations remain in service.
The forward-looking task is to monitor authoritative updates for a revised affected range, additional technical detail, a new exploitation assessment, or product-specific guidance from other browser vendors. Until such information appears, the defensible response remains focused: route the issue to the Android owner, update Chrome, verify version 150.0.7871.47 or later, and do not extend the finding to Windows Chrome or Edge without supporting evidence.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:41:15-07:00
NVD - CVE-2026-13929
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:41:15-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: security.snyk.io
Improper Input Validation in chromium | CVE-2026-13929 | Snyk
Improper Input Validation in chromium | CVE-2026-13929security.snyk.io - Related coverage: linuxsecurity.com
Fedora 44 Chromium 150.0.7871.46 Critical Security Release
Chromium update in Fedora 44 fixes 433 issues including critical flaws enhancing browser security.
linuxsecurity.com