CVE-2026-13943 affects Google Chrome on Android before version 150.0.7871.47. Chrome’s description says a remote attacker can use crafted HTML to obtain potentially sensitive information from browser-process memory. CISA-ADP’s assessment requires user interaction but no attacker privileges and scores the direct impact as high for confidentiality, with no integrity or availability impact. Update affected Android installations and verify that the complete installed Chrome version is 150.0.7871.47 or later.
As a general Android UI path, users can usually find the version under Chrome > three-dot menu > Settings > About Chrome and obtain application updates through Chrome’s listing in the Google Play Store. Menu names and locations can vary by Android release, device manufacturer, and Play Store version. The decisive check is the complete Chrome version shown after the update attempt, not whether an update button was selected.
Chrome categorizes CVE-2026-13943 as an uninitialized-use vulnerability in CSS and maps it to CWE-457, Use of Uninitialized Variable. In general, this weakness occurs when software reads or uses a value before placing that memory in a dependable initial state. Stale or unintended information can then influence behavior or become observable.
The Chrome-originated description presented by the National Vulnerability Database says crafted HTML can obtain potentially sensitive information from process memory in affected Chrome-on-Android versions. That establishes an information-disclosure risk, but the disclosed record does not identify the specific data recoverable through the flaw.
The associated Chromium issue, 513204116, is permission-restricted. Public material therefore does not provide the trigger, proof of concept, affected memory structures, disclosure reliability, or examples of successfully recovered information. “Process memory” defines a technical location; it is not a verified list of exposed credentials, cookies, tokens, files, account records, or other data.
The available record also does not establish arbitrary file access, complete memory dumping, sandbox escape, application installation, Android compromise, data modification, or service disruption. Those limits should prevent exaggerated impact claims without minimizing the documented confidentiality failure.
That vector produces a base score of 6.5, rated Medium. It is a CISA-ADP contribution displayed by NVD, not an NVD-authored CVSS assessment.
The vector describes a network-reachable vulnerability with low attack complexity, no privileges required, required user interaction, unchanged scope, high confidentiality impact, and no scored integrity or availability impact. Based on the
“Low attack complexity” does not prove that exploitation is technically easy to develop. It means the scoring assessment does not depend on unusual conditions outside the attacker’s control. Likewise, “privileges required: none” means the modeled attacker does not need prior authorized access; it does not add capabilities beyond the documented information disclosure.
CISA-ADP’s SSVC contribution records exploitation as none, automatable as no, and technical impact as partial. These are point-in-time assessment fields, not guarantees that exploitation has never happened or will not emerge. The public record does not identify active exploitation, a public proof of concept, a known attacker, a validated exploit chain, or CVE-specific indicators of compromise.
Taken together, the evidence supports a patch promptly and verify response. It does not support treating every affected device as compromised or initiating an emergency device-isolation campaign solely because the vulnerable version is installed.
The complete four-part version matters. A device reporting 150.0.7871.46 remains below the threshold even though it runs milestone 150. A result that reports only “Chrome 150” is insufficient to resolve the finding.
Version 150.0.7871.47 or later is best described as meeting the published threshold or being outside the NVD-stated affected range. That boundary does not prove that an update is immediately available through every Android distribution channel, on every device, or in every region. It also should not be described as proof that every later distribution state contains a particular corrected binary unless Chrome supplies that additional release detail.
The Android condition is equally important. NVD’s desktop Chrome release-note reference does not independently declare Windows, macOS, or Linux affected. Reference links can provide context without expanding the affected-product configuration.
The record also does not establish applicability to Android itself, Microsoft Edge, or every Chromium-derived browser. Shared Chromium ancestry is not enough to prove that another product contains the affected code, exposes the same path, or follows Chrome’s version boundary. Each browser requires its own vendor statement or other product-specific evidence.
Without the issue content, defenders cannot independently determine which CSS operation triggers the flaw, how repeatable the disclosure is, how much information may be returned, or which browser state affects the result. “Uninitialized Use in CSS” identifies a weakness class and subsystem but not a complete exploit mechanism.
This uncertainty cuts in both directions. The absence of a public proof of concept is not a reason to dismiss a browser memory-disclosure vulnerability. It is also not a basis for claiming reliable extraction of passwords, session material, encryption keys, personal records, or arbitrary memory.
The supported remediation decision does not require those missing details. Administrators can act on the named product, Android platform condition, affected-version range, and measurable version threshold without speculating about the restricted report.
Selecting Update, seeing an update offered, or assuming automatic updates are enabled does not demonstrate the resulting installed version. The finding is resolved when current evidence shows that the application meets the published threshold.
Users must check the Chrome application version, not the Android version or Android security-patch date. Those values describe different software components and cannot substitute for the Chrome version named in this CVE.
The CVE record does not document the capabilities, reporting fields, deployment behavior, or enforcement options of any particular inventory or device-management product. Administrators should consult the documentation for the tools they use rather than assume that a platform can collect a specific field, install the update, or prove the resulting application state.
An update assignment and an installed-version observation answer different questions. The first records an attempted administrative action; the second determines whether the device is currently inside or outside the stated affected range.
Missing information should not be silently treated as compliant. An unknown device is not confirmed vulnerable, but it is also not verified as meeting the threshold. Where inventory reports only a major version, administrators need another trustworthy observation of the full version string.
A scanner or vulnerability platform may associate the CVE with desktop Chrome because NVD includes a desktop release-note reference or because a correlation rule matches the generic product name. Neither condition overrides the Android-specific product configuration.
A supportable finding from the supplied record requires:
The distinction prevents two operational errors: wasting desktop-remediation effort on an unsupported match and overlooking the Android installations actually named by the record. Windows-centered organizations that also permit Android access should ensure the issue reaches whichever owner handles mobile browser maintenance, without broadening the technical claim to Windows.
A concise internal ticket can state:
Reports should preserve those distinctions. The 6.5 Medium score should be called the CISA-ADP CVSS 3.1 assessment displayed by NVD, not simply an “NVD score.”
The previously asserted June 30, 2026 publication date is omitted because it is not sufficiently supported by the supplied material for this revision. An exact calendar date is unnecessary to apply the product, platform, and version boundary.
The current evidence supports saying that:
Chrome 150.0.7871.47 or later meets the published threshold and is outside the NVD-stated affected range. Unknown or lower versions remain unresolved. That conclusion should not be generalized to every Chromium browser or used to create Windows Chrome findings without additional evidence.
Future authoritative updates may disclose more about the restricted Chromium issue, revise the affected range, identify additional platforms, change the exploitation assessment, or provide product-specific guidance. Until then, the defensible course is prompt but precise: remediate the Android product named by the record, preserve the full version evidence, avoid unsupported compromise claims, and keep desktop findings out of scope unless new evidence establishes otherwise.
As a general Android UI path, users can usually find the version under Chrome > three-dot menu > Settings > About Chrome and obtain application updates through Chrome’s listing in the Google Play Store. Menu names and locations can vary by Android release, device manufacturer, and Play Store version. The decisive check is the complete Chrome version shown after the update attempt, not whether an update button was selected.
What the Vulnerability Discloses—and What It Does Not
Chrome categorizes CVE-2026-13943 as an uninitialized-use vulnerability in CSS and maps it to CWE-457, Use of Uninitialized Variable. In general, this weakness occurs when software reads or uses a value before placing that memory in a dependable initial state. Stale or unintended information can then influence behavior or become observable.The Chrome-originated description presented by the National Vulnerability Database says crafted HTML can obtain potentially sensitive information from process memory in affected Chrome-on-Android versions. That establishes an information-disclosure risk, but the disclosed record does not identify the specific data recoverable through the flaw.
The associated Chromium issue, 513204116, is permission-restricted. Public material therefore does not provide the trigger, proof of concept, affected memory structures, disclosure reliability, or examples of successfully recovered information. “Process memory” defines a technical location; it is not a verified list of exposed credentials, cookies, tokens, files, account records, or other data.
The available record also does not establish arbitrary file access, complete memory dumping, sandbox escape, application installation, Android compromise, data modification, or service disruption. Those limits should prevent exaggerated impact claims without minimizing the documented confidentiality failure.
Severity Supports Prompt, Proportionate Remediation
CISA-ADP contributed the visible CVSS 3.1 vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:NThat vector produces a base score of 6.5, rated Medium. It is a CISA-ADP contribution displayed by NVD, not an NVD-authored CVSS assessment.
The vector describes a network-reachable vulnerability with low attack complexity, no privileges required, required user interaction, unchanged scope, high confidentiality impact, and no scored integrity or availability impact. Based on the
UI:R value and Chrome’s crafted-HTML description, it is reasonable to infer that a target must encounter the crafted web content. The record does not independently document a campaign-specific delivery workflow, so examples such as malicious links, advertisements, messages, or redirects should not be reported as confirmed methods used for this CVE.“Low attack complexity” does not prove that exploitation is technically easy to develop. It means the scoring assessment does not depend on unusual conditions outside the attacker’s control. Likewise, “privileges required: none” means the modeled attacker does not need prior authorized access; it does not add capabilities beyond the documented information disclosure.
CISA-ADP’s SSVC contribution records exploitation as none, automatable as no, and technical impact as partial. These are point-in-time assessment fields, not guarantees that exploitation has never happened or will not emerge. The public record does not identify active exploitation, a public proof of concept, a known attacker, a validated exploit chain, or CVE-specific indicators of compromise.
Taken together, the evidence supports a patch promptly and verify response. It does not support treating every affected device as compromised or initiating an emergency device-isolation campaign solely because the vulnerable version is installed.
Keep the Platform and Version Boundary Intact
The NVD configuration identifies Google Chrome in an Android context and states that versions before 150.0.7871.47 are affected.| Deployment state | Product and platform | Version | Published status | Operational meaning |
|---|---|---|---|---|
| Exposed | Google Chrome on Android | Earlier than 150.0.7871.47 | Affected | Inside the NVD-stated affected range |
| Threshold met | Google Chrome on Android | 150.0.7871.47 or later | Outside the stated affected range | Meets the published threshold |
| Not established | Google Chrome on Windows, macOS, or Linux | Any version | Not proven affected by this record | Requires separate platform-specific evidence |
Version 150.0.7871.47 or later is best described as meeting the published threshold or being outside the NVD-stated affected range. That boundary does not prove that an update is immediately available through every Android distribution channel, on every device, or in every region. It also should not be described as proof that every later distribution state contains a particular corrected binary unless Chrome supplies that additional release detail.
The Android condition is equally important. NVD’s desktop Chrome release-note reference does not independently declare Windows, macOS, or Linux affected. Reference links can provide context without expanding the affected-product configuration.
The record also does not establish applicability to Android itself, Microsoft Edge, or every Chromium-derived browser. Shared Chromium ancestry is not enough to prove that another product contains the affected code, exposes the same path, or follows Chrome’s version boundary. Each browser requires its own vendor statement or other product-specific evidence.
Why the Restricted Chromium Issue Matters
Chromium issue 513204116 is not publicly readable through the supplied material. Its restricted status establishes that the report cannot currently be reviewed publicly, but it does not establish why access is restricted or when additional details may appear.Without the issue content, defenders cannot independently determine which CSS operation triggers the flaw, how repeatable the disclosure is, how much information may be returned, or which browser state affects the result. “Uninitialized Use in CSS” identifies a weakness class and subsystem but not a complete exploit mechanism.
This uncertainty cuts in both directions. The absence of a public proof of concept is not a reason to dismiss a browser memory-disclosure vulnerability. It is also not a basis for claiming reliable extraction of passwords, session material, encryption keys, personal records, or arbitrary memory.
The supported remediation decision does not require those missing details. Administrators can act on the named product, Android platform condition, affected-version range, and measurable version threshold without speculating about the restricted report.
Android Update and Verification Procedure
The following is a general navigation path rather than a universal interface specification:- Open Chrome on the Android device.
- Open Chrome’s menu and locate Settings.
- Open About Chrome or the equivalent version-information page.
- Record the complete installed version.
- If the version is earlier than 150.0.7871.47, locate Google Chrome in the Google Play Store.
- Install an available Chrome update through the normal application-update interface.
- Return to Chrome’s version-information page.
- Confirm that the displayed version is 150.0.7871.47 or later.
Selecting Update, seeing an update offered, or assuming automatic updates are enabled does not demonstrate the resulting installed version. The finding is resolved when current evidence shows that the application meets the published threshold.
Users must check the Chrome application version, not the Android version or Android security-patch date. Those values describe different software components and cannot substitute for the Chrome version named in this CVE.
Fleet Remediation Is a Version-Evidence Problem
Organizations need a narrow, product-neutral objective: identify relevant Android devices, determine the complete installed Google Chrome version, remediate versions below 150.0.7871.47, and collect fresh version evidence afterward.The CVE record does not document the capabilities, reporting fields, deployment behavior, or enforcement options of any particular inventory or device-management product. Administrators should consult the documentation for the tools they use rather than assume that a platform can collect a specific field, install the update, or prove the resulting application state.
| Fleet state | Meaning | Required action |
|---|---|---|
| Confirmed exposed | Android Chrome is earlier than 150.0.7871.47 | Remediate and recheck |
| Threshold met | Android Chrome is 150.0.7871.47 or later | Record the verified version |
| Update action unverified | An update was requested or attempted, but the resulting version is unknown | Obtain current version evidence |
| Unknown | Version information is missing, incomplete, stale, or conflicting | Keep unresolved and investigate |
| Different browser | The application is not Google Chrome for Android | Check that vendor’s own information |
| Desktop Chrome | Chrome is running on Windows, macOS, or Linux | Do not mark affected from this record alone |
Missing information should not be silently treated as compliant. An unknown device is not confirmed vulnerable, but it is also not verified as meeting the threshold. Where inventory reports only a major version, administrators need another trustworthy observation of the full version string.
Action Checklist for Administrators
- Identify Google Chrome installations on Android devices within the defined management scope.
- Collect the complete four-part installed Chrome version.
- Flag confirmed versions earlier than 150.0.7871.47.
- Treat missing, truncated, stale, or conflicting version information as unresolved.
- Remediate affected installations through the organization’s supported application-update process.
- Collect fresh version evidence after the remediation attempt.
- Close the finding only when current evidence shows version 150.0.7871.47 or later.
- Confirm that the identified application is Google Chrome rather than another Chromium-derived browser.
- Do not substitute the Android operating-system version or security-patch date for the Chrome version.
- Exclude Windows, macOS, Linux, ChromeOS, Edge, and other browser findings created solely through generic product-name or Chromium matching.
- Do not treat an affected version as proof that exploitation or information loss occurred.
- Monitor authoritative records for changes in affected scope, technical detail, version boundaries, or exploitation status.
What Windows-Centric Teams Should Do
For Windows-focused security teams, the most important task is correct routing and scope control.A scanner or vulnerability platform may associate the CVE with desktop Chrome because NVD includes a desktop release-note reference or because a correlation rule matches the generic product name. Neither condition overrides the Android-specific product configuration.
A supportable finding from the supplied record requires:
- Google Chrome as the product.
- Android as the platform context.
- A complete installed version earlier than 150.0.7871.47.
The distinction prevents two operational errors: wasting desktop-remediation effort on an unsupported match and overlooking the Android installations actually named by the record. Windows-centered organizations that also permit Android access should ensure the issue reaches whichever owner handles mobile browser maintenance, without broadening the technical claim to Windows.
A concise internal ticket can state:
Reporting Limits and Provenance
The public record combines material from multiple contributors. Chrome supplied the core vulnerability description, Android product scope, affected range, and CWE-457 classification. CISA-ADP supplied the visible CVSS 3.1 score and SSVC values. NVD presents the record and affected-product configuration but does not provide its own visible CVSS assessment in the supplied material.Reports should preserve those distinctions. The 6.5 Medium score should be called the CISA-ADP CVSS 3.1 assessment displayed by NVD, not simply an “NVD score.”
The previously asserted June 30, 2026 publication date is omitted because it is not sufficiently supported by the supplied material for this revision. An exact calendar date is unnecessary to apply the product, platform, and version boundary.
The current evidence supports saying that:
- Crafted HTML is the documented malicious input.
- CISA-ADP’s vector requires user interaction and no attacker privileges.
- The modeled direct effect is high confidentiality impact.
- Integrity and availability impact are scored as none.
- CISA-ADP’s SSVC contribution records exploitation as none.
- The restricted Chromium issue leaves the trigger and demonstrated exposed data unspecified.
- No active campaign, public proof of concept, validated indicator, or complete exploit chain is identified in the supplied record.
Verify the Version and Watch for Changes
CVE-2026-13943 has a specific, measurable response. Find Google Chrome installations on Android that are earlier than 150.0.7871.47, apply an available update through the supported application-update process, and verify the complete installed version afterward.Chrome 150.0.7871.47 or later meets the published threshold and is outside the NVD-stated affected range. Unknown or lower versions remain unresolved. That conclusion should not be generalized to every Chromium browser or used to create Windows Chrome findings without additional evidence.
Future authoritative updates may disclose more about the restricted Chromium issue, revise the affected range, identify additional platforms, change the exploitation assessment, or provide product-specific guidance. Until then, the defensible course is prompt but precise: remediate the Android product named by the record, preserve the full version evidence, avoid unsupported compromise claims, and keep desktop findings out of scope unless new evidence establishes otherwise.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:41:21-07:00
NVD - CVE-2026-13943
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:41:21-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: security.snyk.io
Use of Uninitialized Variable in chromium | CVE-2026-13943 | Snyk
Use of Uninitialized Variable in chromium | CVE-2026-13943security.snyk.io - Related coverage: chromium.org