Google Chrome on Android versions before 150.0.7871.47 are affected by CVE-2026-13997, an incorrect-security-UI vulnerability in the browser’s Extensions component. According to the National Vulnerability Database record, a remote attacker can use crafted HTML and specific user gestures to produce UI spoofing. The record identifies 150.0.7871.47 as the first version outside the affected range.
CVE-2026-13997 is classified as an incorrect-security-UI vulnerability in Chrome’s Extensions component. The public description says that a remote attacker can use crafted HTML and specific UI gestures to perform UI spoofing on affected Chrome-for-Android installations.
That makes accurate presentation central to the vulnerability. Browser security depends not only on permissions, process boundaries, cryptography, and isolation, but also on the browser’s ability to keep security-relevant interface elements distinguishable from attacker-controlled content. If that distinction becomes unreliable, a user may make a decision based on misleading visual information.
The record maps the vulnerability to CWE-451, “User Interface (UI) Misrepresentation of Critical Information,” with the classification attributed to CISA-ADP. The public description documents UI spoofing and does not provide technical detail beyond that outcome. It does not identify the exact interface element, visual state, prompt, warning, or browser control involved.
That limitation should shape reporting. It is appropriate to say that crafted HTML and required gestures can produce incorrect security UI. It is not appropriate to assign the flaw a more specific visual effect or follow-on capability without additional evidence.
The NVD description instead identifies crafted HTML as the attacker-controlled input. It describes a remote attacker and does not list prior privileges as a requirement. The user must perform specific UI gestures, but the public description does not say that a hostile extension must already be installed.
Extension allowlisting or removing optional extensions should therefore not be treated as a substitute for updating Chrome. Those controls may remain useful for broader browser governance, but they do not move an affected Chrome installation outside the version range identified for this CVE.
The Extensions label also does not tell defenders exactly what exploitation looks like. The public information does not identify a named installation workflow, permission dialog, indicator, or security prompt. The associated Chromium issue is restricted, so the available material does not provide a public reproduction procedure, screenshots, source-level explanation, or exact gesture sequence.
The defensible conclusion is narrow: on affected versions of Google Chrome for Android, crafted HTML combined with specific user gestures can cause incorrect security UI and enable UI spoofing in the Extensions component.
CISA-ADP’s CVSS 3.1 contribution reflects that limitation. It assigns a base score of 4.2 and the vector
This is a CISA-ADP score presented through the NVD record, not an independent NIST CVSS assessment. The Medium score summarizes the recorded exploit conditions and direct technical impact. It should not be inflated into a claim of automatic compromise, but it also should not be used as a reason to leave an affected browser unpatched.
A plausible deployment method would involve a page persuading a visitor to continue interacting until the required gestures occur. That is a general threat-model observation, not evidence of a known campaign. The supplied record does not identify active attacks, a particular lure, a targeted population, or a confirmed secondary compromise.
Because the exact gesture sequence is not public, user training cannot reliably teach people to recognize and avoid that sequence. Updating Chrome and verifying the resulting version provides a more dependable response.
The wording around 150.0.7871.47 matters. The NVD record identifies it as the first version outside the affected range. That supports using 150.0.7871.47 or later as the minimum verification target for CVE-2026-13997.
It does not, by itself, establish when every device or application channel will offer the corrected build. It also does not supply manual menu instructions for installing or viewing the update. Administrators and users should follow the supported procedures for their device or management platform, then compare the installed version with the NVD threshold.
The platform boundary should remain equally precise. This record concerns Google Chrome on Android. It should not be converted into a general claim about Android itself, desktop Chrome, Microsoft Edge, or every browser containing Chromium code.
Other browser vendors may use different product versions, incorporate changes on different schedules, or backport fixes without matching Google Chrome’s public version number. The Chrome threshold should not be applied directly to another browser unless its vendor confirms the relationship.
A management console may show that Chrome is approved, required, assigned, or targeted for an update. Those records can demonstrate administrative intent, but they do not establish which version is currently installed on an endpoint.
For CVE-2026-13997, the compliance test is simple:
Organizations may use features available in their own endpoint-management products, but those features should be described as local administrative controls—not as remediation instructions supplied by the CVE record.
A page visit alone would not establish exploitation. General touch interaction would not identify the undisclosed sequence. Likewise, ordinary browser or network logs may not reveal whether incorrect security UI appeared on the screen or influenced a user’s decision.
Version verification is consequently more useful than speculative hunting. An organization can directly determine whether a reported Chrome installation falls before or after 150.0.7871.47. It cannot derive an equally reliable behavioral signature from the limited public description.
Security teams can still review reports involving suspicious pages, deceptive browser presentation, or unexpected user actions. Those events may deserve investigation under normal incident-response procedures. They should not, however, be attributed specifically to CVE-2026-13997 unless supporting evidence becomes available.
The absence of a public exploit recipe should not delay remediation. The affected range is sufficiently clear to support a focused inventory and update effort without speculation about the undisclosed interface behavior.
“Exploitation: none” supports saying that the assessment did not record active exploitation at the stated time. It does not prove that exploitation is impossible or that later evidence cannot change the status.
“Automatable: no” is consistent with the requirement for specific user gestures. It should not be expanded into claims about how widely a malicious page could be distributed, how reliable exploitation might be, or which surrounding campaign activities could be automated.
“Technical impact: partial” should also remain a categorization value. The public technical description documents UI spoofing but does not provide enough detail to define every possible user decision or subsequent action that might follow from misleading presentation.
The practical posture is proportionate: update affected installations, verify the result, and avoid presenting the vulnerability as either a confirmed active campaign or an insignificant cosmetic defect.
These dates describe the timestamps present in the supplied record. They should not be used to infer unsupported details about the precise internal sequence by which each organization reviewed or edited every field.
The supplied record does not establish exact consumer navigation paths, explain update-delivery timing, or document troubleshooting steps for a failed installation. It therefore does not support attributing failures to storage, account condition, enrollment state, connectivity, application use, update queues, or any other particular cause.
Users encountering update problems should follow current support guidance supplied by the device manufacturer, application distributor, or Google rather than treating speculative causes as facts about this CVE.
For CVE-2026-13997, that difference produces a clear closing test: Google Chrome on Android below 150.0.7871.47 remains inside the published affected range, while 150.0.7871.47 or later crosses the NVD threshold. Update, measure the installed state, and keep unknown devices visible until their status can be verified.
Enterprise administrators should follow the same technical test: identify managed Android devices running Google Chrome and verify the version actually installed on each device. An assigned update policy, an approved application, or a completed management command is not proof of remediation. For this CVE, the meaningful evidence is an installed Chrome version of 150.0.7871.47 or later.
The Browser’s Security Boundary Includes What the User Sees
CVE-2026-13997 is classified as an incorrect-security-UI vulnerability in Chrome’s Extensions component. The public description says that a remote attacker can use crafted HTML and specific UI gestures to perform UI spoofing on affected Chrome-for-Android installations.That makes accurate presentation central to the vulnerability. Browser security depends not only on permissions, process boundaries, cryptography, and isolation, but also on the browser’s ability to keep security-relevant interface elements distinguishable from attacker-controlled content. If that distinction becomes unreliable, a user may make a decision based on misleading visual information.
The record maps the vulnerability to CWE-451, “User Interface (UI) Misrepresentation of Critical Information,” with the classification attributed to CISA-ADP. The public description documents UI spoofing and does not provide technical detail beyond that outcome. It does not identify the exact interface element, visual state, prompt, warning, or browser control involved.
That limitation should shape reporting. It is appropriate to say that crafted HTML and required gestures can produce incorrect security UI. It is not appropriate to assign the flaw a more specific visual effect or follow-on capability without additional evidence.
“Extensions” Does Not Mean a Malicious Extension Must Already Be Installed
The component name can be misleading. “Incorrect security UI in Extensions” may sound like a vulnerability that begins with a malicious extension, a compromised extension listing, or an extension that already has browser permissions.The NVD description instead identifies crafted HTML as the attacker-controlled input. It describes a remote attacker and does not list prior privileges as a requirement. The user must perform specific UI gestures, but the public description does not say that a hostile extension must already be installed.
Extension allowlisting or removing optional extensions should therefore not be treated as a substitute for updating Chrome. Those controls may remain useful for broader browser governance, but they do not move an affected Chrome installation outside the version range identified for this CVE.
The Extensions label also does not tell defenders exactly what exploitation looks like. The public information does not identify a named installation workflow, permission dialog, indicator, or security prompt. The associated Chromium issue is restricted, so the available material does not provide a public reproduction procedure, screenshots, source-level explanation, or exact gesture sequence.
The defensible conclusion is narrow: on affected versions of Google Chrome for Android, crafted HTML combined with specific user gestures can cause incorrect security UI and enable UI spoofing in the Extensions component.
User Interaction Is a Required Attack Condition
The requirement for specific UI gestures is an important constraint. The vulnerability is not described as activating merely because Chrome receives a request or loads a page. The user must perform particular interactions under conditions arranged by attacker-controlled HTML.CISA-ADP’s CVSS 3.1 contribution reflects that limitation. It assigns a base score of 4.2 and the vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L.| CVSS metric | Recorded value | Practical interpretation |
|---|---|---|
| Attack vector | Network | Attacker-controlled content can be delivered remotely |
| Attack complexity | High | Exploitation depends on special conditions |
| Privileges required | None | The attacker does not need prior authorization |
| User interaction | Required | A victim must perform the necessary gestures |
| Scope | Unchanged | The scored impact remains within the same security authority |
| Confidentiality | None | The vector assigns no direct confidentiality impact |
| Integrity | Low | The vector assigns limited integrity impact |
| Availability | Low | The vector assigns limited availability impact |
A plausible deployment method would involve a page persuading a visitor to continue interacting until the required gestures occur. That is a general threat-model observation, not evidence of a known campaign. The supplied record does not identify active attacks, a particular lure, a targeted population, or a confirmed secondary compromise.
Because the exact gesture sequence is not public, user training cannot reliably teach people to recognize and avoid that sequence. Updating Chrome and verifying the resulting version provides a more dependable response.
The Version Boundary Is the Strongest Operational Fact
The NVD configuration associates the affected product with Google Chrome on Google Android and identifies versions before 150.0.7871.47 as vulnerable. That creates a clear product, platform, and version test.| Product and version state | Status in the supplied record | Operational interpretation |
|---|---|---|
| Google Chrome on Android before 150.0.7871.47 | Affected | Update and verify the installed version |
| Google Chrome on Android at 150.0.7871.47 or later | Outside the listed affected range | Meets the NVD verification threshold for this CVE |
| Chrome on other operating systems | Not established by this configuration | Do not extend the Android finding without separate evidence |
| Other Chromium-derived Android browsers | Not determined by Chrome’s version range | Obtain product-specific information from the browser vendor |
It does not, by itself, establish when every device or application channel will offer the corrected build. It also does not supply manual menu instructions for installing or viewing the update. Administrators and users should follow the supported procedures for their device or management platform, then compare the installed version with the NVD threshold.
The platform boundary should remain equally precise. This record concerns Google Chrome on Android. It should not be converted into a general claim about Android itself, desktop Chrome, Microsoft Edge, or every browser containing Chromium code.
Other browser vendors may use different product versions, incorporate changes on different schedules, or backport fixes without matching Google Chrome’s public version number. The Chrome threshold should not be applied directly to another browser unless its vendor confirms the relationship.
Assigned Policy Is Not the Same as Verified Remediation
The most important enterprise distinction is between intended state and observed state.A management console may show that Chrome is approved, required, assigned, or targeted for an update. Those records can demonstrate administrative intent, but they do not establish which version is currently installed on an endpoint.
For CVE-2026-13997, the compliance test is simple:
- Verified remediated: Chrome on Android reports version 150.0.7871.47 or later.
- Still affected: Chrome on Android reports a version earlier than 150.0.7871.47.
- Unknown: The organization cannot obtain a sufficiently recent installed-version report.
Concise enterprise procedure
- Identify the applicable population.
Locate managed Android devices on which Google Chrome is installed. - Collect the installed version.
Use the organization’s supported inventory or endpoint-management process to obtain the version currently reported by each device. - Apply the version test.
Flag Chrome installations earlier than 150.0.7871.47 as affected by the NVD range. - Initiate the update.
Use the organization’s established application-distribution process to deploy a current Chrome release. - Collect inventory again.
Recheck the installed version after the deployment period rather than relying on the update assignment or command status. - Separate verified, affected, and unknown devices.
Keep devices with stale or missing inventory in an unresolved category until their installed version can be confirmed. - Retain evidence.
Record the device identifier, reported Chrome version, inventory time, and remediation result according to normal organizational procedures.
Organizations may use features available in their own endpoint-management products, but those features should be described as local administrative controls—not as remediation instructions supplied by the CVE record.
Action checklist for administrators
- Inventory Google Chrome installations on managed Android devices.
- Record the full installed Chrome version.
- Flag versions earlier than 150.0.7871.47.
- Update affected installations through the organization’s supported distribution process.
- Verify the installed version after deployment.
- Do not equate policy assignment with successful installation.
- Treat missing or stale version reports as unresolved rather than compliant.
- Keep the finding limited to Google Chrome on Android unless separate evidence establishes broader applicability.
- Do not use extension allowlisting as a replacement for updating Chrome.
- Request product-specific fixed-version information for other Chromium-derived browsers.
- Monitor the public vulnerability record for later technical details or changes in exploitation assessment.
The Public Record Supports Version Auditing More Than Exploit Hunting
The restricted Chromium issue leaves defenders without a public reproduction procedure, detailed visual description, or exact gesture sequence. That makes highly specific detection logic difficult to justify.A page visit alone would not establish exploitation. General touch interaction would not identify the undisclosed sequence. Likewise, ordinary browser or network logs may not reveal whether incorrect security UI appeared on the screen or influenced a user’s decision.
Version verification is consequently more useful than speculative hunting. An organization can directly determine whether a reported Chrome installation falls before or after 150.0.7871.47. It cannot derive an equally reliable behavioral signature from the limited public description.
Security teams can still review reports involving suspicious pages, deceptive browser presentation, or unexpected user actions. Those events may deserve investigation under normal incident-response procedures. They should not, however, be attributed specifically to CVE-2026-13997 unless supporting evidence becomes available.
The absence of a public exploit recipe should not delay remediation. The affected range is sufficiently clear to support a focused inventory and update effort without speculation about the undisclosed interface behavior.
Exploitation Status Requires Narrow Wording
The CISA-ADP Stakeholder-Specific Vulnerability Categorization contribution lists:- Exploitation: none
- Automatable: no
- Technical impact: partial
- SSVC version: 2.0.3
- Role: CISA Coordinator
“Exploitation: none” supports saying that the assessment did not record active exploitation at the stated time. It does not prove that exploitation is impossible or that later evidence cannot change the status.
“Automatable: no” is consistent with the requirement for specific user gestures. It should not be expanded into claims about how widely a malicious page could be distributed, how reliable exploitation might be, or which surrounding campaign activities could be automated.
“Technical impact: partial” should also remain a categorization value. The public technical description documents UI spoofing but does not provide enough detail to define every possible user decision or subsequent action that might follow from misleading presentation.
The practical posture is proportionate: update affected installations, verify the result, and avoid presenting the vulnerability as either a confirmed active campaign or an insignificant cosmetic defect.
Dated Record Timeline
| Date | Recorded milestone |
|---|---|
| June 30, 2026 | NVD lists CVE-2026-13997 as published. The public record describes incorrect security UI in Chrome’s Extensions component, crafted HTML, required user gestures, UI spoofing, and affected Chrome-on-Android versions before 150.0.7871.47. |
| July 1, 2026 | NVD lists the record as last modified. |
| July 1, 2026 | The CISA-ADP SSVC contribution carries this timestamp and records exploitation as none, automatable as no, and technical impact as partial. |
A Focused Consumer Response
For individual users, the useful procedure is intentionally short:- Update Google Chrome using the official application-distribution mechanism available on the Android device.
- Determine the installed Chrome version using a supported device, application, or browser information view.
- Confirm that the version is 150.0.7871.47 or later.
The supplied record does not establish exact consumer navigation paths, explain update-delivery timing, or document troubleshooting steps for a failed installation. It therefore does not support attributing failures to storage, account condition, enrollment state, connectivity, application use, update queues, or any other particular cause.
Users encountering update problems should follow current support guidance supplied by the device manufacturer, application distributor, or Google rather than treating speculative causes as facts about this CVE.
The Most Important Facts Are the Measurable Ones
- CVE-2026-13997 affects Google Chrome on Android versions before 150.0.7871.47.
- The NVD record identifies 150.0.7871.47 as the first version outside the affected range.
- The vulnerability involves incorrect security UI in Chrome’s Extensions component.
- The documented input is crafted HTML, and exploitation requires specific UI gestures.
- The documented result is UI spoofing.
- The public description does not provide technical detail beyond that outcome or identify the exact affected interface behavior.
- The Extensions component label does not establish that a malicious extension must already be installed.
- CISA-ADP assigns a CVSS 3.1 base score of 4.2, with network access, high attack complexity, no required privileges, and required user interaction.
- CISA-ADP’s SSVC contribution records exploitation as none, automatable as no, and technical impact as partial as of July 1, 2026.
- The record concerns Chrome on Android and should not be generalized automatically to desktop Chrome, Android itself, or other Chromium-based browsers.
- The most reliable remediation evidence is the version installed after the update—not the policy, approval, or deployment command intended to deliver it.
For CVE-2026-13997, that difference produces a clear closing test: Google Chrome on Android below 150.0.7871.47 remains inside the published affected range, while 150.0.7871.47 or later crosses the NVD threshold. Update, measure the installed state, and keep unknown devices visible until their status can be verified.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:41:31-07:00
Loading…
nvd.nist.gov - Security advisory: MSRC
Published: 2026-07-11T15:41:31-07:00
Original feed URL
Loading…
msrc.microsoft.com - Related coverage: ubuntu.com
Loading…
ubuntu.com - Related coverage: security.snyk.io
Loading…
security.snyk.io - Related coverage: chromium.googlesource.com
Loading…
chromium.googlesource.com - Related coverage: cvepremium.circl.lu
Loading…
cvepremium.circl.lu