CVE-2026-13866 affects Google Chrome on Android before 150.0.7871.47. A remote attacker who has already compromised Chrome’s renderer could use crafted HTML to bypass Site Isolation. Update Chrome to 150.0.7871.47 or later.
The renderer-compromise prerequisite changes how the issue should be triaged: this CVE describes a security-boundary bypass that may follow an earlier compromise, not a complete attack chain by itself. The current affected configuration is limited to Chrome on Android. Administrators should remediate that product and should not automatically open desktop-Chrome or all-Chromium-browser tickets from this CVE alone.
The available CVSS 3.1 assessment assigns a base score of 6.5 Medium with this vector:
The assessment is contributed through CISA-ADP. It should not be labeled as an NVD-generated score merely because it appears in an NVD record.
The public attack description begins after the renderer has already been compromised. At that point, a remote attacker could use crafted HTML to exploit the Input implementation problem and bypass Site Isolation. The record does not identify how the renderer compromise occurs or name another vulnerability that supplies it.
That prerequisite does not eliminate the need to patch. Site Isolation is an important browser security boundary, and a weakness that becomes useful after renderer compromise may contribute to a broader exploit chain. It does, however, prevent the CVE from being accurately described as a stand-alone one-page compromise of Chrome or Android.
The comparison applies to the Chrome application version, not the Android operating-system version or Android security-patch level. A current Android patch date does not demonstrate that the installed Chrome application has crossed the correction threshold.
Users can generally update Android applications through Google Play, while administrators may deploy or validate the release through their managed application platform. Google can change menu names and interface layouts, so the exact navigation may vary by device, Android release, Play Store version, management policy, and Chrome build. The security test is the resulting application version: 150.0.7871.47 or later.
If the visible interface does not provide a clear version check, users should consult Chrome’s application details or their device’s application-information screen. Enterprise administrators should prefer inventory or managed-app reporting when it reliably exposes the installed package version.
The prerequisite also affects incident classification. Security teams should not convert this record into an assertion that visiting any malicious page automatically compromises the browser, escapes the sandbox, or controls the Android device. A broader incident may still involve those outcomes, but they would require evidence beyond this CVE’s public description.
For vulnerability management, the practical decision remains straightforward: an affected Chrome version should be updated. For threat hunting and incident response, the record is less prescriptive because it does not disclose a proof of concept, exploit signature, malicious sample, or detailed code path.
These metrics should be reported as assessment values rather than expanded into unsupported attack details. In particular, user interaction required does not reveal whether the user must open a page, select a control, type information, or perform another action. The exact interaction is undisclosed.
The low attack-complexity value also does not cancel the renderer-compromise prerequisite stated in the vulnerability description. CVSS expresses standardized scoring assumptions; the prose description supplies an explicit condition that remains essential to understanding the attack model.
The vector assigns no confidentiality or availability impact. Accordingly, this CVE alone does not support definitive claims of data theft, service disruption, browser crashes, or denial of service. Its scored impact is concentrated on integrity.
Similarly, “crafted HTML” identifies the type of material involved but not its exact construction. No particular HTML element, script, browser event, form action, or user gesture should be presented as the trigger without further disclosure.
These limits support a disciplined administrative rule: patch what the current affected configuration names, then require separate evidence before broadening product or platform scope.
This current-state summary avoids assigning individual changes to an “initial” record or claiming that a contributor added or removed a specific field when the supplied change history does not support that precision.
“Automatable: no” and “technical impact: partial” should receive the same restrained treatment. The public record does not disclose enough technical information to explain the complete reasoning behind those selections or to identify exactly which sites, browser contexts, accounts, or data could be affected.
The remediation decision does not depend on extrapolating from the SSVC fields. Chrome on Android versions below the correction threshold remain affected and should be updated.
A device running an affected version demonstrates exposure, not exploitation. Conversely, confirming a corrected version demonstrates that the current installation is outside the stated affected range; it does not determine whether an older installation was previously targeted.
Organizations investigating suspicious browser activity can still apply their normal incident-response procedures. Evidence from endpoint telemetry, mobile-device management, network monitoring, account activity, or other vulnerabilities may justify a wider investigation. Those activities should be described as general defensive practice rather than CVE-specific detection guidance.
For routine vulnerability management, version remediation is the dependable control available from the current record.
Administrators should not compare another browser’s version number directly with Chrome 150.0.7871.47. That threshold belongs to the Google Chrome product identified in the affected configuration. Another Android browser requires its own vendor advisory, affected-version statement, or other product-specific evidence.
The same rule applies to desktop Chrome. This CVE’s current scope does not justify opening remediation tickets for Chrome on Windows, macOS, Linux, or ChromeOS. If later vendor information expands the affected range, those platforms can be evaluated at that time.
This disciplined scope rule is the principal WindowsForum operational value-add: remediate Chrome on Android now, but avoid generating unsupported desktop-Chrome or all-Chromium findings from a narrowly scoped CVE.
The issue has a CISA-ADP-contributed CVSS 3.1 score of 6.5 Medium. The prerequisite narrows the attack model but does not remove the need to patch affected installations. Users and administrators should update Chrome on Android to 150.0.7871.47 or later and verify the application version.
The current evidence supports a narrow response rather than a platform-wide Chromium alert. Desktop Chrome, other Chromium-based Android browsers, a renderer-compromise technique, and a complete device-takeover chain are outside the established scope.
Future public disclosure may explain the Input implementation error, identify the required user interaction, clarify the post-bypass impact, or establish whether related products share the vulnerable code. Until then, the sound course is to remediate the named Android product, preserve the contributor attribution for the severity assessment, and expand scope only when additional vendor evidence warrants it.
The renderer-compromise prerequisite changes how the issue should be triaged: this CVE describes a security-boundary bypass that may follow an earlier compromise, not a complete attack chain by itself. The current affected configuration is limited to Chrome on Android. Administrators should remediate that product and should not automatically open desktop-Chrome or all-Chromium-browser tickets from this CVE alone.
Immediate action checklist
- Update Google Chrome on affected Android devices.
- Confirm that the installed Chrome application version is 150.0.7871.47 or later.
- Use the device’s application-management or enterprise-management interface to verify deployment where possible.
- Remediate Chrome on Android; do not expand the ticket to desktop Chrome or every Chromium-based browser without product-specific evidence.
A Medium-Rated Flaw With an Important Prerequisite
CVE-2026-13866 is described as an inappropriate implementation in Chrome’s Input component. The current record lists CWE-20, Improper Input Validation, as Chrome’s weakness classification, but the underlying implementation details have not been publicly disclosed.The available CVSS 3.1 assessment assigns a base score of 6.5 Medium with this vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:NThe assessment is contributed through CISA-ADP. It should not be labeled as an NVD-generated score merely because it appears in an NVD record.
The public attack description begins after the renderer has already been compromised. At that point, a remote attacker could use crafted HTML to exploit the Input implementation problem and bypass Site Isolation. The record does not identify how the renderer compromise occurs or name another vulnerability that supplies it.
That prerequisite does not eliminate the need to patch. Site Isolation is an important browser security boundary, and a weakness that becomes useful after renderer compromise may contribute to a broader exploit chain. It does, however, prevent the CVE from being accurately described as a stand-alone one-page compromise of Chrome or Android.
Affected Scope and Version Threshold
The affected configuration identifies Google Chrome running on Android, with versions before 150.0.7871.47 in the vulnerable range.| Security state | Product and version | Administrative response |
|---|---|---|
| Affected | Chrome on Android earlier than 150.0.7871.47 | Update the Chrome application |
| Correction threshold | Chrome on Android 150.0.7871.47 | Confirm installation |
| Later release | Chrome on Android later than 150.0.7871.47 | Confirm the reported application version |
| Desktop Chrome | Not identified in the affected configuration | Do not mark affected from this CVE alone |
| Other Chromium-based Android browsers | Not identified as affected products | Obtain vendor-specific information |
Users can generally update Android applications through Google Play, while administrators may deploy or validate the release through their managed application platform. Google can change menu names and interface layouts, so the exact navigation may vary by device, Android release, Play Store version, management policy, and Chrome build. The security test is the resulting application version: 150.0.7871.47 or later.
If the visible interface does not provide a clear version check, users should consult Chrome’s application details or their device’s application-information screen. Enterprise administrators should prefer inventory or managed-app reporting when it reliably exposes the installed package version.
Why the Renderer Prerequisite Matters
The supported attack sequence is concise:- The attacker is remote.
- Chrome’s renderer process has already been compromised.
- Crafted HTML reaches the vulnerable behavior in the Input component.
- The attacker can bypass Site Isolation on an affected Chrome for Android release.
The prerequisite also affects incident classification. Security teams should not convert this record into an assertion that visiting any malicious page automatically compromises the browser, escapes the sandbox, or controls the Android device. A broader incident may still involve those outcomes, but they would require evidence beyond this CVE’s public description.
For vulnerability management, the practical decision remains straightforward: an affected Chrome version should be updated. For threat hunting and incident response, the record is less prescriptive because it does not disclose a proof of concept, exploit signature, malicious sample, or detailed code path.
Reading the CVSS Assessment
The contributed CVSS vector records the following values:| Metric | Value | What the assessment indicates |
|---|---|---|
| Attack Vector | Network | The assessed attack is remotely reachable |
| Attack Complexity | Low | The vector does not assign a special complexity condition |
| Privileges Required | None | An authorized account or existing user privilege is not required |
| User Interaction | Required | Some user participation is included in the assessed scenario |
| Scope | Unchanged | The scored impact remains within the same security authority |
| Confidentiality | None | The vector assigns no confidentiality impact |
| Integrity | High | The vector assigns high integrity impact |
| Availability | None | The vector assigns no availability impact |
The low attack-complexity value also does not cancel the renderer-compromise prerequisite stated in the vulnerability description. CVSS expresses standardized scoring assumptions; the prose description supplies an explicit condition that remains essential to understanding the attack model.
The vector assigns no confidentiality or availability impact. Accordingly, this CVE alone does not support definitive claims of data theft, service disruption, browser crashes, or denial of service. Its scored impact is concentrated on integrity.
Scope Limits
The component label Input should also be used without guessing at a narrower subsystem. It does not by itself prove that the bug resides in Android’s keyboard, touch drivers, password fields, HTML forms, or the operating system’s input framework.
Similarly, “crafted HTML” identifies the type of material involved but not its exact construction. No particular HTML element, script, browser event, form action, or user gesture should be presented as the trigger without further disclosure.
These limits support a disciplined administrative rule: patch what the current affected configuration names, then require separate evidence before broadening product or platform scope.
Current Record Attribution
The present record can be summarized without reconstructing an uncertain field-by-field history:- Chrome’s contribution identifies the vulnerability in the Input component, the renderer-compromise prerequisite, crafted HTML, the Site Isolation bypass, the Android version boundary, and CWE-20.
- CISA-ADP’s contribution provides the CVSS 3.1 vector and a score of 6.5 Medium, along with SSVC assessment fields.
- NVD’s presentation includes the affected configuration for Chrome on Android and
NVD-CWE-noinfo, indicating that NVD did not provide a more specific independent weakness classification from the available information.
Current-state timeline
| Record element | Present attribution or status |
|---|---|
| Vulnerability description and Chrome weakness classification | Chrome contribution |
| CVSS 3.1 score of 6.5 Medium | CISA-ADP contribution |
| SSVC assessment fields | CISA-ADP contribution |
| Chrome on Android affected configuration | Presented in the current NVD record |
| Detailed Chromium implementation notes | Not publicly available through the restricted issue |
| Established correction threshold | Chrome 150.0.7871.47 or later |
SSVC and Exploitation Status
The available CISA-ADP SSVC contribution records:- Exploitation: None
- Automatable: No
- Technical impact: Partial
“Automatable: no” and “technical impact: partial” should receive the same restrained treatment. The public record does not disclose enough technical information to explain the complete reasoning behind those selections or to identify exactly which sites, browser contexts, accounts, or data could be affected.
The remediation decision does not depend on extrapolating from the SSVC fields. Chrome on Android versions below the correction threshold remain affected and should be updated.
Detection and Incident Response
The public material does not provide indicators of compromise, a malicious HTML sample, a network signature, a crash pattern, a browser warning, or a distinctive log entry. Security teams therefore should not advertise a particular string, event, file, or alert as a validated detector for CVE-2026-13866 based on this record alone.A device running an affected version demonstrates exposure, not exploitation. Conversely, confirming a corrected version demonstrates that the current installation is outside the stated affected range; it does not determine whether an older installation was previously targeted.
Organizations investigating suspicious browser activity can still apply their normal incident-response procedures. Evidence from endpoint telemetry, mobile-device management, network monitoring, account activity, or other vulnerabilities may justify a wider investigation. Those activities should be described as general defensive practice rather than CVE-specific detection guidance.
For routine vulnerability management, version remediation is the dependable control available from the current record.
Other Browsers and Desktop Platforms
Shared Chromium ancestry is not enough to mark another browser as affected. Vendors may use different code snapshots, modify the relevant implementation, disable a code path, or ship a correction under a different product version.Administrators should not compare another browser’s version number directly with Chrome 150.0.7871.47. That threshold belongs to the Google Chrome product identified in the affected configuration. Another Android browser requires its own vendor advisory, affected-version statement, or other product-specific evidence.
The same rule applies to desktop Chrome. This CVE’s current scope does not justify opening remediation tickets for Chrome on Windows, macOS, Linux, or ChromeOS. If later vendor information expands the affected range, those platforms can be evaluated at that time.
This disciplined scope rule is the principal WindowsForum operational value-add: remediate Chrome on Android now, but avoid generating unsupported desktop-Chrome or all-Chromium findings from a narrowly scoped CVE.
Action Checklist for Users and Administrators
Android users
- Use Google Play or the device’s application-management interface to check for a Chrome update.
- Install the available corrected release.
- Verify that the Chrome application reports version 150.0.7871.47 or later.
- If the version remains below the threshold, check again for managed-device restrictions, staged availability, or an outstanding application update.
Administrators
- Inventory the installed Google Chrome package version on managed Android devices.
- Identify devices running a release earlier than 150.0.7871.47.
- Approve, deploy, or permit the corrected Chrome release through the organization’s managed application channel.
- Confirm installation using reliable application-version inventory.
- Track devices that cannot reach the correction threshold because of management policy, update availability, device compatibility, or enrollment problems.
- Do not substitute the Android OS version or security-patch date for the Chrome application version.
- Do not automatically mark desktop Chrome or other Chromium browsers as affected.
- Escalate related products only when vendor-specific evidence supports doing so.
The Bottom Line
CVE-2026-13866 affects Google Chrome on Android before version 150.0.7871.47. It is described as an inappropriate implementation in the Input component that could allow a remote attacker, after compromising Chrome’s renderer, to use crafted HTML to bypass Site Isolation.The issue has a CISA-ADP-contributed CVSS 3.1 score of 6.5 Medium. The prerequisite narrows the attack model but does not remove the need to patch affected installations. Users and administrators should update Chrome on Android to 150.0.7871.47 or later and verify the application version.
The current evidence supports a narrow response rather than a platform-wide Chromium alert. Desktop Chrome, other Chromium-based Android browsers, a renderer-compromise technique, and a complete device-takeover chain are outside the established scope.
Future public disclosure may explain the Input implementation error, identify the required user interaction, clarify the post-bypass impact, or establish whether related products share the vulnerable code. Until then, the sound course is to remediate the named Android product, preserve the contributor attribution for the severity assessment, and expand scope only when additional vendor evidence warrants it.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:41:01-07:00
NVD - CVE-2026-13866
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:41:01-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromium.org
- Related coverage: chromium.googlesource.com
- Related coverage: blog.chromium.org
Chromium Blog: Recent Site Isolation improvements
In July 2018 we launched Site Isolation in Chrome as a way to secure desktop browsers against the risk of side-channel attacks like Spectr...blog.chromium.org
- Related coverage: cvefeed.io
CVE-2026-13866 - Google Chrome Android Information Disclosure
Inappropriate implementation in Input in Google Chrome on Android prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)cvefeed.io
