Chrome on Android versions below 150.0.7871.47 are affected by CVE-2026-13923. Update Chrome to version 150.0.7871.47 or later and verify the installed app version.
The documented exposure is a crafted-HTML-triggered potential disclosure of sensitive information from browser process memory, not a documented device takeover. The public record does not establish remote code execution, sandbox escape, privilege escalation, persistent compromise, or active exploitation.
Chrome classifies CVE-2026-13923 as Medium, and the CISA Authorized Data Publisher, or CISA-ADP, supplied a CVSS 3.1 base score of 6.5. The associated vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N.
In practical terms, the vector describes a network-delivered attack with low attack complexity and no requirement for prior attacker privileges. User interaction is required, the security scope is unchanged, and the recorded impact is High for confidentiality but None for integrity and availability.
The vulnerability description says a remote attacker can use a crafted HTML page to obtain potentially sensitive information from Chrome process memory. The public material does not specify what information might be exposed, how much memory might be disclosed, how repeatable the result is, or whether the returned data would be consistently useful to an attacker.
Those limits matter. It would be unsupported to claim that the flaw reliably exposes passwords, authentication tokens, personal information, browsing history, or data from a particular website. It would also be inappropriate to dismiss the issue as an inconsequential display problem: the documented security consequence is potential disclosure of sensitive process memory, and the supplied CVSS vector records a High confidentiality impact.
The defensible characterization is therefore narrow but meaningful. CVE-2026-13923 is an information-disclosure vulnerability affecting Chrome on Android before the stated version boundary. The available evidence does not show that the flaw can independently alter data, install software, gain Android privileges, or take control of the device.
The vulnerability is identified as a GPU-related issue, but that label should not be expanded beyond the available evidence. The public record does not establish whether the relevant memory is owned by a particular Chrome process, resides in a graphics buffer, comes from an earlier browser operation, or crosses any specific internal boundary.
It also does not establish that the underlying defect is in physical GPU hardware, the Android kernel, a device manufacturer’s driver, or a particular graphics implementation. The affected-product information identifies Google Chrome on Android, and the verified impact statement concerns potential disclosure from browser process memory.
Browsers use graphics-related components to process and display web content, so a crafted page can reach complex browser functionality without requiring the attacker to distribute a native Android application. That general observation helps explain why a GPU-related defect can be web-triggered, but it is not a substitute for the restricted technical analysis of this particular CVE.
No verified public source change has been supplied that demonstrates a texture-copy, luma-emulation, rasterizer-discard, or skipped-copy explanation for CVE-2026-13923. Those details should not be presented as part of the vulnerability’s mechanism unless Google or another authoritative source explicitly connects them to this CVE.
That does not mean every device with an affected Chrome version has already disclosed information. The browser must process the malicious content under the conditions needed to trigger the flaw. At the same time, the user-interaction requirement does not eliminate the need to update, because following links and loading web content are ordinary browser activities.
The vector records no integrity impact and no availability impact. On the supplied evidence, CVE-2026-13923 is not documented as changing browser or operating-system data, installing an application, corrupting files, or making the device unavailable. The stated consequence is potential exposure of process memory.
Administrators should keep the response proportional to that evidence. The appearance of an affected version in inventory supports updating and verification. By itself, it does not establish that a device was exploited, that credentials were stolen, or that the handset should be erased.
There is also an important scoring-provenance distinction. CISA-ADP supplied the 6.5 CVSS 3.1 score, while NVD had not supplied its own CVSS assessment at the stated record date. Reports and dashboards should therefore identify the score as originating from CISA-ADP rather than describing it as an NVD-calculated score.
For that reason, the desktop release-note reference should not be used here to claim that the page lists CVE-2026-13923, Chrome 150.0.7871.47 for Windows or Mac, or a related Linux build. Those details would require a separately supplied or verified copy of the release notes.
The available affected-product information is more specific: it identifies Chrome on Android before 150.0.7871.47. That is the scope administrators should use when acting on the evidence currently available.
A referenced desktop bulletin can still be relevant to provenance or vendor context, but a reference alone does not prove that desktop platforms are affected by the same CVE. Security teams should distinguish among three separate facts:
For WindowsForum readers, the operational lesson is straightforward: a vulnerability does not need to affect Windows to matter to a Windows-oriented organization. Many IT teams manage Windows endpoints alongside Android phones, identity services, mobile access, and application compliance. The platform boundary should be respected without treating mobile Chrome as someone else’s responsibility.
The restricted record also means several important technical questions remain unanswered in the supplied material:
The supplied SSVC snapshot records exploitation as “none,” automatable as “no,” and technical impact as “partial.” The “none” entry should be read only as the exploitation status recorded at that snapshot, not as proof that exploitation has never occurred or could never occur.
Taken together, the public signals support patching without panic. The issue is remotely deliverable through crafted web content and carries a High confidentiality-impact value, but the available material does not document code execution, integrity loss, availability loss, a scope change, or active exploitation.
The most useful administrative response is to identify affected versions, provide an update path, and verify completion. Broader actions should depend on an organization’s own risk assessment, device-management capabilities, exposure evidence, and incident-response policies rather than on unsupported assumptions about this CVE.
Managed and personally owned devices may require different workflows. Some organizations can query installed application versions centrally, while others must rely on user confirmation or access-policy data. Those are general management considerations, not documented properties of CVE-2026-13923.
Likewise, update availability should not be treated as proof of installation. Where inventory tools are available, administrators should prefer a reported installed version over assumptions based on rollout approval, update publication, or major-version labels.
The precise boundary matters. An installation that reports only “Chrome 150” has not provided enough information to confirm remediation. The complete installed version should be compared with 150.0.7871.47.
These distinctions are not merely administrative trivia. Vulnerability-management products can display several scores and labels side by side, or collapse them into a single summary. If the source is omitted, a reader may incorrectly assume that every field was calculated or confirmed by NVD.
A clear report should therefore say “CISA-ADP score: 6.5” rather than “NVD score: 6.5.” It should also preserve the difference between a vendor description, an NVD configuration, an external score, and an SSVC snapshot.
If the installed version remains below 150.0.7871.47 and no update is offered, the user should follow the support or device-management process appropriate to that device. The CVE record itself does not establish why an update might be unavailable.
For a fleet, the key question is not whether an update was announced, approved, or offered. It is whether each in-scope Android device reports an installed Chrome version at or above the required boundary.
Administrators should compare complete version strings. Every confirmed installation below 150.0.7871.47 falls within the affected range. A device with incomplete or stale inventory should be recorded separately rather than counted as compliant.
Organizations should also avoid substituting desktop version information for Android inventory. The supplied record supports an Android affected range; it does not provide a verified desktop scope for this CVE.
The record does not document device takeover, code execution, sandbox escape, privilege escalation, persistent compromise, or a specific category of stolen data. It also does not supply the technical detail needed to make claims about source changes, texture-copy behavior, graphics buffers, process ownership, renderer compromise, or hardware-specific reliability.
The immediate task is therefore measurable: update Chrome on Android to 150.0.7871.47 or later and verify the complete installed version. The longer-term lesson is equally practical. Security teams should preserve platform scope, score provenance, evidence boundaries, and version precision when converting a vulnerability record into an operational ticket.
If Google later publishes additional technical analysis, revises the affected configuration, or provides verified platform-specific release information, administrators can reassess the scope and attack mechanics. Until then, the sound response is prompt version-based remediation without turning unanswered questions into unsupported claims.
The documented exposure is a crafted-HTML-triggered potential disclosure of sensitive information from browser process memory, not a documented device takeover. The public record does not establish remote code execution, sandbox escape, privilege escalation, persistent compromise, or active exploitation.
A Medium Rating Conceals a Serious Confidentiality Failure
Chrome classifies CVE-2026-13923 as Medium, and the CISA Authorized Data Publisher, or CISA-ADP, supplied a CVSS 3.1 base score of 6.5. The associated vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N.In practical terms, the vector describes a network-delivered attack with low attack complexity and no requirement for prior attacker privileges. User interaction is required, the security scope is unchanged, and the recorded impact is High for confidentiality but None for integrity and availability.
The vulnerability description says a remote attacker can use a crafted HTML page to obtain potentially sensitive information from Chrome process memory. The public material does not specify what information might be exposed, how much memory might be disclosed, how repeatable the result is, or whether the returned data would be consistently useful to an attacker.
Those limits matter. It would be unsupported to claim that the flaw reliably exposes passwords, authentication tokens, personal information, browsing history, or data from a particular website. It would also be inappropriate to dismiss the issue as an inconsequential display problem: the documented security consequence is potential disclosure of sensitive process memory, and the supplied CVSS vector records a High confidentiality impact.
The defensible characterization is therefore narrow but meaningful. CVE-2026-13923 is an information-disclosure vulnerability affecting Chrome on Android before the stated version boundary. The available evidence does not show that the flaw can independently alter data, install software, gain Android privileges, or take control of the device.
The GPU Path Is Part of the Browser’s Security Surface
NVD maps the issue to CWE-457, Use of Uninitialized Variable. The supplied material does not provide enough technical detail to explain precisely which value was uninitialized, how the condition arose, or how data moved from the affected operation into content observable by an attacker.The vulnerability is identified as a GPU-related issue, but that label should not be expanded beyond the available evidence. The public record does not establish whether the relevant memory is owned by a particular Chrome process, resides in a graphics buffer, comes from an earlier browser operation, or crosses any specific internal boundary.
It also does not establish that the underlying defect is in physical GPU hardware, the Android kernel, a device manufacturer’s driver, or a particular graphics implementation. The affected-product information identifies Google Chrome on Android, and the verified impact statement concerns potential disclosure from browser process memory.
Browsers use graphics-related components to process and display web content, so a crafted page can reach complex browser functionality without requiring the attacker to distribute a native Android application. That general observation helps explain why a GPU-related defect can be web-triggered, but it is not a substitute for the restricted technical analysis of this particular CVE.
No verified public source change has been supplied that demonstrates a texture-copy, luma-emulation, rasterizer-discard, or skipped-copy explanation for CVE-2026-13923. Those details should not be presented as part of the vulnerability’s mechanism unless Google or another authoritative source explicitly connects them to this CVE.
User Interaction Separates Exposure from Triggering
The CISA-ADP vector records User Interaction Required. The verified attack narrative is that a remote attacker prepares crafted HTML and an affected Chrome for Android user interacts with the content, allowing the vulnerable browser path to be reached.That does not mean every device with an affected Chrome version has already disclosed information. The browser must process the malicious content under the conditions needed to trigger the flaw. At the same time, the user-interaction requirement does not eliminate the need to update, because following links and loading web content are ordinary browser activities.
The vector records no integrity impact and no availability impact. On the supplied evidence, CVE-2026-13923 is not documented as changing browser or operating-system data, installing an application, corrupting files, or making the device unavailable. The stated consequence is potential exposure of process memory.
Administrators should keep the response proportional to that evidence. The appearance of an affected version in inventory supports updating and verification. By itself, it does not establish that a device was exploited, that credentials were stolen, or that the handset should be erased.
There is also an important scoring-provenance distinction. CISA-ADP supplied the 6.5 CVSS 3.1 score, while NVD had not supplied its own CVSS assessment at the stated record date. Reports and dashboards should therefore identify the score as originating from CISA-ADP rather than describing it as an NVD-calculated score.
A Desktop Reference Does Not Define the Affected Scope
NVD references Google’s Stable Channel Update for Desktop, but the supplied material establishes only that NVD includes that URL as a reference. It does not directly quote the release-note content or independently verify what CVE entries and desktop build numbers appear on that page.For that reason, the desktop release-note reference should not be used here to claim that the page lists CVE-2026-13923, Chrome 150.0.7871.47 for Windows or Mac, or a related Linux build. Those details would require a separately supplied or verified copy of the release notes.
The available affected-product information is more specific: it identifies Chrome on Android before 150.0.7871.47. That is the scope administrators should use when acting on the evidence currently available.
A referenced desktop bulletin can still be relevant to provenance or vendor context, but a reference alone does not prove that desktop platforms are affected by the same CVE. Security teams should distinguish among three separate facts:
- NVD references a Google desktop stable-channel page.
- The CVE description identifies Chrome on Android before 150.0.7871.47.
- The supplied affected configuration combines the vulnerable Chrome range with Android.
| Record or device state | Platform | Version condition | What the supplied material supports | Administrative interpretation |
|---|---|---|---|---|
| Affected configuration | Android | Earlier than 150.0.7871.47 | Chrome on Android below the boundary is affected | Update and verify the installed version |
| Minimum acceptable boundary | Android | 150.0.7871.47 | The affected range ends before this version | Treat this or a later version as remediated for this CVE |
| NVD reference | Desktop stable-channel page | Not established by the supplied excerpt | NVD references the page | Do not infer desktop exposure or build details from the reference alone |
| Windows, macOS, or Linux installation | Desktop | Not established | No verified desktop affected range was supplied | Do not open a desktop incident solely from the referenced page |
The Restricted Chromium Issue Leaves Key Questions Open
Google’s associated Chromium issue is permission-restricted. Without verified public content from that issue, reporting should not claim what an unauthenticated viewer can inspect, whether linked source changes are visible, or whether reproduction steps, test cases, internal comments, or exploitability analysis are available to particular classes of users.The restricted record also means several important technical questions remain unanswered in the supplied material:
- Which exact memory region can be exposed.
- How much information can be returned.
- Whether repeated triggering changes or improves the disclosure.
- Whether the exposed values are predictable.
- Whether an attacker can influence the contents.
- Whether the behavior varies by Android device, graphics hardware, driver, or browser configuration.
- Whether exploitation depends on any undocumented browser-process prerequisite.
- Whether a renderer compromise is required.
- Whether the disclosed data comes from GPU-process memory, a graphics buffer, or another location.
The supplied SSVC snapshot records exploitation as “none,” automatable as “no,” and technical impact as “partial.” The “none” entry should be read only as the exploitation status recorded at that snapshot, not as proof that exploitation has never occurred or could never occur.
Taken together, the public signals support patching without panic. The issue is remotely deliverable through crafted web content and carries a High confidentiality-impact value, but the available material does not document code execution, integrity loss, availability loss, a scope change, or active exploitation.
Evidence Versus Unknowns
CVE-2026-13923 is a useful example of why vulnerability reporting should separate verified facts from plausible but unsupported technical interpretations.What the supplied evidence establishes
- The affected product is Chrome on Android.
- Versions earlier than 150.0.7871.47 are affected.
- The attack is delivered through crafted HTML.
- User interaction is required.
- No prior attacker privileges are required according to the CISA-ADP vector.
- The documented consequence is potential disclosure of sensitive information from process memory.
- NVD maps the issue to CWE-457, Use of Uninitialized Variable.
- CISA-ADP supplied a CVSS 3.1 score of 6.5.
- The vector records High confidentiality impact, with no integrity or availability impact.
- The SSVC snapshot records exploitation as “none,” automatable as “no,” and technical impact as “partial.”
- At the stated record date, NVD had not supplied its own CVSS assessment.
What the supplied evidence does not establish
- Remote code execution.
- Device takeover.
- Android privilege escalation.
- A sandbox escape.
- Persistent malware installation.
- Compromise without user interaction.
- A renderer-compromise prerequisite.
- Exposure of passwords, session tokens, or any other specific data type.
- The amount, reliability, or repeatability of the disclosed memory.
- GPU-process memory versus graphics-buffer memory.
- Device-, chipset-, or driver-specific behavior.
- A public source change explaining the vulnerability.
- A texture-copy, luma-emulation, rasterizer-discard, or skipped-copy mechanism.
- Active exploitation beyond the SSVC status recorded at the cited snapshot.
- An affected Windows, macOS, or Linux version range.
- Desktop build details allegedly appearing in the referenced Google page.
Mobile Chrome Is an Enterprise Endpoint
Chrome on Android may be used to reach organizational websites, cloud services, identity pages, support portals, and other web-based resources. That makes browser version visibility an ordinary part of endpoint administration, even though this CVE does not establish exposure of any particular enterprise data.The most useful administrative response is to identify affected versions, provide an update path, and verify completion. Broader actions should depend on an organization’s own risk assessment, device-management capabilities, exposure evidence, and incident-response policies rather than on unsupported assumptions about this CVE.
Managed and personally owned devices may require different workflows. Some organizations can query installed application versions centrally, while others must rely on user confirmation or access-policy data. Those are general management considerations, not documented properties of CVE-2026-13923.
Likewise, update availability should not be treated as proof of installation. Where inventory tools are available, administrators should prefer a reported installed version over assumptions based on rollout approval, update publication, or major-version labels.
The precise boundary matters. An installation that reports only “Chrome 150” has not provided enough information to confirm remediation. The complete installed version should be compared with 150.0.7871.47.
The Record’s Provenance Matters
The public record reflects contributions from different organizations with different roles. Chrome supplied the core vulnerability information and affected-version boundary. CISA-ADP supplied the CVSS 3.1 assessment and SSVC information. NVD added or presented product configuration and reference metadata but had not supplied its own CVSS assessment at the stated record date.These distinctions are not merely administrative trivia. Vulnerability-management products can display several scores and labels side by side, or collapse them into a single summary. If the source is omitted, a reader may incorrectly assume that every field was calculated or confirmed by NVD.
A clear report should therefore say “CISA-ADP score: 6.5” rather than “NVD score: 6.5.” It should also preserve the difference between a vendor description, an NVD configuration, an external score, and an SSVC snapshot.
Record timeline
- Chrome contribution: The core description, Android scope, CWE mapping, references, and affected-version boundary entered the record.
- CISA-ADP contribution: The CVSS 3.1 vector and 6.5 Medium base score were added.
- SSVC snapshot: The record marked exploitation as “none,” automatable as “no,” and technical impact as “partial.”
- NVD enrichment: Product-configuration and reference metadata were added or presented while NVD’s own CVSS assessment remained absent at the stated record date.
How Android Users Can Update and Verify Chrome
Android users should update through Google Play and then check the complete installed Chrome version. Interface wording can vary by Android release, Play Store version, device manufacturer, and account configuration.Update through Google Play
- Open Android Settings.
- Select Apps.
- Select Google Play Store and open it. Users can also open the Play Store directly from the app launcher.
- Tap the profile icon.
- Select Manage apps & device.
- Open Updates available.
- Find Chrome.
- Tap Update.
Verify the installed Chrome version
- Open Chrome.
- Tap the three-dot menu.
- Select Settings.
- Select About Chrome.
- Confirm that the displayed version is 150.0.7871.47 or later.
If the installed version remains below 150.0.7871.47 and no update is offered, the user should follow the support or device-management process appropriate to that device. The CVE record itself does not establish why an update might be unavailable.
Version Detection Is the Real Remediation Test
For an individual user, the remedy is uncomplicated: install the Chrome update and verify that the application reports version 150.0.7871.47 or later.For a fleet, the key question is not whether an update was announced, approved, or offered. It is whether each in-scope Android device reports an installed Chrome version at or above the required boundary.
Administrators should compare complete version strings. Every confirmed installation below 150.0.7871.47 falls within the affected range. A device with incomplete or stale inventory should be recorded separately rather than counted as compliant.
Organizations should also avoid substituting desktop version information for Android inventory. The supplied record supports an Android affected range; it does not provide a verified desktop scope for this CVE.
Action checklist for admins
- Inventory the complete installed Chrome version on in-scope Android devices.
- Flag confirmed installations earlier than 150.0.7871.47.
- Make the current approved Chrome update available through the organization’s normal mobile-management process.
- Recheck inventory after the update period.
- Separate confirmed compliant, confirmed affected, stale, and unreachable devices.
- Provide end users with the Google Play update and Chrome version-verification steps.
- Require the full version number rather than accepting “Chrome 150” as proof of remediation.
- Do not infer Windows, macOS, or Linux exposure solely because NVD references a desktop stable-channel page.
- Record the 6.5 score as a CISA-ADP assessment.
- Preserve NVD’s assessment status separately rather than labeling the CISA-ADP score as an NVD calculation.
- Escalate additional containment or investigation only when supported by organizational risk factors or concrete evidence, not merely by the presence of an affected version.
What Android and Windows Teams Should Carry Forward
CVE-2026-13923 is a bounded Chrome for Android information-disclosure issue whose remediation is clearer than its surrounding metadata. Chrome on Android below 150.0.7871.47 is affected, crafted HTML and user interaction are required, and the documented outcome is potential process-memory disclosure.The record does not document device takeover, code execution, sandbox escape, privilege escalation, persistent compromise, or a specific category of stolen data. It also does not supply the technical detail needed to make claims about source changes, texture-copy behavior, graphics buffers, process ownership, renderer compromise, or hardware-specific reliability.
The immediate task is therefore measurable: update Chrome on Android to 150.0.7871.47 or later and verify the complete installed version. The longer-term lesson is equally practical. Security teams should preserve platform scope, score provenance, evidence boundaries, and version precision when converting a vulnerability record into an operational ticket.
If Google later publishes additional technical analysis, revises the affected configuration, or provides verified platform-specific release information, administrators can reassess the scope and attack mechanics. Until then, the sound response is prompt version-based remediation without turning unanswered questions into unsupported claims.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:41:10-07:00
NVD - CVE-2026-13923
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:41:10-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromium.googlesource.com
- Related coverage: cvefeed.io
CVE-2026-13950 - Google Chrome Use-After-Free in GPU
Uninitialized Use in GPU in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium)cvefeed.io - Related coverage: security.snyk.io
Use of Uninitialized Variable in chromium | CVE-2026-13923 | Snyk
Use of Uninitialized Variable in chromium | CVE-2026-13923security.snyk.io