Chrome for Android versions earlier than 150.0.7871.47 are affected by CVE-2026-13939; update Chrome to version 150.0.7871.47 or later. Chrome on Windows is not listed as affected by the current National Vulnerability Database record.
The medium-severity WebShare input-validation flaw could allow a remote attacker who has already compromised Chrome’s renderer process to use a crafted HTML page for UI spoofing. It is not described as a stand-alone browser takeover, and CISA’s assessment records no known exploitation, but the renderer prerequisite does not eliminate the need to patch affected Android devices.
CVE-2026-13939 concerns insufficient validation of untrusted input in WebShare in Chrome for Android. According to the public description, an attacker who had already compromised the renderer process could use a crafted HTML page to spoof UI. The assigned weakness category is CWE-20, Improper Input Validation.
The fixed boundary is explicit: Chrome for Android versions before 150.0.7871.47 are affected. Version 150.0.7871.47 meets the minimum boundary identified in NIST’s analysis, and later versions fall outside the stated affected range.
Individual Android users should update Chrome through Google Play and verify the installed version inside Chrome. Administrators should inventory Chrome versions on Android devices that access organizational resources and confirm that affected installations have reached the fixed boundary.
For Windows administrators, the key scope distinction is equally important. The NVD configuration identifies Chrome together with Android, and the vulnerability description repeatedly specifies Chrome on Android. Chrome on Windows is not listed as affected, even though the record includes a reference whose title concerns a desktop Stable Channel update.
That desktop reference does not, by itself, expand the affected platform. Unless Google or another authoritative record supplies new information, administrators should not classify Windows endpoints as vulnerable to CVE-2026-13939 solely because that reference appears in the record.
That wording limits what can responsibly be claimed. Visiting a crafted page is not described as sufficient, by itself, to compromise Chrome. CVE-2026-13939 instead supplies a potential follow-on capability after an attacker has gained control in the renderer through some separate vulnerability or condition.
The documented result is manipulation of what the user sees or understands, rather than direct disclosure of data, loss of availability, or system-level code execution. The public material does not state that this CVE independently steals files, installs software, escapes the browser sandbox, compromises Android, or takes control of the device.
The restricted Chromium issue does not expose the reproducer, patch details, or exact interface element involved. It would therefore be speculative to describe a particular fake share dialog, permission request, account prompt, destination list, credential screen, or other visual result. The supported conclusion is narrower: insufficient WebShare input validation could enable UI spoofing after renderer compromise.
The exclusive version boundary matters during inventory checks. A device reporting 150.0.7871.47 is at the identified fixed boundary rather than below it. Any earlier Chrome version remains within the affected range described by the NVD configuration.
The same distinction should be preserved in security alerts and vulnerability-management tickets. “Google Chrome” is not a sufficiently precise product label for this case. The finding should identify Google Chrome on Android earlier than 150.0.7871.47 so that Windows systems are not incorrectly included and Android devices are not overlooked.
This makes the flaw potentially useful as part of a larger chain, but the public record does not identify the preceding vulnerability or describe a complete chain. It also does not establish that a working chain has been used against real targets.
CISA-ADP’s CVSS 3.1 calculation produces a base score of 3.1, categorized as Low. The complete vector is
In practical terms, the vector describes network-delivered content, high attack complexity, no required attacker privileges, required user interaction, unchanged scope, no documented confidentiality or availability impact, and low integrity impact.
The high attack-complexity metric is consistent with the documented need for a prior renderer compromise, but that relationship is an inference from the public vector and vulnerability description. The available material does not explicitly state that CISA selected the high-complexity value solely or specifically because of the renderer prerequisite.
Required user interaction also fits the stated UI-spoofing impact. A spoofed presentation is generally useful only if the user sees it and responds in a way that advances the attacker’s objective. The public record does not provide enough detail to specify what that interaction would look like in this case.
Chrome rates the vulnerability Medium, while the CISA-ADP CVSS calculation is 3.1 Low. These labels come from different sources and scoring approaches. Chrome supplied the vendor severity rating; CISA-ADP supplied the published CVSS 3.1 vector. NVD had not supplied its own CVSS 3.x, CVSS 4.0, or CVSS 2.0 assessment in the described record.
Administrators should therefore avoid saying that “NVD scored the vulnerability 3.1.” More precisely, NVD displays a 3.1 score contributed by CISA-ADP.
The low base score does not change the fixed-version decision. Affected Android installations have a documented update boundary, and updating removes the known condition. At the same time, the score and prerequisites do not support treating this CVE alone as evidence of a widespread or independently successful browser compromise.
“Exploitation: none” should be interpreted as an assessment of the evidence available when the record was produced. It is not proof that exploitation is impossible, that private research does not exist, or that the issue could never be combined with another vulnerability.
Similarly, “automation: no” does not mean the bug can be ignored. It indicates that the assessed scenario was not considered readily automatable under the SSVC decision model. The renderer prerequisite and required user interaction further distinguish this issue from a simple, self-contained compromise triggered merely by loading a page.
The appropriate operational response is to update and verify affected devices while avoiding claims unsupported by the record. There is no basis in the supplied material for declaring an active mass-exploitation event, but there is also no benefit in leaving an affected Chrome version installed after the fixed release is available.
Reports of suspicious dialogs or misleading browser interfaces should be investigated on their own evidence. A visual anomaly is not sufficient to attribute activity to CVE-2026-13939, especially because the exact spoofed UI and exploit method have not been publicly documented.
If an investigation considers this CVE, responders should establish the installed Chrome version, record the relevant page and interaction, preserve available device evidence, and remember that the CVE description requires a preceding renderer compromise. The visible spoofing stage would not, by itself, explain how that prerequisite was achieved.
That platform information outweighs the title of an individual reference attached to the record. One cited Google Chrome Releases entry is identified as a Stable Channel Update for Desktop, but the public record does not state that Chrome on Windows is vulnerable to CVE-2026-13939.
The reference could relate to a broader release, shared Chromium changes, or publication context, but the available material does not establish the reason. The restricted Chromium issue may contain more detail, yet that detail is not available in the public record supplied for this article.
The defensible conclusion is therefore straightforward:
Vulnerability scanners and internal reports should preserve the operating-system condition. A ticket that lists only “Google Chrome” may produce false positives on Windows while failing to communicate the actual Android remediation task.
Administrators should also avoid the opposite error of dismissing the finding as irrelevant because Windows Chrome is not affected. The relevant inventory is the organization’s Android browser estate, including managed Android devices and any other Android devices permitted to access sensitive services.
CWE-20 identifies the broad weakness category as Improper Input Validation. It does not establish whether the underlying issue involved rejection, normalization, representation, length checking, type handling, or another specific validation failure.
The public description supports three central technical points:
The permission-restricted Chromium issue also limits detection guidance. Without a public reproducer or detailed indicator set, defenders cannot reliably identify exploitation from the CVE description alone. Version verification is therefore the clearest available control.
User awareness remains useful, but generic instructions to watch for suspicious prompts should not replace updating. UI spoofing is specifically intended to make an untrusted presentation appear more credible, and the public record does not reveal a dependable visual signature that users could be trained to recognize.
Those conditions support prompt, routine remediation rather than an unsupported emergency declaration. Android users should install the update as soon as it is available and confirm the resulting version. Administrators should establish whether any managed or permitted Android devices remain below the boundary.
Priority can be based on exposure and organizational role without implying that the CVE is known to target a particular group. Devices used for privileged administration, identity approval, sensitive communications, or access to high-value services merit early verification because compromise of those devices would carry greater operational consequences.
If an organization cannot centrally verify every device, it can communicate the exact manual procedure and request evidence of the installed version. Any enforcement or compliance method should be based on the organization’s documented management capabilities rather than assumed features.
The central measure of completion is simple: Chrome on affected Android devices reports version 150.0.7871.47 or later.
These fields may be updated as additional information becomes available. A later NVD score, a public Chromium issue, or a revised exploitation assessment could add context, but none is needed to make the immediate remediation decision for Android versions below the fixed boundary.
CVE-2026-13939 is narrow but actionable. It does not describe a stand-alone compromise and is not currently scoped to Windows, yet affected Chrome for Android installations have a clear fixed version. Update, verify, preserve the Android-only scope, and revisit the assessment if authoritative records later add exploitation evidence or broader platform impact.
The medium-severity WebShare input-validation flaw could allow a remote attacker who has already compromised Chrome’s renderer process to use a crafted HTML page for UI spoofing. It is not described as a stand-alone browser takeover, and CISA’s assessment records no known exploitation, but the renderer prerequisite does not eliminate the need to patch affected Android devices.
What changed / Who needs to act
CVE-2026-13939 concerns insufficient validation of untrusted input in WebShare in Chrome for Android. According to the public description, an attacker who had already compromised the renderer process could use a crafted HTML page to spoof UI. The assigned weakness category is CWE-20, Improper Input Validation.The fixed boundary is explicit: Chrome for Android versions before 150.0.7871.47 are affected. Version 150.0.7871.47 meets the minimum boundary identified in NIST’s analysis, and later versions fall outside the stated affected range.
Individual Android users should update Chrome through Google Play and verify the installed version inside Chrome. Administrators should inventory Chrome versions on Android devices that access organizational resources and confirm that affected installations have reached the fixed boundary.
For Windows administrators, the key scope distinction is equally important. The NVD configuration identifies Chrome together with Android, and the vulnerability description repeatedly specifies Chrome on Android. Chrome on Windows is not listed as affected, even though the record includes a reference whose title concerns a desktop Stable Channel update.
That desktop reference does not, by itself, expand the affected platform. Unless Google or another authoritative record supplies new information, administrators should not classify Windows endpoints as vulnerable to CVE-2026-13939 solely because that reference appears in the record.
Affected: Chrome for Android below 150.0.7871.47
The public record describes UI spoofing through a crafted HTML page, but it also imposes a significant prerequisite: the attacker must already have compromised the renderer process.That wording limits what can responsibly be claimed. Visiting a crafted page is not described as sufficient, by itself, to compromise Chrome. CVE-2026-13939 instead supplies a potential follow-on capability after an attacker has gained control in the renderer through some separate vulnerability or condition.
The documented result is manipulation of what the user sees or understands, rather than direct disclosure of data, loss of availability, or system-level code execution. The public material does not state that this CVE independently steals files, installs software, escapes the browser sandbox, compromises Android, or takes control of the device.
The restricted Chromium issue does not expose the reproducer, patch details, or exact interface element involved. It would therefore be speculative to describe a particular fake share dialog, permission request, account prompt, destination list, credential screen, or other visual result. The supported conclusion is narrower: insufficient WebShare input validation could enable UI spoofing after renderer compromise.
| Deployment or version state | Platform | CVE-2026-13939 status | Practical interpretation |
|---|---|---|---|
| Chrome earlier than 150.0.7871.47 | Android | Affected | Update Chrome and verify the installed version |
| Chrome 150.0.7871.47 | Android | At the fixed boundary | Meets the minimum version identified by NIST |
| Chrome later than 150.0.7871.47 | Android | Outside the stated affected range | Continue normal update enforcement |
| Chrome on Windows | Windows | Not listed as affected | Do not extend the Android scope without new authoritative evidence |
The same distinction should be preserved in security alerts and vulnerability-management tickets. “Google Chrome” is not a sufficiently precise product label for this case. The finding should identify Google Chrome on Android earlier than 150.0.7871.47 so that Windows systems are not incorrectly included and Android devices are not overlooked.
Renderer compromise and UI spoofing
CVE-2026-13939 is not documented as the initial method by which an attacker compromises Chrome’s renderer. The attacker must arrive with that capability already established.This makes the flaw potentially useful as part of a larger chain, but the public record does not identify the preceding vulnerability or describe a complete chain. It also does not establish that a working chain has been used against real targets.
CISA-ADP’s CVSS 3.1 calculation produces a base score of 3.1, categorized as Low. The complete vector is
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N.In practical terms, the vector describes network-delivered content, high attack complexity, no required attacker privileges, required user interaction, unchanged scope, no documented confidentiality or availability impact, and low integrity impact.
The high attack-complexity metric is consistent with the documented need for a prior renderer compromise, but that relationship is an inference from the public vector and vulnerability description. The available material does not explicitly state that CISA selected the high-complexity value solely or specifically because of the renderer prerequisite.
Required user interaction also fits the stated UI-spoofing impact. A spoofed presentation is generally useful only if the user sees it and responds in a way that advances the attacker’s objective. The public record does not provide enough detail to specify what that interaction would look like in this case.
Chrome rates the vulnerability Medium, while the CISA-ADP CVSS calculation is 3.1 Low. These labels come from different sources and scoring approaches. Chrome supplied the vendor severity rating; CISA-ADP supplied the published CVSS 3.1 vector. NVD had not supplied its own CVSS 3.x, CVSS 4.0, or CVSS 2.0 assessment in the described record.
Administrators should therefore avoid saying that “NVD scored the vulnerability 3.1.” More precisely, NVD displays a 3.1 score contributed by CISA-ADP.
The low base score does not change the fixed-version decision. Affected Android installations have a documented update boundary, and updating removes the known condition. At the same time, the score and prerequisites do not support treating this CVE alone as evidence of a widespread or independently successful browser compromise.
Exploitation assessment
CISA-ADP’s SSVC assessment records exploitation as none, automation as no, and technical impact as partial. Those fields describe a conditional issue rather than a publicly known, automated campaign.“Exploitation: none” should be interpreted as an assessment of the evidence available when the record was produced. It is not proof that exploitation is impossible, that private research does not exist, or that the issue could never be combined with another vulnerability.
Similarly, “automation: no” does not mean the bug can be ignored. It indicates that the assessed scenario was not considered readily automatable under the SSVC decision model. The renderer prerequisite and required user interaction further distinguish this issue from a simple, self-contained compromise triggered merely by loading a page.
The appropriate operational response is to update and verify affected devices while avoiding claims unsupported by the record. There is no basis in the supplied material for declaring an active mass-exploitation event, but there is also no benefit in leaving an affected Chrome version installed after the fixed release is available.
Reports of suspicious dialogs or misleading browser interfaces should be investigated on their own evidence. A visual anomaly is not sufficient to attribute activity to CVE-2026-13939, especially because the exact spoofed UI and exploit method have not been publicly documented.
If an investigation considers this CVE, responders should establish the installed Chrome version, record the relevant page and interaction, preserve available device evidence, and remember that the CVE description requires a preceding renderer compromise. The visible spoofing stage would not, by itself, explain how that prerequisite was achieved.
Windows Chrome is not listed as affected
The current NVD affected-product configuration combines the Chrome application with the Android operating system. The description also identifies the vulnerable product as Google Chrome on Android.That platform information outweighs the title of an individual reference attached to the record. One cited Google Chrome Releases entry is identified as a Stable Channel Update for Desktop, but the public record does not state that Chrome on Windows is vulnerable to CVE-2026-13939.
The reference could relate to a broader release, shared Chromium changes, or publication context, but the available material does not establish the reason. The restricted Chromium issue may contain more detail, yet that detail is not available in the public record supplied for this article.
The defensible conclusion is therefore straightforward:
- Chrome for Android below 150.0.7871.47 is affected.
- Chrome for Android 150.0.7871.47 or later meets the stated fixed boundary.
- Chrome on Windows is not listed as affected.
- A desktop release-notes reference is not sufficient evidence to add Windows to the affected scope.
Vulnerability scanners and internal reports should preserve the operating-system condition. A ticket that lists only “Google Chrome” may produce false positives on Windows while failing to communicate the actual Android remediation task.
Administrators should also avoid the opposite error of dismissing the finding as irrelevant because Windows Chrome is not affected. The relevant inventory is the organization’s Android browser estate, including managed Android devices and any other Android devices permitted to access sensitive services.
WebShare and the public technical record
WebShare allows web content to initiate a sharing operation through capabilities provided by the browser and device. Beyond that general context, the supplied record does not document the exact invalid input, the affected code path, the patch mechanics, or the precise UI result.CWE-20 identifies the broad weakness category as Improper Input Validation. It does not establish whether the underlying issue involved rejection, normalization, representation, length checking, type handling, or another specific validation failure.
The public description supports three central technical points:
- The vulnerable component is WebShare in Chrome for Android.
- The attacker must already have compromised the renderer process.
- A crafted HTML page could then be used for UI spoofing.
The permission-restricted Chromium issue also limits detection guidance. Without a public reproducer or detailed indicator set, defenders cannot reliably identify exploitation from the CVE description alone. Version verification is therefore the clearest available control.
User awareness remains useful, but generic instructions to watch for suspicious prompts should not replace updating. UI spoofing is specifically intended to make an untrusted presentation appear more credible, and the public record does not reveal a dependable visual signature that users could be trained to recognize.
Severity and remediation priority
The difference between Chrome’s Medium severity and CISA-ADP’s 3.1 Low score should not dominate the remediation decision. Both descriptions point to a constrained scenario: a prior renderer compromise, required user interaction, limited documented impact, and no known exploitation in the supplied assessment.Those conditions support prompt, routine remediation rather than an unsupported emergency declaration. Android users should install the update as soon as it is available and confirm the resulting version. Administrators should establish whether any managed or permitted Android devices remain below the boundary.
Priority can be based on exposure and organizational role without implying that the CVE is known to target a particular group. Devices used for privileged administration, identity approval, sensitive communications, or access to high-value services merit early verification because compromise of those devices would carry greater operational consequences.
If an organization cannot centrally verify every device, it can communicate the exact manual procedure and request evidence of the installed version. Any enforcement or compliance method should be based on the organization’s documented management capabilities rather than assumed features.
The central measure of completion is simple: Chrome on affected Android devices reports version 150.0.7871.47 or later.
Disclosure timeline
The record was assembled through contributions from Chrome, CISA-ADP, and NIST. The supplied change history documents a sequence of initial publication followed by scoring, decision-support, configuration, and reference enrichment.- Chrome submission: Chrome supplied the CVE description, the CWE-20 classification, affected-product information, references, and the version boundary below 150.0.7871.47.
- NVD publication: NVD published the CVE record with Chrome identified as the source.
- CISA-ADP enrichment: CISA-ADP added the CVSS 3.1 vector and SSVC decision-support information.
- NIST initial analysis: NIST added the Chrome-and-Android CPE configuration, the exclusive 150.0.7871.47 boundary, and classifications for the listed references.
- Current state: The record presents Chrome’s Medium vendor rating, CISA-ADP’s 3.1 Low CVSS calculation, and NIST’s Android-specific affected-product analysis.
These fields may be updated as additional information becomes available. A later NVD score, a public Chromium issue, or a revised exploitation assessment could add context, but none is needed to make the immediate remediation decision for Android versions below the fixed boundary.
Admin actions
- Inventory Chrome versions on managed Android devices.
- Identify installations earlier than 150.0.7871.47.
- Update affected installations to Chrome 150.0.7871.47 or later.
- Verify the installed version after the update rather than relying only on update availability.
- Provide users with the exact Google Play and Chrome version-check steps when central verification is unavailable.
- Prioritize verification for Android devices used for privileged access, identity approval, administration, sensitive communications, or access to high-value services.
- Keep vulnerability tickets scoped to Chrome on Android.
- Do not classify Chrome on Windows as affected solely because the NVD record includes a desktop release-notes reference.
- Do not describe CVE-2026-13939 as an independent renderer compromise, sandbox escape, code-execution flaw, or device takeover.
- Treat suspicious UI reports as investigative leads, not proof of exploitation.
- If investigating a suspected event, preserve available device and browser evidence and look for the separate renderer-compromise prerequisite.
- Recheck the Chrome, CISA-ADP, and NVD records if exploitation status, scoring, affected-product data, or public technical disclosure changes.
CVE-2026-13939 is narrow but actionable. It does not describe a stand-alone compromise and is not currently scoped to Windows, yet affected Chrome for Android installations have a clear fixed version. Update, verify, preserve the Android-only scope, and revisit the assessment if authoritative records later add exploitation evidence or broader platform impact.