CVE-2026-13816: Update Chrome Android to 150.0.7871.47

In brief: CVE-2026-13816 applies to Google Chrome on Android before version 150.0.7871.47; update affected devices to 150.0.7871.47 or later and verify the installed application version. Do not mark Windows, macOS, or Linux Chrome affected based on this CVE record alone.

Google fixed CVE-2026-13816 in Chrome for Android 150.0.7871.47 after finding that earlier versions insufficiently validated untrusted input in the browser’s File Input component. According to the CVE description, a remote attacker could use a crafted HTML page to leak cross-origin data when a user interacted with it.
Chromium rates the flaw High. Separately, the CISA-ADP contribution assigns a CVSS 3.1 base score of 6.5, which falls in the Medium range. NVD itself has not provided a CVSS assessment. The two available labels use different methods, but neither changes the remediation: Chrome for Android must be updated to version 150.0.7871.47 or later.
The public record does not establish remote code execution, arbitrary local-file theft, device takeover, or zero-click exploitation. CISA-ADP’s SSVC contribution records exploitation as “none,” automation as “no,” and technical impact as “partial.” Those details argue against panic, not against completing the update.

A File Input Bug Crossed an Important Browser Boundary​

Chrome’s public description is short but consequential. Insufficient validation of untrusted input in File Input allowed a crafted HTML page to leak cross-origin data in Chrome for Android versions before 150.0.7871.47.
Browsers are expected to prevent one website from reading data belonging to another website’s security context. CVE-2026-13816 matters because the described result is a failure of that separation: under the required conditions, information from one origin could become visible across an origin boundary.
The available description does not specify the exact data exposed, the complete sequence needed to trigger the leak, or every limitation on the affected data path. The linked Chromium issue is permission restricted, so the public record does not provide the implementation detail needed to reproduce the flaw or design exploit-specific detection.
That lack of detail should constrain both reassuring and alarming claims. The record supports a cross-origin data leak involving File Input on Android. It does not support claims of password extraction, arbitrary file access, complete account compromise, remote code execution, or control of the Android device.
The component name can invite broader interpretations because file-input features are designed to transfer user-selected data to web pages. Administrators should resist inferring more than the CVE description says. The established security consequence—cross-origin information disclosure—is sufficient reason to update without embellishing the attack scenario.

---

“High” and 6.5 Medium Measure the Flaw Differently​

The vulnerability has two severity labels that can appear inconsistent. Chromium classifies CVE-2026-13816 as High, while the CISA-ADP CVSS 3.1 contribution gives it a 6.5 Medium base score.
The 6.5 score is specifically CISA-ADP’s assessment, not an NVD CVSS score. NVD displays the contributed assessment but has not supplied its own CVSS evaluation.
The CISA-ADP vector is:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
In practical terms, that vector describes a network-reachable flaw with low attack complexity, no attacker privileges required, and required user interaction. It assigns High confidentiality impact while recording no direct integrity or availability impact.
Chromium’s High label is the vendor’s classification of the vulnerability in the context of Chrome’s architecture. CVSS is a standardized representation of selected exploitability and impact characteristics. A vendor can view a broken browser isolation control as High severity even when required interaction and confidentiality-only impact keep the numerical CVSS base score in the Medium range.
The user-interaction condition is meaningful because it rules out treating the published scenario as a confirmed zero-click attack. The public material does not, however, define the exact interaction required. Administrators should therefore describe the condition simply as user interaction and avoid inventing a particular gesture, delivery method, or workflow.
The vector also records no attacker privileges. That means the published assessment does not require the attacker to start with an account or elevated access on the affected device. It does not mean every page can automatically exploit the flaw or that exploitation has been observed.
High vendor severity and a 6.5 Medium CISA-ADP score can both be accurate. For remediation purposes, the important evidence remains the affected platform and fixed version.

CISA’s SSVC Record Supports Prompt, Controlled Patching​

CISA-ADP’s Stakeholder-Specific Vulnerability Categorization contribution records exploitation as “none,” automatable as “no,” and technical impact as “partial.”
“None” should be read as the exploitation status recorded in that contribution, not a guarantee that exploitation cannot occur. “No” for automation indicates that the attack was not assessed as readily automatable under the SSVC model. “Partial” distinguishes the reported information-disclosure consequence from a total technical impact.
Together with the CVSS vector, these fields place CVE-2026-13816 below the most urgent category of browser emergencies. The supplied record does not establish active exploitation, zero-click compromise, integrity impact, availability impact, or independent code execution.
That supports a prompt, controlled update followed by version verification. It does not support isolating every Android device or initiating incident response solely because an older Chrome build is discovered. It also does not justify leaving an affected browser in service after the corrected release is available.
Organizations can prioritize confirmed exploited vulnerabilities and critical code-execution flaws ahead of this issue while still setting a near-term completion target for the Android Chrome update. The correct posture is routine but verifiable remediation rather than either alarm or indefinite deferral.

---

The Android-Only Scope Is the Key Operational Fact​

The affected product described in the CVE record is Google Chrome on Android. The fixed-version boundary is 150.0.7871.47.
NVD links to a Chrome desktop release-notes URL, but the supplied material does not establish the contents of that release page or prove that it lists CVE-2026-13816 as a desktop vulnerability. A reference link is not, by itself, evidence that Windows, macOS, or Linux Chrome is affected.
Administrators should follow the affected-product description rather than expand the scope from the title or location of a reference.

Deployment state	Platform	Chrome version	CVE status	Operational meaning
Older installation	Android	Earlier than 150.0.7871.47	Affected	Update Chrome and verify the installed version
Corrected threshold	Android	150.0.7871.47	Fixed boundary	Meets the minimum version identified in the record
Newer installation	Android	Later than 150.0.7871.47	Beyond fixed boundary	No need to install the exact original fixed build
Desktop Chrome	Windows, macOS, or Linux	Not specified	Not listed as affected	Do not assign exposure from this CVE record alone
Other Chromium-based browsers	Any	Product-specific	Not established	Check that browser vendor’s own advisory and version data

This distinction is especially valuable to Windows-focused security teams that manage multiple endpoint platforms from a common vulnerability queue. A desktop-oriented dashboard may show the Chrome product name and a desktop release reference without clearly presenting the Android limitation.
The appropriate ticket scope is Chrome on Android below 150.0.7871.47. A Windows device should not be labeled vulnerable to CVE-2026-13816 merely because Chrome is installed on it. Conversely, confirming that desktop Chrome is current does not establish that Android devices have received the required application update.
The CVE is Android-specific, but responsibility may still rest with the same endpoint, vulnerability, identity, or security-operations team that manages Windows. Platform scope determines which assets require remediation; it does not necessarily determine which internal team owns the work.

Treat Product, Platform, and Version as a Single Test​

Vulnerability records combine product descriptions, platform data, standardized identifiers, references, and version boundaries. Those elements can be displayed differently by different inventory and vulnerability-management products.
The supplied NVD information associates the issue with Chrome versions below the fixed threshold and Android. That supports treating product, platform, and version together when evaluating exposure. It does not establish a universal rule for how every scanner interprets the configuration or prove a particular failure mode in third-party tools.
Administrators should nevertheless review any result that conflicts with the CVE’s stated scope. The validation question is straightforward:

1. Is the product Google Chrome?
2. Is it installed on Android?
3. Is the installed version earlier than 150.0.7871.47?

If all three are true, the device is within the published affected range. If the platform is Windows, macOS, or Linux, this CVE record alone does not establish exposure. If the product is another Chromium-based browser, its status must be obtained from that product’s vendor rather than inferred from Chrome’s version number.
The Android operating-system patch level is not sufficient evidence of remediation. The vulnerable product is Chrome, and the correction boundary is expressed as a Chrome application version. An Android device can meet an operating-system patch policy while still carrying an older Chrome package.
The reverse is also true: an updated Chrome application does not prove that the Android operating system meets the organization’s broader patch requirements. Browser and operating-system compliance should remain separate measurements even when one management platform reports both.

Public Information Does Not Support Exploit-Specific Detection​

The restricted Chromium issue does not provide public implementation details in the supplied material. The available record gives defenders the component, affected platform, fixed version, required interaction, and confidentiality consequence, but not an exploit blueprint.
Administrators therefore do not have a supported basis for creating detection logic around a specific URL, HTML sequence, filename, file type, network signature, or device artifact. Claims about the issue page’s hidden contents would be speculative, as would a claim explaining why access is restricted.
Version-based exposure management is the dependable control. Determine whether Chrome for Android is below 150.0.7871.47, update it, and confirm that the corrected package is installed.
The same evidence limit applies to other Chromium-derived browsers. Shared code may justify asking vendors whether their products are affected, but it does not prove exposure, patch equivalence, or the timing of a downstream correction. Each vendor’s advisory and installed version should be evaluated separately.
For Google Chrome on Android, the remediation threshold is explicit. For another browser, security teams should seek a vendor-confirmed affected range and fixed release before opening or closing a CVE-specific finding.

---

The Risk Is a Cross-Origin Confidentiality Failure​

File Input sits at a sensitive point between web content, browser controls, Android services, and data selected by the user. The browser must ensure that a page receives only information permitted by the relevant security context and interaction.
CVE-2026-13816 shows why validation in that path matters. The stated result is not a general failure of Android’s file picker or proof that websites can read every local file. It is a Chrome validation flaw that could allow cross-origin information disclosure under the published conditions.
The CISA-ADP vector assigns High confidentiality impact and no direct integrity or availability impact. That distinction should be preserved in security communications. The CVE is not publicly described as changing protected information, stopping a service, or independently executing attacker-controlled code.
At the same time, confidentiality-only does not mean inconsequential. Browser origin separation is intended to prevent unrelated web contexts from observing each other’s data. A failure in that control warrants remediation even when the exact exposed information and complete triggering sequence are not public.
Organizations may apply their own environmental priorities based on how managed Android browsers are used. That is an internal risk decision, not a reason to add unsupported consequences to the CVE description. The evidence-led statement is that the flaw can leak cross-origin data and is fixed by updating Chrome for Android.

---

Timeline​

Initial publication: The CVE record identified Google Chrome on Android as affected below version 150.0.7871.47 and described insufficient validation in File Input leading to cross-origin data disclosure.
CISA-ADP enrichment: CISA-ADP contributed the CVSS 3.1 vector and 6.5 Medium score. It also supplied SSVC information recording exploitation as none, automation as no, and technical impact as partial.
Subsequent metadata processing: The available record shows more than one CISA-ADP modification timestamp, but the supplied facts do not identify what changed during each modification. No metadata-history narrative should be inferred from timestamps alone.
NVD analysis: NVD added platform and product configuration information and displayed references associated with the record. NVD has not supplied its own CVSS assessment.
Current remediation boundary: Chrome for Android 150.0.7871.47 is the first fixed version identified in the supplied record. Later versions also satisfy the CVE-specific version requirement.

Updating a Personal Android Device​

For an individually managed Android phone or tablet, use the Google Play Store to install the current Chrome release:

1. Open Google Play Store.
2. Tap the profile icon.
3. Select Manage apps & device.
4. Open Updates available.
5. Find Google Chrome.
6. Tap Update.
7. Wait for installation to complete.
8. Open Chrome.
9. Tap ⋮.
10. Select Settings.
11. Open About Chrome.
12. Verify that the displayed version is 150.0.7871.47 or later.

If the Play Store offers a version newer than 150.0.7871.47, install the newer version. The objective is to reach or exceed the fixed boundary, not to pin the device permanently to the first corrected build.
If Chrome does not appear under Updates available, check the version through Chrome > ⋮ > Settings > About Chrome. A device already running 150.0.7871.47 or later meets the CVE-specific requirement.
An update being offered is not proof that it was installed. The version shown by Chrome after the update is the stronger local verification evidence.

Managed Android Deployment and Verification​

Managed fleets should deploy the current approved Chrome release through their existing mobile device management or enterprise mobility management product. There is no universal MDM or EMM console path that applies to every product.
The administrator must use their management product’s managed-app inventory or application-version report to identify the installed Google Chrome version on each Android device. An application approval, assignment, or deployment command is not equivalent to confirmation that the corrected package is present.
A useful enterprise report should include, where available:

• Device identity
• Android platform and operating-system version
• Google Chrome package or application name
• Installed Chrome version
• Application deployment or compliance state
• Last device check-in
• Device ownership or management classification
• Any update failure or pending-install status

Filter that inventory for Android devices with Chrome versions earlier than 150.0.7871.47. Deploy or require an update, allow the devices to check in again, and then rerun the inventory report.
Remediation should be closed only when the management system reports version 150.0.7871.47 or later—or when the device has been retired, wiped, removed from access, or otherwise handled through an approved exception process.
Administrators should separately review devices that have stale check-ins, are offline, are outside the normal deployment group, or do not report application versions. A missing version is not proof of compliance. It is an evidence gap that requires follow-up.
If the organization permits unmanaged Android devices to access corporate resources, the vulnerability-management team may not have direct application inventory. In that case, the organization should use whatever supported access-control or device-compliance mechanism it has adopted to require a current browser or current managed device state. The appropriate mechanism depends on the organization’s identity, mobility, and access architecture.

Version Evidence Beats Update Assumptions​

The strongest evidence of remediation is the installed Chrome version on the Android device. Statements such as “automatic updates are enabled,” “Chrome is approved,” “the application was assigned,” or “the deployment job succeeded” describe process state rather than final security state.
A device can remain below the fixed version because it has not checked in, has not downloaded the package, lacks storage, is subject to a deployment restriction, or has not completed installation. The specific cause matters for troubleshooting, but the remediation test remains the same: is the installed version at least 150.0.7871.47?
Organizations using deployment rings should decide how quickly to move the update through testing and production. The lack of recorded exploitation supports a controlled process. The network attack vector, low complexity, lack of required attacker privileges, and High confidentiality impact argue against leaving the rollout open-ended.
Testing should focus on the organization’s real Android Chrome dependencies, including managed browser policy, authentication, application access, and legitimate file-input workflows. Once the approved build passes the required checks, administrators should complete deployment and verify the fleet rather than treating approval as the end of the task.
If a device cannot install a corrected Chrome release, administrators need a documented disposition. Depending on organizational policy, that may involve removing the device from access, replacing unsupported hardware, correcting Play Store or management restrictions, or recording a time-limited exception with compensating controls.
The CVE should not remain indefinitely open with the explanation that an update was attempted. It should be resolved through verified installation or an explicit risk-handling decision.

Admin verification table​

Evidence	What it proves	Sufficient to close the CVE?
Chrome update approved in management console	The application is permitted or available	No
Chrome update assigned to a device group	Deployment was requested	No
Automatic application updates enabled	The device is configured to seek updates	No
Deployment status says successful	The management workflow reports success	Verify the installed version
Device reports Chrome 150.0.7871.47	The device reached the first fixed build	Yes
Device reports a later Chrome version	The device is beyond the fixed boundary	Yes
Android OS patch level is current	The operating system meets a separate requirement	No
Desktop Chrome is current	A Windows, macOS, or Linux browser was updated	No evidence about Android
Chrome version is missing or inventory is stale	Compliance cannot be established	No

Scanner and Ticket Handling​

When a vulnerability scanner or asset dashboard reports CVE-2026-13816, the remediation team should verify that the finding identifies an Android device and a Chrome version below 150.0.7871.47.
A finding assigned to Windows, macOS, or Linux should be reviewed rather than automatically accepted. The CVE record supplied for this article does not list those platforms as affected. The appropriate disposition is to document that the published scope is Chrome on Android and to avoid claiming desktop exposure without additional vendor evidence.
A result for another Chromium-based browser also requires product-specific review. Do not map Google Chrome’s fixed version directly to another vendor’s numbering scheme, and do not assume that the absence of a Chrome package means the underlying issue is either present or absent.
Tickets for confirmed Android exposure should contain:

• The affected device or device group
• The installed Chrome version
• The minimum corrected version, 150.0.7871.47
• The deployment owner
• The expected completion date
• The required post-deployment evidence
• The treatment for devices that fail to update or check in

This makes the ticket actionable and keeps the remediation discussion centered on evidence rather than speculation about exploit delivery or hidden implementation details.

Action Checklist for Admins​

• Inventory Google Chrome versions on Android devices.
• Identify installations earlier than 150.0.7871.47.
• Deploy the current approved Chrome version through the organization’s MDM or EMM product.
• Use that product’s managed-app inventory or version report to verify installation.
• Recheck offline, stale, failed, excluded, and non-reporting devices.
• Do not use Android OS patch level as proof that Chrome is corrected.
• Do not use desktop Chrome compliance as proof of Android remediation.
• Do not mark Windows, macOS, or Linux Chrome affected from this CVE record alone.
• Validate other Chromium-based browsers against their vendors’ own advisories.
• Close findings only after confirming Chrome 150.0.7871.47 or later, or after completing an approved alternative disposition.
• Continue monitoring the vendor and NVD records for supported changes to scope or exploitation status.

What Admins Should Do Now​

Update Chrome on Android to 150.0.7871.47 or later and verify the installed version. Individual users should open Google Play Store > profile icon > Manage apps & device > Updates available > Google Chrome > Update, then open Chrome > ⋮ > Settings > About Chrome and confirm version 150.0.7871.47 or later.
Managed-environment administrators should deploy the update through their existing MDM or EMM product and verify it through that product’s managed-app inventory or application-version report. Do not assume that assignment, automatic updates, a current Android OS patch level, or desktop Chrome compliance proves remediation.
Finally, keep the scope precise: CVE-2026-13816 is established here as a Chrome-for-Android issue. Do not mark Windows, macOS, or Linux Chrome affected based on this CVE record alone.

---

References​

1. Primary source: NVD / Chromium
   Published: 2026-07-11T15:40:50-07:00
   
   

   NVD - CVE-2026-13816

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-07-11T15:40:50-07:00
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
3. Related coverage: chromium.googlesource.com
   
   Cross-Origin Read Blocking (CORB)