MEDIUM 5.3

CVE-2026-13877: ANGLE Memory Disclosure in Google Chrome—Patch & Guidance

A vulnerability in Google Chrome's ANGLE graphics library allows an attacker who has already gained control of the browser's renderer process to read sensitive data from the browser's memory by tricking a user into viewing a specially crafted webpage. The attacker cannot exploit this directly from the internet—they must first compromise the renderer, making this a secondary attack that increases the severity of other browser vulnerabilities. Chrome versions before 150.0.7871.47 are affected.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.3 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N
Weaknesses (CWE)
CWE-20
Affected products
4 configuration(s)
Published / Modified
2026-06-30 / 2026-07-01

NVD description (verbatim)

Insufficient validation of untrusted input in ANGLE 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)

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-13877 is an insufficient input validation flaw in ANGLE (Almost Native Graphics Layer Engine), Chrome's graphics abstraction layer. The vulnerability exists in how ANGLE processes untrusted input without proper sanitization, enabling memory disclosure from the compromised renderer process. An attacker with renderer-level code execution can craft HTML content that triggers out-of-bounds memory reads, leaking data that may contain sensitive information such as encryption keys, authentication tokens, or other process-resident secrets. The issue is tracked as CVSS 5.3 (Medium) with a vector reflecting network accessibility but requiring both renderer compromise and user interaction.

Business impact

This vulnerability reduces defense-in-depth by turning renderer exploits into information disclosure attacks. Organizations defending against browser-based attacks face increased risk if other Chrome vulnerabilities are leveraged first to gain renderer access. The ability to exfiltrate memory contents could expose session tokens, cached credentials, or sensitive document data processed by web applications. For enterprises using Chrome in security-sensitive environments (development teams, financial services, government), this compounds the impact of renderer sandbox escapes or other process compromises.

Affected systems

Google Chrome prior to version 150.0.7871.47 on Windows, macOS, and Linux is affected. The vulnerability is in the ANGLE graphics library, which is cross-platform, so all three operating system builds of Chrome require patching. Linux kernel and Windows versions listed as affected vendors refer to the underlying operating systems where Chrome runs; the vulnerability itself is specific to Chrome's ANGLE implementation.

Exploitability

Exploitation requires a two-stage attack: first, the attacker must compromise the Chrome renderer process through a separate vulnerability or exploit. Second, they must deliver a crafted HTML page to the user. Once renderer access is established, the ANGLE validation flaw is reliably exploitable to leak memory. Chromium's sandbox architecture means this is not a network-direct remote code execution risk, but it significantly amplifies the impact of renderer-level compromises. The requirement for user interaction (visiting a webpage) and the need for prior renderer compromise keeps the CVSS score moderate.

Remediation

Update Google Chrome to version 150.0.7871.47 or later immediately. Automatic updates should deploy this patch across Windows, macOS, and Linux installations. Organizations managing Chrome fleet-wide should verify patch deployment through their endpoint management tools. There is no workaround; patching is the only mitigation. Given the memory-disclosure nature, organizations should also assess whether other browser vulnerabilities have been exploited in their environment, as this vulnerability often acts as a secondary payload.

Patch guidance

Deploy Chrome version 150.0.7871.47 or later across all affected platforms. On Windows and macOS, Chrome's auto-update mechanism will push the patch if enabled. On Linux, distribution package managers or manual updates may be required depending on deployment method. Verify installation with chrome://version in the address bar. If your organization uses Chrome Enterprise or Chromebook management, use admin policies to force immediate update and restrict use of older versions. Test patched builds in a limited environment first if you manage corporate deployments, though this is a Chromium-validated security fix with low regression risk.

Detection guidance

Monitor for Chrome crashes or unusual renderer behavior following deployment, which could indicate either the vulnerability being exploited or patch-related issues. Analyze network telemetry for unusual outbound connections from Chrome processes post-compromise, as memory disclosure attacks often precede data exfiltration. Security event logs should flag renderer process terminations and restarts in rapid succession. Endpoint Detection and Response (EDR) tools can monitor for suspicious ANGLE library access patterns, though detection of the vulnerability itself is difficult without behavioral anomalies. Focus monitoring on users who may be targeted by sophisticated attackers or who browse untrusted content.

Why prioritize this

Although CVSS 5.3 is moderate, this vulnerability should be prioritized because it is a secondary amplifier of other browser exploits. Patching reduces the attack surface for multi-stage campaigns targeting your users. It is not critical for standalone exploitation, but it prevents attackers from weaponizing subsequent renderer compromises for information theft. Organizations with high-value targets (developers, researchers, financial analysts) should patch immediately.

Risk score, explained

CVSS 5.3 (Medium) reflects the requirement for both renderer compromise and user interaction, tempering the severity. However, the attack vector is Network and the impact is Confidentiality High—meaning memory disclosure can be substantial. The score is appropriate: this is not a critical sandbox escape, but it is a meaningful information disclosure vulnerability that becomes dangerous in combination with other Chrome flaws. Prioritization should account for your threat model and whether you expect targeted attacks against your user base.

Frequently asked questions

Does this vulnerability allow hackers to attack me directly over the internet?

No. An attacker must first compromise the Chrome renderer process through another vulnerability or method. Only then can they use this ANGLE flaw to read memory. It is a secondary attack, not a direct entry point.

What information can be stolen through this vulnerability?

The attacker can leak sensitive data resident in the Chrome process memory, such as session tokens, cached passwords, encryption keys, API credentials, or data from open web pages and applications. The exact content depends on what the user is doing in Chrome at the time.

Do I need to do anything besides update Chrome?

Updating to 150.0.7871.47 or later is the primary mitigation. If you manage a fleet, ensure the patch is deployed uniformly. Consider auditing logs and security alerts around the time this patch was released to check whether your organization may have been targeted.

Is this vulnerability being actively exploited in the wild?

This vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, meaning there is no confirmed active exploitation in public attacks. However, organizations should still patch promptly as sophisticated threat actors often discover and exploit memory-disclosure flaws.

This analysis is based on Chromium security advisories and CVE data as of the publication date. Patch version numbers and availability should be verified against Google's official Chrome release notes. This vulnerability requires prior renderer process compromise; it is not a standalone network attack vector. Organizations should test patches in their own environment before fleet deployment. SEC.co provides this information for threat assessment and patch planning; it does not constitute legal or compliance advice. Source: NVD (public-domain), retrieved 2026-08-09. Analysis generated by SEC.co (claude-haiku-4-5).