Affected: Google Chrome on macOS before 150.0.7871.47. Fix: update to 150.0.7871.47 or later. Windows and Linux are not listed in this CVE configuration.
CVE-2026-13819 is a High-severity out-of-bounds read in Chrome’s ANGLE component. The Chrome-originated description says an attacker who had already compromised the renderer process could use crafted HTML to trigger the flaw. That prerequisite is central to an accurate reading: the record does not describe CVE-2026-13819 as independently compromising an otherwise intact renderer, providing remote code execution, escaping the browser sandbox, or taking control of macOS.
The practical response is nevertheless clear. Macs running Chrome below the fixed boundary should be updated, and administrators should verify the complete installed version rather than relying on a general “Chrome 150” label. The published configuration is platform-specific, so Windows and Linux systems should not be treated as affected by this CVE without additional authoritative product information.
Chrome classifies CVE-2026-13819 as High severity. The CISA-ADP assessment displayed in the vulnerability record assigns it a CVSS 3.1 base score of 8.1 HIGH with the vector
Those labels describe a significant vulnerability, but they do not replace the Chrome-authored prose. The description expressly places the attacker in an already compromised renderer before the out-of-bounds read becomes available through crafted HTML. The record does not say that opening the crafted page, by itself, creates that renderer compromise.
The narrow and defensible description is therefore:
CVE-2026-13819 can be serious without being converted into a complete attack narrative. The available facts establish the vulnerable condition and the corrective version. They do not establish a companion renderer exploit, a sandbox escape, operating-system control, persistence, credential theft, or any other later-stage outcome.
That limitation matters. An out-of-bounds read is a recognized memory-safety weakness, but the weakness category alone does not prove that a particular type of secret, pointer, credential, token, file, or cross-origin data can be recovered in this case. It also does not establish that the read can be converted into code execution or used to defeat a specific mitigation.
The public description supports saying that the affected operation could read beyond its intended boundary after renderer compromise. It does not support naming the data that would be exposed in a practical exploit. It also does not provide a public proof of concept, exploit sample, indicator of compromise, or confirmed malicious campaign.
The CVSS vector records High confidentiality and availability impact and None for integrity. Those are the contributed assessment values, not a substitute for missing exploit details. In particular, the None integrity value is consistent with the record describing a read rather than claiming that this CVE directly writes or modifies arbitrary memory.
Administrators do not need a more elaborate technical theory to act. The vulnerable range is measurable, the corrected boundary is explicit, and the appropriate control is to remove affected Chrome versions from managed Macs.
These fields should be read together with the vulnerability description. “Privileges required: none” is a CVSS authorization metric; it does not delete the separately documented condition that the renderer has already been compromised. Similarly, Low attack complexity describes the contributed scoring assessment under its modeled conditions. It does not prove that obtaining the required renderer position is itself a low-complexity or single-step operation.
The displayed 8.1 score should remain attributed to CISA-ADP. The supplied record did not contain a separate NIST CVSS 4.0, CVSS 3.x, or CVSS 2.0 assessment. Describing 8.1 simply as “the NVD score” would hide the origin of the calculation.
The provided CISA Coordinator SSVC snapshot records:
CVSS and SSVC can coexist without contradiction because they capture different dimensions of the record. The CVSS contribution assigns a High technical severity score. The SSVC snapshot does not record known exploitation and characterizes automation and technical impact more narrowly. Neither system changes the affected product or the fixed-version boundary.
That statement must remain carefully bounded. The absence of Windows and Linux from this CVE configuration means the supplied record does not identify those platforms as affected. It is not proof about every possible related code path, every Chromium branch, or every downstream browser product.
The Windows and Linux rows are not declarations that every build on those platforms is technically incapable of containing related code. They are applicability statements based on the supplied CVE configuration. If another vendor or an updated authoritative record later identifies additional products or platforms, those products should be assessed under that information.
For the same reason, Chrome’s version threshold should not automatically be assigned to Microsoft Edge or another Chromium-derived browser. The record names Google Chrome, uses a Chrome build number, and pairs the affected application with macOS. Shared Chromium ancestry is not sufficient evidence that another vendor shipped the affected revision, exposes the same vulnerable path, or uses the same corrected-version boundary.
The correct product-specific approach is straightforward:
The supplied record does not say how that renderer compromise occurs. It does not identify a companion CVE, a delivery campaign, a public exploit, or an affected renderer feature that provides the initial foothold. Naming any such path would go beyond the available evidence.
The record also does not describe what happens beyond the out-of-bounds read. There is no documented sandbox escape, privilege escalation, kernel transition, arbitrary code execution, or macOS takeover attributed to CVE-2026-13819. Those outcomes should not be attached to the CVE merely because they may appear in generic discussions of browser security.
At the same time, the prerequisite does not make the version safe. A system running a version explicitly included in the affected range remains within the documented vulnerable configuration. Defenders can acknowledge the prerequisite while still completing a prompt, version-based remediation.
This produces a balanced operational statement: CVE-2026-13819 is not documented as the initial renderer compromise, but affected Mac installations should still be moved to the corrected Chrome version.
CISA-ADP assessment: The displayed record received the contributed CVSS 3.1 vector and 8.1 HIGH score, along with the SSVC values recording exploitation as none, automatable as no, and technical impact as partial.
NIST/NVD analysis: The vulnerability record presented the affected-product configuration pairing Google Chrome below the fixed boundary with Apple macOS.
The important lesson is attribution. A vulnerability page can display information from Chrome, CISA-ADP, and NIST together even though those organizations contributed different parts of the record. The score should remain attributed to CISA-ADP, while the product and behavior should remain tied to the Chrome-originated CVE information.
The supplied material does not justify a more granular chronology of particular fields being added, removed, or normalized. Such details should be included only when the exact change-history entries are available.
A user can perform the direct browser check as follows:
For a Windows endpoint, the supplied configuration does not provide a direct CVE basis for an affected finding. If an internal tool reports otherwise, administrators can treat that result as a hypothetical validation check:
The same restraint applies to organizational ownership. It is possible that Chrome on macOS is managed by a different team or inventory system, but that is not a fact supplied by the CVE record. Organizations should simply ensure that the person or system responsible for managed Macs receives the version boundary and can return current compliance evidence.
A Windows-only environment can document that Windows is not listed in the supplied affected configuration. A mixed environment should pass the macOS remediation requirement to the appropriate endpoint-management process. Neither situation requires extending the CVE beyond its documented scope.
It is equally important not to turn “none” into a permanent warranty. Vulnerability records can change as additional evidence emerges. If Chrome, CISA, NIST, or another authoritative product source later reports exploitation, expands the affected platforms, or revises the corrected version, defenders should reassess the issue using that updated information.
For the supplied snapshot, the complete SSVC statement is more useful than any single field:
The immediate technical control remains independent of that policy choice: Google Chrome on macOS below 150.0.7871.47 is within the documented affected range, and version 150.0.7871.47 or later crosses the published fix boundary.
For users, the response is short: on an affected Mac, open
For administrators, the response is measurable: identify Chrome installations on managed Macs, compare their complete versions with 150.0.7871.47, use the established managed update process, and retain current evidence that each in-scope installation crossed the boundary.
Future information could change the exploitation assessment or expand the product guidance. Until authoritative sources do so, the defensible conclusion is precise and limited: Google Chrome on macOS before 150.0.7871.47 is affected; 150.0.7871.47 or later is the fix boundary; Windows and Linux are not listed in this CVE configuration.
CVE-2026-13819 is a High-severity out-of-bounds read in Chrome’s ANGLE component. The Chrome-originated description says an attacker who had already compromised the renderer process could use crafted HTML to trigger the flaw. That prerequisite is central to an accurate reading: the record does not describe CVE-2026-13819 as independently compromising an otherwise intact renderer, providing remote code execution, escaping the browser sandbox, or taking control of macOS.
The practical response is nevertheless clear. Macs running Chrome below the fixed boundary should be updated, and administrators should verify the complete installed version rather than relying on a general “Chrome 150” label. The published configuration is platform-specific, so Windows and Linux systems should not be treated as affected by this CVE without additional authoritative product information.
A High Score Does Not Erase the Attack Prerequisite
Chrome classifies CVE-2026-13819 as High severity. The CISA-ADP assessment displayed in the vulnerability record assigns it a CVSS 3.1 base score of 8.1 HIGH with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:H.Those labels describe a significant vulnerability, but they do not replace the Chrome-authored prose. The description expressly places the attacker in an already compromised renderer before the out-of-bounds read becomes available through crafted HTML. The record does not say that opening the crafted page, by itself, creates that renderer compromise.
The narrow and defensible description is therefore:
- The affected product is Google Chrome on macOS.
- Versions earlier than 150.0.7871.47 are within the affected range.
- The weakness is classified as CWE-125, Out-of-bounds Read.
- Crafted HTML is involved.
- The attacker is assumed to have already compromised the renderer process.
- The documented result is an out-of-bounds memory read.
- The record does not describe the CVE as standalone remote code execution.
CVE-2026-13819 can be serious without being converted into a complete attack narrative. The available facts establish the vulnerable condition and the corrective version. They do not establish a companion renderer exploit, a sandbox escape, operating-system control, persistence, credential theft, or any other later-stage outcome.
The Documented Behavior Is an Out-of-Bounds Read
Chrome identifies the issue in ANGLE and maps it to CWE-125. Beyond those facts, the supplied record does not provide enough technical detail to explain the relevant ANGLE code path, the exact object involved, the layout of the accessed memory, or the content that could be returned.That limitation matters. An out-of-bounds read is a recognized memory-safety weakness, but the weakness category alone does not prove that a particular type of secret, pointer, credential, token, file, or cross-origin data can be recovered in this case. It also does not establish that the read can be converted into code execution or used to defeat a specific mitigation.
The public description supports saying that the affected operation could read beyond its intended boundary after renderer compromise. It does not support naming the data that would be exposed in a practical exploit. It also does not provide a public proof of concept, exploit sample, indicator of compromise, or confirmed malicious campaign.
The CVSS vector records High confidentiality and availability impact and None for integrity. Those are the contributed assessment values, not a substitute for missing exploit details. In particular, the None integrity value is consistent with the record describing a read rather than claiming that this CVE directly writes or modifies arbitrary memory.
Administrators do not need a more elaborate technical theory to act. The vulnerable range is measurable, the corrected boundary is explicit, and the appropriate control is to remove affected Chrome versions from managed Macs.
CVSS and SSVC Answer Different Questions
The CISA-ADP CVSS 3.1 vector records the following attributes:| Metric | Recorded value |
|---|---|
| Attack vector | Network |
| Attack complexity | Low |
| Privileges required | None |
| User interaction | Required |
| Scope | Unchanged |
| Confidentiality impact | High |
| Integrity impact | None |
| Availability impact | High |
| Base score | 8.1 HIGH |
The displayed 8.1 score should remain attributed to CISA-ADP. The supplied record did not contain a separate NIST CVSS 4.0, CVSS 3.x, or CVSS 2.0 assessment. Describing 8.1 simply as “the NVD score” would hide the origin of the calculation.
The provided CISA Coordinator SSVC snapshot records:
- Exploitation: none
- Automatable: no
- Technical impact: partial
CVSS and SSVC can coexist without contradiction because they capture different dimensions of the record. The CVSS contribution assigns a High technical severity score. The SSVC snapshot does not record known exploitation and characterizes automation and technical impact more narrowly. Neither system changes the affected product or the fixed-version boundary.
The macOS Scope Is the Most Important Applicability Fact
The supplied NVD configuration identifies Google Chrome on Apple macOS as affected when the Chrome version is earlier than 150.0.7871.47. Windows and Linux are not listed in that configuration.That statement must remain carefully bounded. The absence of Windows and Linux from this CVE configuration means the supplied record does not identify those platforms as affected. It is not proof about every possible related code path, every Chromium branch, or every downstream browser product.
| Deployment | Version state | What the supplied CVE record supports |
|---|---|---|
| Google Chrome on macOS | Earlier than 150.0.7871.47 | Listed within the affected configuration |
| Google Chrome on macOS | 150.0.7871.47 or later | At or beyond the published fixed boundary |
| Google Chrome on Windows | Any version | Windows is not listed in the supplied affected configuration |
| Google Chrome on Linux | Any version | Linux is not listed in the supplied affected configuration |
| Microsoft Edge or another Chromium-derived product | Any version | Not established by this Google Chrome CVE configuration |
For the same reason, Chrome’s version threshold should not automatically be assigned to Microsoft Edge or another Chromium-derived browser. The record names Google Chrome, uses a Chrome build number, and pairs the affected application with macOS. Shared Chromium ancestry is not sufficient evidence that another vendor shipped the affected revision, exposes the same vulnerable path, or uses the same corrected-version boundary.
The correct product-specific approach is straightforward:
- Apply the Chrome threshold to Google Chrome on macOS.
- Use Microsoft’s own advisories and release information for Microsoft Edge.
- Use the relevant vendor’s information for every other Chromium-derived product.
- Do not convert codebase similarity into a confirmed CVE finding without product-specific evidence.
Renderer Compromise Is a Required Condition
The phrase “had compromised the renderer process” is a required part of the vulnerability description, not optional background. It establishes that the documented out-of-bounds read occurs from a position the attacker has already obtained.The supplied record does not say how that renderer compromise occurs. It does not identify a companion CVE, a delivery campaign, a public exploit, or an affected renderer feature that provides the initial foothold. Naming any such path would go beyond the available evidence.
The record also does not describe what happens beyond the out-of-bounds read. There is no documented sandbox escape, privilege escalation, kernel transition, arbitrary code execution, or macOS takeover attributed to CVE-2026-13819. Those outcomes should not be attached to the CVE merely because they may appear in generic discussions of browser security.
At the same time, the prerequisite does not make the version safe. A system running a version explicitly included in the affected range remains within the documented vulnerable configuration. Defenders can acknowledge the prerequisite while still completing a prompt, version-based remediation.
This produces a balanced operational statement: CVE-2026-13819 is not documented as the initial renderer compromise, but affected Mac installations should still be moved to the corrected Chrome version.
What the Public Record Does—and Does Not—Establish
A disciplined vulnerability report should separate confirmed facts from possibilities that are not documented for this CVE.The record establishes
- Google Chrome is the affected product.
- The supplied configuration identifies Apple macOS.
- Chrome versions before 150.0.7871.47 are affected.
- Chrome 150.0.7871.47 is the fixed boundary.
- The affected component is identified as ANGLE.
- The weakness is an out-of-bounds read classified as CWE-125.
- Crafted HTML is part of the described trigger.
- The attacker is assumed to have already compromised the renderer.
- Chrome rates the issue High.
- CISA-ADP contributes an 8.1 HIGH CVSS 3.1 score.
- The provided SSVC snapshot records exploitation none, automatable no, and technical impact partial.
The record does not establish
- Standalone remote code execution.
- Initial renderer compromise through this CVE alone.
- A sandbox escape.
- Administrator or root access to macOS.
- Persistence on the endpoint.
- A specific category of exposed memory contents.
- Recovery of credentials, tokens, pointers, files, or cross-origin data.
- Bypass of a named browser or operating-system mitigation.
- A working public exploit or proof of concept.
- Active exploitation or a known attack campaign.
- Applicability to Windows or Linux.
- Applicability to Microsoft Edge or every Chromium-derived browser.
- A platform-independent Chrome 150 release event or rollout schedule.
- A CVE-specific workaround equivalent to installing the fixed version.
The Record Was Enriched in Stages
The supplied facts support a short sequence of record development, but not the previously asserted June and July calendar dates or detailed claims about every field added and removed. Those dates and unsupported change descriptions should not be repeated.Timeline
Initial Chrome-originated CVE information: The core record identified Google Chrome, ANGLE, the out-of-bounds read, crafted HTML, the renderer-compromise prerequisite, the macOS applicability, and the fixed-version boundary.CISA-ADP assessment: The displayed record received the contributed CVSS 3.1 vector and 8.1 HIGH score, along with the SSVC values recording exploitation as none, automatable as no, and technical impact as partial.
NIST/NVD analysis: The vulnerability record presented the affected-product configuration pairing Google Chrome below the fixed boundary with Apple macOS.
The important lesson is attribution. A vulnerability page can display information from Chrome, CISA-ADP, and NIST together even though those organizations contributed different parts of the record. The score should remain attributed to CISA-ADP, while the product and behavior should remain tied to the Chrome-originated CVE information.
The supplied material does not justify a more granular chronology of particular fields being added, removed, or normalized. Such details should be included only when the exact change-history entries are available.
Remediation Is a Version Check on Affected Macs
For an affected Mac, the corrective threshold is Google Chrome 150.0.7871.47 or later.A user can perform the direct browser check as follows:
- Open Google Chrome on the Mac.
- Go to
chrome://settings/help. - Confirm that the displayed version is 150.0.7871.47 or later.
- If Chrome requests a relaunch, select Relaunch.
- Return to
chrome://settings/helpand confirm the version after Chrome reopens.
Admin verification checklist
- Identify managed Macs on which Google Chrome is installed.
- Obtain the complete installed Chrome version.
- Mark versions earlier than 150.0.7871.47 as affected.
- Apply Chrome 150.0.7871.47 or later through the organization’s managed update process.
- Complete a requested Chrome relaunch.
- Verify the displayed or reported version after remediation.
- Keep installations with missing, stale, partial, or conflicting version information open as unverified.
- Record the 8.1 score as a CISA-ADP assessment rather than an independently authored NIST score.
- Do not assign the CVE to Windows, Linux, Edge, or another Chromium-derived browser without authoritative product-specific evidence.
Windows Teams Should Validate Scope Without Inventing Exposure
Windows administrators may still encounter CVE-2026-13819 in a general vulnerability feed, a cross-platform software inventory, or an internal security ticket. The appropriate response is to check the authoritative applicability data rather than automatically treating every Chrome installation as affected.For a Windows endpoint, the supplied configuration does not provide a direct CVE basis for an affected finding. If an internal tool reports otherwise, administrators can treat that result as a hypothetical validation check:
- Did the tool evaluate the macOS condition?
- Did it rely only on the Google Chrome product name?
- Did it compare the full version boundary?
- Is the finding based on additional authoritative information not included in the supplied record?
- Has the tool assigned a Google Chrome CVE to a different Chromium-derived browser?
The same restraint applies to organizational ownership. It is possible that Chrome on macOS is managed by a different team or inventory system, but that is not a fact supplied by the CVE record. Organizations should simply ensure that the person or system responsible for managed Macs receives the version boundary and can return current compliance evidence.
A Windows-only environment can document that Windows is not listed in the supplied affected configuration. A mixed environment should pass the macOS remediation requirement to the appropriate endpoint-management process. Neither situation requires extending the CVE beyond its documented scope.
“Exploitation: None” Is a Recorded Snapshot
The SSVC exploitation selection of “none” should be reported exactly for what it is: the value in the provided CISA Coordinator snapshot. It does not establish active exploitation, and the article should not describe CVE-2026-13819 as a confirmed zero-day or ongoing campaign.It is equally important not to turn “none” into a permanent warranty. Vulnerability records can change as additional evidence emerges. If Chrome, CISA, NIST, or another authoritative product source later reports exploitation, expands the affected platforms, or revises the corrected version, defenders should reassess the issue using that updated information.
For the supplied snapshot, the complete SSVC statement is more useful than any single field:
- Exploitation was recorded as none.
- Automation was recorded as no.
- Technical impact was recorded as partial.
The immediate technical control remains independent of that policy choice: Google Chrome on macOS below 150.0.7871.47 is within the documented affected range, and version 150.0.7871.47 or later crosses the published fix boundary.
The Last Word Should Be the Version, Not the Headline
CVE-2026-13819 demonstrates why accurate product and platform matching matters as much as a severity label. The 8.1 CISA-ADP score is significant, but it does not erase the renderer-compromise prerequisite. The High Chrome classification warrants attention, but it does not turn an out-of-bounds read into documented standalone RCE. The Chrome product name may appear across several operating systems, but the supplied affected configuration identifies macOS rather than Windows or Linux.For users, the response is short: on an affected Mac, open
chrome://settings/help, update to Google Chrome 150.0.7871.47 or later, relaunch if requested, and verify the version.For administrators, the response is measurable: identify Chrome installations on managed Macs, compare their complete versions with 150.0.7871.47, use the established managed update process, and retain current evidence that each in-scope installation crossed the boundary.
Future information could change the exploitation assessment or expand the product guidance. Until authoritative sources do so, the defensible conclusion is precise and limited: Google Chrome on macOS before 150.0.7871.47 is affected; 150.0.7871.47 or later is the fix boundary; Windows and Linux are not listed in this CVE configuration.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:39:33-07:00
NVD - CVE-2026-13819
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:39:33-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: security.snyk.io
Out-of-bounds Read in chromium | CVE-2026-13819 | Snyk
Out-of-bounds Read in chromium | CVE-2026-13819security.snyk.io - Related coverage: vulnerability.circl.lu
Vulnerability-Lookup
Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.vulnerability.circl.lu
