CVE-2026-13868: Update Chrome Android to 150.0.7871.47

Google Chrome on Android versions earlier than 150.0.7871.47 are affected by CVE-2026-13868, a medium-severity flaw that the supplied National Vulnerability Database record describes as an inappropriate implementation in Chrome’s Network component. According to that record, a remote attacker who had already compromised a renderer could use crafted HTML to bypass site isolation. Android users should update Chrome to version 150.0.7871.47 or later and verify the complete installed version.

Who is affected / what to do​

Affected: Google Chrome on Android below 150.0.7871.47, according to the supplied NVD affected-product information.
Required action: Update Chrome to 150.0.7871.47 or later and verify the complete version after the update.
Not established by this record: The supplied NVD information does not establish exposure for Chrome on Windows, macOS, Linux, ChromeOS, Android WebView, or other browsers. Those products and platforms should not be marked affected by assumption.

Graphic urging users to update Chrome to version 150.0.7871.47 for enhanced security and site isolation.What CVE-2026-13868 Does—and Does Not Establish​

The public description is narrow. The supplied NVD record says CVE-2026-13868 affects Google Chrome on Android before 150.0.7871.47. It describes a remote attacker using crafted HTML to bypass site isolation after first compromising a renderer.
The renderer-compromise prerequisite is essential. CVE-2026-13868 is not described as the vulnerability that initially compromises the renderer. The record establishes a post-renderer-compromise site-isolation bypass, not a standalone path from an otherwise ordinary webpage to complete control of Chrome or the Android device.
The disclosed scenario can be summarized as follows:
  1. A Chrome renderer has already been compromised through some separate means not identified in this CVE.
  2. The attacker uses crafted HTML.
  3. The vulnerable Network implementation permits a site-isolation bypass.
That is the full supported attack description. The supplied record does not document the vulnerability that would provide the prerequisite renderer compromise, a complete working exploit chain, a public proof of concept, or the precise HTML and implementation conditions required to trigger the bypass.
It also does not establish any of the following outcomes:
  • A complete remote-code-execution exploit.
  • A one-step or “one-click” compromise.
  • A Chrome sandbox escape.
  • Android operating-system takeover.
  • Administrator or root privileges.
  • Arbitrary-file access.
  • Persistence on the device.
  • A demonstrated capability to read data from another site.
  • A demonstrated compromise of accounts, sessions, credentials, or cloud services.
  • Exposure of Chrome on desktop operating systems, ChromeOS, WebView, or other browsers.
Those limitations should constrain the article’s language without obscuring the remediation requirement. A known browser security-boundary flaw remains a valid reason to update, even when the public record does not describe a complete compromise.
CISA-ADP assigned the weakness classification CWE-346, Origin Validation Error, as shown in the supplied NVD record. That classification should be reported as assigned rather than expanded into an unsupported explanation of the specific validation failure. The public description does not identify the exact origin value involved, the relevant comparison or trust decision, or the practical access produced after successful exploitation.
Likewise, the record’s reference to site isolation does not provide a general technical specification for that feature. It does not document Chrome’s process architecture, Android’s isolation strategy, device-memory tradeoffs, hardened-mode availability, or which categories of information site isolation protects. Those broader architectural claims require separate authoritative documentation and are not necessary to apply the update.
The defensible conclusion is therefore precise: CVE-2026-13868 is a site-isolation bypass in Chrome on Android that requires a previously compromised renderer and crafted HTML. Versions below 150.0.7871.47 are affected. The supplied record does not establish a broader platform scope or a complete device-compromise scenario.

CVSS and SSVC Status​

CISA-ADP contributed a CVSS 3.1 base score of 6.5 Medium for CVE-2026-13868, according to the assessment displayed in the supplied NVD record. The corresponding vector is:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
The supplied record had not provided a separate NVD-authored CVSS 4.0, CVSS 3.x, or CVSS 2.0 assessment. Accurate reporting should therefore attribute the displayed 6.5 score to CISA-ADP rather than calling it an NVD calculation.
Assessment elementRecorded resultWhat the supplied NVD record supports
Chrome severityMediumChrome categorized the vulnerability as Medium
CISA-ADP CVSS 3.16.5 MediumCISA-ADP contributed the displayed score
Attack vectorNetworkThe CVSS vector records AV:N
Attack complexityLowThe CVSS vector records AC:L
Privileges requiredNoneThe CVSS vector records PR:N
User interactionRequiredThe CVSS vector records UI:R
ScopeUnchangedThe CVSS vector records S:U
Confidentiality impactNoneThe CVSS vector records C:N
Integrity impactHighThe CVSS vector records I:H
Availability impactNoneThe CVSS vector records A:N
NVD-authored CVSSNot providedNVD had not supplied its own assessment in the supplied record
The vector supports describing the vulnerability as network-accessible and low in attack complexity under the CVSS model, with no privileges required and user interaction required. Those values should not be translated into a more specific attack procedure than the record provides.
In particular, “user interaction required” does not by itself establish a single-click scenario. “Low attack complexity” is a CVSS metric and does not remove the separately documented prerequisite that the renderer must already have been compromised.
The CVSS vector scores high integrity impact but no confidentiality or availability impact. That should be reported as written. The article should not replace the recorded impact values with assumptions about cross-site reading, credential theft, arbitrary data disclosure, browser crashes, or device availability. Any explanation for why the vector was scored that way would be analysis unless supported by additional authoritative information.
CISA-ADP’s Stakeholder-Specific Vulnerability Categorization contribution records:
  • Exploitation: none.
  • Automatable: no.
  • Technical impact: partial.
These are point-in-time decision values displayed in the supplied NVD record. “Exploitation: none” means the supplied assessment did not identify exploitation; it should not be rewritten as proof that exploitation is impossible or that the status can never change. Conversely, nothing in the record supports describing CVE-2026-13868 as actively exploited.
“Automatable: no” should also be left within its recorded scope. It does not establish that malicious content cannot be distributed broadly, and it does not provide an exploit-complexity analysis beyond the SSVC selection itself.
“Technical impact: partial” is consistent with keeping the reported outcome narrower than complete browser or device compromise. It does not define the exact actions available after the site-isolation bypass.
Taken together, the assessments support prompt, calm remediation. The supplied evidence identifies an affected version range and a corrected threshold, but it does not establish an active campaign, a complete attack chain, or compromise of every device running an affected version.

Update Chrome on Android Now​

Android users can check and update Chrome immediately:
  1. Open Chrome on the Android device.
  2. Tap the three-dot menu.
  3. Select Settings.
  4. Select About Chrome.
  5. Read the complete version number.
  6. Confirm that the version is 150.0.7871.47 or later.
  7. If the version is earlier, open the Google Play Store.
  8. Search for Google Chrome.
  9. Select Update if an update is available.
  10. After the update finishes, reopen Chrome and return to three-dot menu > Settings > About Chrome.
  11. Verify that Chrome now displays 150.0.7871.47 or later.
The final verification matters. Opening the Play Store, enabling automatic updates, or initiating an update is not the same as proving that the device has crossed the affected-version boundary.
Users and support teams should compare the complete four-part version. A result that shows only “Chrome 150” is insufficient because it does not establish whether the installation is below or at the fixed build.
Installed Chrome version on AndroidStatus under the supplied NVD recordRequired response
Earlier than 150.0.7871.47AffectedUpdate Chrome and verify again
Exactly 150.0.7871.47Meets the stated thresholdRecord the verified version
Later than 150.0.7871.47Outside the stated affected rangeRecord the verified version
Only “Chrome 150” is knownUnverifiedObtain the complete four-part version
Version is missing, stale, or conflictingUnknownKeep the issue open until verified
Chrome is not installedNot applicable to that deviceRecord the product absence separately
The supplied NVD record supports version-based remediation but does not document an alternative configuration workaround. Clearing browsing data, closing tabs, using incognito mode, changing site permissions, or restarting the phone should not be presented as substitutes for installing a corrected Chrome version.
The record also does not establish that disabling JavaScript, changing isolation settings, or enabling another browser option prevents exploitation. Administrators should not substitute an inferred workaround for the explicit version threshold.

Narrow Enterprise Guidance​

For organizations, the key task is to establish which managed Android devices run Chrome below 150.0.7871.47 and then collect current evidence that those installations have been updated.
The supplied NVD record does not prescribe a mobile-device-management product, deployment channel, inventory agent, update policy, or enforcement design. Organizations should use the capabilities documented for their own management platforms rather than assuming that every platform can remotely update Chrome, force a relaunch, or block an application according to its four-part version.
A defensible enterprise process has four stages:
  1. Identify Android devices that have Google Chrome installed.
  2. Collect the complete installed Chrome version.
  3. Remediate every version below 150.0.7871.47 through the organization’s supported process.
  4. Collect fresh version evidence and keep unknown or lower results open.
A deployment status marked “successful” can be useful operational evidence, but the CVE-specific closure test remains the installed version. The strongest result is a current device record showing Chrome 150.0.7871.47 or later.

WindowsForum angle for Microsoft identity teams​

CVE-2026-13868 is not established as a Windows vulnerability by the supplied record. The actionable WindowsForum connection is administrative: teams responsible for Microsoft identities and browser-based access should inventory managed Android Chrome versions and require 150.0.7871.47 or later before allowing sensitive browser-based work, if their management and access platforms support that control.
That recommendation is intentionally conditional. The NVD record does not establish that a particular Microsoft, Google, or third-party platform can enforce a Chrome build threshold. Teams must confirm what their own products support before creating an access rule.
Where version-aware enforcement is unavailable, the immediate task remains inventory, user notification, supported remediation, and post-update verification. The article should not claim that conditional access, application-protection rules, session settings, or privileged-session architecture will compensate for the vulnerability without product-specific evidence.

Action checklist for administrators​

  • Inventory Google Chrome installations on managed Android devices.
  • Collect the complete four-part installed version.
  • Flag every Chrome installation below 150.0.7871.47.
  • Treat missing, stale, truncated, or conflicting version data as unresolved.
  • Direct affected users through the Chrome and Google Play update procedure.
  • Use an organization-controlled deployment method only where the management platform documents support for it.
  • Collect fresh version evidence after remediation.
  • Close the finding only when Chrome reports 150.0.7871.47 or later.
  • Record devices that cannot be verified and assign an owner and next action.
  • If supported by the organization’s management and access platforms, prevent devices below the threshold from performing sensitive browser-based work.
  • Evaluate Windows, macOS, Linux, ChromeOS, Android WebView, and other browsers separately rather than copying this Android Chrome threshold to them.
  • Monitor authoritative vulnerability and vendor information for any later change in affected scope or exploitation status.
A useful verification record should include the device identifier, operating-system platform, complete Chrome version, time of observation, remediation action, post-remediation version, and owner of any unresolved exception. This is an evidence checklist, not a claim that every management platform provides each field automatically.

Record Timeline Without Unsupported Dates​

The supplied NVD material shows that the public record was developed in stages, but the article does not need unconfirmed calendar dates to explain the sequence.

Timeline​

Chrome-originated vulnerability information: The record identified Google Chrome on Android, the Network component, the renderer-compromise prerequisite, crafted HTML, the site-isolation-bypass result, the Medium severity, and the affected boundary below 150.0.7871.47.
CISA-ADP assessment: CISA-ADP contributed the CVSS 3.1 vector and 6.5 Medium score, the CWE-346 Origin Validation Error classification, and the SSVC selections.
NVD and NIST presentation: The supplied NVD record presented the contributed vulnerability information, assessments, references, and affected-product configuration. NVD had not supplied its own CVSS assessment in that record.
This sequence is useful for attribution. A score or classification displayed on an NVD page is not necessarily calculated by NVD. For CVE-2026-13868, the 6.5 CVSS score, vector, CWE assignment, and SSVC values should remain attributed to CISA-ADP.
Specific claims involving June 30, July 1, or July 6, 2026, have been omitted because they are not needed to identify affected devices or apply the update and should not be treated as disclosure, release, enrichment, or rollout dates without confirmed source-level support.

Scope Discipline Prevents Bad Vulnerability Tickets​

The affected condition combines a product, platform, and version:
  • Product: Google Chrome.
  • Platform: Android.
  • Affected range: Versions earlier than 150.0.7871.47.
Dropping any part of that condition can produce inaccurate findings. A scanner or ticket that says only “Chrome below 150.0.7871.47” may incorrectly route remediation to Windows, macOS, Linux, or ChromeOS teams even though the supplied NVD record does not establish exposure on those platforms.
The same caution applies to Android WebView and other browsers. Shared components, Chromium ancestry, similar feature names, or overlapping browser behavior do not prove that another product contains the vulnerable implementation or uses Chrome’s corrected version number.
Administrators should therefore:
  • Apply the 150.0.7871.47 threshold directly to Chrome on Android.
  • Keep desktop Chrome out of this CVE’s affected population unless another authoritative source establishes applicability.
  • Evaluate Android WebView independently.
  • Consult each browser vendor before assigning the finding to another Chromium-based browser.
  • Avoid using the Chrome version threshold as a universal Chromium compliance rule.
This narrow handling is not merely editorial caution. It prevents wasted remediation work, inaccurate compliance metrics, and the possibility that genuinely affected Android devices will be hidden inside an incorrectly broad browser finding.

Verify the Version and Close the Gap​

CVE-2026-13868 is a medium-severity, post-renderer-compromise site-isolation bypass affecting Chrome on Android below 150.0.7871.47, according to the supplied NVD record. The public information does not establish a standalone renderer exploit, sandbox escape, Android takeover, arbitrary-file access, cross-site data-read capability, or exposure on Windows and other unlisted platforms.
The response is direct: open Chrome’s three-dot menu > Settings > About Chrome, verify the full version, and use the Google Play Store to update if it is below 150.0.7871.47. Enterprises should inventory managed Android Chrome installations, remediate lower versions, and require the corrected threshold for sensitive browser-based work where their management platform supports that control.
Patch Chrome on Android, verify 150.0.7871.47 or later, and keep every lower or unknown result open until it is resolved.

References​

  1. Primary source: NVD / Chromium
    Published: 2026-07-11T15:41:02-07:00
  2. Security advisory: MSRC
    Published: 2026-07-11T15:41:02-07:00
    Original feed URL
  3. Related coverage: chromium.org
  4. Related coverage: chromium.googlesource.com
  5. Related coverage: blog.chromium.org
 

Back
Top