Google Chrome versions before 150.0.7871.47 on Mac are identified as affected by CVE-2026-13880, a use-after-free flaw in the browser’s USB code that could let a remote attacker escape Chrome’s sandbox through a crafted HTML page—but only after the attacker had already compromised the renderer process. Chromium labels the flaw Medium, while a CISA-ADP CVSS 3.1 assessment scores it 9.6 CRITICAL. Those ratings describe the same vulnerability through different assessment systems. The immediate response is straightforward: update Chrome on affected Macs and verify the running version.
On each Mac, open Chrome menu → Help → About Google Chrome, let Chrome check for and apply the update, click Relaunch, and return to the About page to confirm that the running version is 150.0.7871.47 or later. Enterprise administrators should perform the same verification through browser or endpoint inventory, while ensuring that inventory is scoped specifically to Google Chrome on macOS.
That prerequisite is essential to accurate risk communication. The vulnerability is best understood as a second-stage sandbox escape: an attacker needs another capability to compromise the renderer, after which CVE-2026-13880 may provide a route across the renderer’s containment boundary.
The record does not identify the first-stage vulnerability, technique, or campaign that would supply that prerequisite. Administrators should not pair CVE-2026-13880 with another CVE or claim that merely visiting a page is sufficient unless additional evidence becomes available.
The prerequisite does not make the flaw harmless. A renderer compromise that remains contained is materially different from one that can cross a sandbox boundary. In an exploit chain, an escape vulnerability may determine whether the attacker remains confined to a browser process or gains access beyond the boundary that process is supposed to enforce.
At the same time, the public description uses cautious language: the attacker could potentially perform a sandbox escape. It does not establish that exploitation automatically results in arbitrary code execution, persistence, kernel access, credential theft, or complete control of every affected Mac.
The strongest verified conclusions are narrower:
For CVE-2026-13880, the public description places the weakness in Chrome’s USB functionality. The available material does not disclose the exact object, function, callback, message, or operation involved. It therefore does not support claims about a specific WebUSB API sequence, device event, race condition, interprocess message, or physical peripheral.
The USB component name should not be interpreted as evidence that exploitation requires someone to insert malicious hardware into the Mac. The record describes a remote attacker, a crafted HTML page, and a network attack vector. In this context, “USB” identifies the Chrome component containing the memory-safety weakness; it does not establish physical USB access as the delivery method.
Analysis: The operational importance of the flaw comes from the boundary it may help cross, not merely from the name of the affected component. Security teams should prioritize the documented application and version range rather than redirecting the issue into a physical-port or peripheral-control workflow unsupported by the record.
The restricted Chromium issue reference prevents independent examination of the underlying bug report and technical mechanics. Until more details become public, assertions about exploit reliability, memory layout, triggering conditions, or required mitigation bypasses would be speculative.
The CISA-ADP vector is:
Under that vector, the path is treated as network-reachable, low in attack complexity, requiring no privileges in the scored authorization context, and requiring user interaction. It is also modeled as changing security scope and potentially causing high confidentiality, integrity, and availability impacts.
The renderer prerequisite may appear to conflict with the “Privileges Required: None” metric. The two statements address different concepts. The narrative describes a technical precondition in the exploit chain: the renderer must already be compromised. The CVSS privileges metric addresses privileges within the authorization context used by the scoring model. That distinction does not remove the prerequisite from the vulnerability description.
Chromium’s classification reflects the vendor’s treatment of the browser vulnerability, including the fact that it is not presented as the initial renderer compromise. The CISA-ADP vector models a successful attack as crossing a security boundary and producing severe consequences.
Neither rating, by itself, is proof of exploitation probability. The Medium label does not mean the vulnerability can be deferred indefinitely, and the 9.6 score does not mean any visit to a crafted page will immediately compromise a Mac.
The extractable conclusion is:
Calling 9.6 “the NVD score” would therefore conceal its provenance. A more accurate description is “the CISA-ADP CVSS 3.1 score displayed by NVD.”
That distinction can affect operational decisions. Organizations may use score thresholds to establish remediation targets, create tickets, prioritize scanner findings, or populate executive reporting. A platform that retains only the number while dropping the source can make a contributed assessment look like an independent NIST conclusion.
The record also warns that it was updated after NVD enrichment had been completed and that NVD-supplied enrichment may need amendment. Administrators should consequently treat database fields as versioned intelligence rather than assuming every field was entered simultaneously or will remain unchanged.
The supplied history supports several broad phases of record development:
The operating-system condition is part of the documented exposure boundary. A Windows machine should not be classified as vulnerable to CVE-2026-13880 solely because it runs Chrome or carries a version number that resembles one in the affected range.
That matters for WindowsForum readers because Windows-centered IT teams often administer more than Windows endpoints. They may own browser policy, identity access, security operations, compliance reporting, or endpoint inventory across a mixed fleet that includes Macs.
The correct query is therefore not “Where is Chrome installed?” It is:
The same restraint applies to Apple products. The presence of macOS in the configuration does not transform CVE-2026-13880 into a macOS, Safari, USB-driver, or peripheral-firmware vulnerability. macOS is the operating environment specified for the affected Chrome application.
Accurate scoping avoids two opposite errors: creating a broad alert across unaffected Windows systems and overlooking a smaller Mac population hidden inside an otherwise Windows-dominant fleet.
A more accurate sequence is:
Analysis: Layered defenses may reduce exposure to hostile content, but the supplied facts do not establish the specific effectiveness of URL filtering, remote browser isolation, endpoint prevention, or other compensating controls against this vulnerability. Such controls should not be presented as substitutes for reaching the documented version boundary.
This is also why the CISA-ADP SSVC options should be read together. “Exploitation: none” addresses identified exploitation at the time of assessment. “Automatable: no” addresses expected automation. “Technical impact: total” describes the modeled severity of a successful outcome. These are separate judgments, not contradictions.
A Mac reporting “Chrome 150” is not necessarily compliant. The relevant comparison is against the full value:
For an individual user, the verification procedure is direct:
Administrators should also identify policy conditions that prevent systems from reaching that boundary. Examples include intentionally pinned versions, maintenance exclusions, offline systems, unmanaged Macs, and approved deferral groups. These are general inventory considerations, not evidence of any particular Chrome update failure.
A broad fleet-wide compliance percentage can conceal the affected population if Macs represent only a small share of managed endpoints. Reporting should therefore show macOS Chrome compliance separately.
NVD publication — The National Vulnerability Database published the CVE record and identified Chrome as the source of the vulnerability description.
CISA-ADP assessment — CISA-ADP supplied a CVSS 3.1 vector producing a 9.6 CRITICAL score. It also supplied SSVC options stating exploitation was none, automation was no, and technical impact was total.
NIST enrichment — NIST added an affected-product configuration associating vulnerable Google Chrome versions with Apple macOS. It also classified the Chrome reference as a vendor-advisory reference and the restricted Chromium link as an issue-tracking reference.
Subsequent modification — The record received an additional CISA-ADP modification after the initial assessment and enrichment activity.
This timeline explains why products ingesting the record at different points may display different combinations of severity, platform, reference, and decision-support information. It does not establish that a specific modification removed or restored CWE-416, nor does it justify attributing every individual field to a particular change without the complete change record.
The supported operational statement is more precise: the affected configuration ends before 150.0.7871.47, making that build the documented version boundary for exposure assessment.
The restricted issue tracker limits responsible technical analysis. The public sources do not establish:
The same standard applies to impact. CISA-ADP’s high confidentiality, integrity, and availability metrics and “technical impact: total” option are modeled assessment results. They are not evidence that attackers have produced each outcome in real incidents.
Similarly, a Chrome crash is not proof of exploitation. The supplied information includes no validated crash signature, malicious domain, file hash, process pattern, or other indicator specific to this CVE. Version-based exposure identification is therefore the primary reliable control available from the record.
The difference between Chromium’s Medium classification and CISA-ADP’s 9.6 CRITICAL score is not a reason to delay remediation while analysts debate which label is more persuasive. It is a reminder that vendor severity, CVSS impact modeling, SSVC decision data, and NVD enrichment answer different questions.
For defenders, the operational decision does not require inaccessible exploit details. Find Google Chrome on macOS, identify versions below 150.0.7871.47, update them, relaunch the browser, and verify the running version. Do not widen the affected scope to Windows, Linux, other browsers, or macOS itself without separate evidence.
Future record changes may refine the scoring, references, configuration, or technical description. They may also expose more of the underlying Chromium analysis once disclosure restrictions change. Until then, administrators should anchor their response to the source-proven facts: a Mac-specific Chrome version boundary, a renderer-compromise prerequisite, a potential sandbox escape, and a clear verification target of 150.0.7871.47 or later.
On each Mac, open Chrome menu → Help → About Google Chrome, let Chrome check for and apply the update, click Relaunch, and return to the About page to confirm that the running version is 150.0.7871.47 or later. Enterprise administrators should perform the same verification through browser or endpoint inventory, while ensuring that inventory is scoped specifically to Google Chrome on macOS.
Action Checklist for Administrators
- Inventory Google Chrome installations on macOS.
- Flag every Mac running a Chrome version below 150.0.7871.47.
- Update affected installations through the organization’s approved browser or endpoint-management process.
- Relaunch Chrome and verify that the running four-part version is 150.0.7871.47 or later.
- Confirm the version locally on representative systems rather than relying solely on package deployment status.
- Identify Macs that are offline, unmanaged, excluded from deployment, or subject to update-deferral policies.
- Scope CVE-2026-13880 findings to Google Chrome on macOS; do not automatically classify Windows, Linux, or other Chromium-derived browsers as affected.
- Review relevant browser and endpoint telemetry without treating ordinary crashes as evidence that this CVE was exploited.
- Track changes to the NVD and vendor-originated records because the vulnerability entry has received multiple rounds of enrichment.
This Is an Escape Route, Not the Front Door
CVE-2026-13880 is not described as a stand-alone compromise of an otherwise secure Mac. According to the Chrome-originated description published through the National Vulnerability Database, an attacker must first have compromised Chrome’s renderer process before using the USB vulnerability to potentially escape the browser sandbox through a crafted HTML page.That prerequisite is essential to accurate risk communication. The vulnerability is best understood as a second-stage sandbox escape: an attacker needs another capability to compromise the renderer, after which CVE-2026-13880 may provide a route across the renderer’s containment boundary.
The record does not identify the first-stage vulnerability, technique, or campaign that would supply that prerequisite. Administrators should not pair CVE-2026-13880 with another CVE or claim that merely visiting a page is sufficient unless additional evidence becomes available.
The prerequisite does not make the flaw harmless. A renderer compromise that remains contained is materially different from one that can cross a sandbox boundary. In an exploit chain, an escape vulnerability may determine whether the attacker remains confined to a browser process or gains access beyond the boundary that process is supposed to enforce.
At the same time, the public description uses cautious language: the attacker could potentially perform a sandbox escape. It does not establish that exploitation automatically results in arbitrary code execution, persistence, kernel access, credential theft, or complete control of every affected Mac.
The strongest verified conclusions are narrower:
- The weakness is described as Use After Free in USB.
- The record identifies CWE-416, Use After Free.
- The affected product is Google Chrome running on Apple macOS.
- The attack description involves a crafted HTML page.
- Renderer compromise is a prerequisite.
- Versions below 150.0.7871.47 are within the affected range recorded by NVD.
- CISA-ADP’s assessment reports no identified exploitation at the time of its analysis.
A Freed Object Creates a Memory-Safety Failure
A use-after-free vulnerability occurs when software continues to access an object after the memory associated with that object has been released. The reference left behind may point to invalid data or to memory that has since been reused. Depending on the surrounding conditions, the result can range from a process crash to unintended reads, writes, or changes in program behavior.For CVE-2026-13880, the public description places the weakness in Chrome’s USB functionality. The available material does not disclose the exact object, function, callback, message, or operation involved. It therefore does not support claims about a specific WebUSB API sequence, device event, race condition, interprocess message, or physical peripheral.
The USB component name should not be interpreted as evidence that exploitation requires someone to insert malicious hardware into the Mac. The record describes a remote attacker, a crafted HTML page, and a network attack vector. In this context, “USB” identifies the Chrome component containing the memory-safety weakness; it does not establish physical USB access as the delivery method.
Analysis: The operational importance of the flaw comes from the boundary it may help cross, not merely from the name of the affected component. Security teams should prioritize the documented application and version range rather than redirecting the issue into a physical-port or peripheral-control workflow unsupported by the record.
The restricted Chromium issue reference prevents independent examination of the underlying bug report and technical mechanics. Until more details become public, assertions about exploit reliability, memory layout, triggering conditions, or required mitigation bypasses would be speculative.
“Medium” and “Critical” Reflect Different Rating Systems
The most important interpretive issue is the distance between Chromium’s Medium security severity and the 9.6 CRITICAL CVSS 3.1 score attributed to CISA-ADP. Neither label should be erased, and neither should be presented as if it were the only valid description.| Assessment | Rating or result | What it represents | Practical reading |
|---|---|---|---|
| Chromium security severity | Medium | The vendor’s security-severity classification for the Chrome flaw | A significant browser defect whose use is constrained by the renderer-compromise prerequisite |
| CISA-ADP CVSS 3.1 | 9.6 CRITICAL | A standardized score based on the selected exploitability and impact metrics | Severe modeled consequences if exploitation succeeds under the vector’s assumptions |
| CISA-ADP SSVC | Exploitation: none; automatable: no; technical impact: total | Decision-oriented options addressing exploitation status, automation, and impact | No exploitation identified in the assessment, no expected automation, but potentially total technical impact |
| NIST NVD assessment | Not provided in the represented record | NIST’s own CVSS assessment | The 9.6 score should not be described as an independent NIST score |
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:HUnder that vector, the path is treated as network-reachable, low in attack complexity, requiring no privileges in the scored authorization context, and requiring user interaction. It is also modeled as changing security scope and potentially causing high confidentiality, integrity, and availability impacts.
The renderer prerequisite may appear to conflict with the “Privileges Required: None” metric. The two statements address different concepts. The narrative describes a technical precondition in the exploit chain: the renderer must already be compromised. The CVSS privileges metric addresses privileges within the authorization context used by the scoring model. That distinction does not remove the prerequisite from the vulnerability description.
Interpretation of the Two Ratings
The safest interpretation is not that one rating is correct and the other is wrong. Chromium’s Medium label and CISA-ADP’s 9.6 score come from different rating systems with different purposes and inputs.Chromium’s classification reflects the vendor’s treatment of the browser vulnerability, including the fact that it is not presented as the initial renderer compromise. The CISA-ADP vector models a successful attack as crossing a security boundary and producing severe consequences.
Neither rating, by itself, is proof of exploitation probability. The Medium label does not mean the vulnerability can be deferred indefinitely, and the 9.6 score does not mean any visit to a crafted page will immediately compromise a Mac.
The extractable conclusion is:
This source-provenance distinction matters when vulnerability-management products reduce several fields to a single severity badge.
The 9.6 Score Is Not an NVD Verdict
The National Vulnerability Database displays vulnerability information contributed and enriched by multiple sources. In this record, the CVSS 3.1 score of 9.6 is attributed to CISA-ADP. NIST had not supplied its own CVSS 3.x, CVSS 4.0, or CVSS 2.0 assessment in the represented material.Calling 9.6 “the NVD score” would therefore conceal its provenance. A more accurate description is “the CISA-ADP CVSS 3.1 score displayed by NVD.”
That distinction can affect operational decisions. Organizations may use score thresholds to establish remediation targets, create tickets, prioritize scanner findings, or populate executive reporting. A platform that retains only the number while dropping the source can make a contributed assessment look like an independent NIST conclusion.
The record also warns that it was updated after NVD enrichment had been completed and that NVD-supplied enrichment may need amendment. Administrators should consequently treat database fields as versioned intelligence rather than assuming every field was entered simultaneously or will remain unchanged.
The supplied history supports several broad phases of record development:
- Chrome-originated vulnerability information entered the record.
- CISA-ADP contributed CVSS and SSVC assessment data.
- NIST added affected-product configuration and reference classifications.
- The record received subsequent modification.
Mac-Only Scope Prevents a Windows Panic, Not a Windows-Team Pass
The affected-product configuration pairs Google Chrome versions below 150.0.7871.47 with Apple macOS. Based on that configuration, this CVE should not be described as affecting Chrome on Windows or Linux.The operating-system condition is part of the documented exposure boundary. A Windows machine should not be classified as vulnerable to CVE-2026-13880 solely because it runs Chrome or carries a version number that resembles one in the affected range.
That matters for WindowsForum readers because Windows-centered IT teams often administer more than Windows endpoints. They may own browser policy, identity access, security operations, compliance reporting, or endpoint inventory across a mixed fleet that includes Macs.
The correct query is therefore not “Where is Chrome installed?” It is:
- Where is Google Chrome installed?
- Which installations are running on macOS?
- Which of those installations are below 150.0.7871.47?
- Which affected systems have not yet been updated and verified?
The same restraint applies to Apple products. The presence of macOS in the configuration does not transform CVE-2026-13880 into a macOS, Safari, USB-driver, or peripheral-firmware vulnerability. macOS is the operating environment specified for the affected Chrome application.
Accurate scoping avoids two opposite errors: creating a broad alert across unaffected Windows systems and overlooking a smaller Mac population hidden inside an otherwise Windows-dominant fleet.
The Crafted Page Still Needs a Compromised Renderer
The phrase “crafted HTML page” can resemble the description of a conventional drive-by compromise. CVE-2026-13880 is web-delivered in the public account, and the CISA-ADP vector includes required user interaction, but the renderer-compromise prerequisite prevents the description from being shortened to “open a page and lose the Mac.”A more accurate sequence is:
- The attacker obtains a capability that compromises the renderer.
- A crafted HTML page participates in reaching or triggering the USB use-after-free condition.
- CVE-2026-13880 may then allow the attacker to escape the renderer sandbox.
Analysis: Layered defenses may reduce exposure to hostile content, but the supplied facts do not establish the specific effectiveness of URL filtering, remote browser isolation, endpoint prevention, or other compensating controls against this vulnerability. Such controls should not be presented as substitutes for reaching the documented version boundary.
This is also why the CISA-ADP SSVC options should be read together. “Exploitation: none” addresses identified exploitation at the time of assessment. “Automatable: no” addresses expected automation. “Technical impact: total” describes the modeled severity of a successful outcome. These are separate judgments, not contradictions.
Version 150.0.7871.47 Is the Operational Line
The affected-version range is the most actionable element in the record. Google Chrome versions before 150.0.7871.47 on macOS are included in the affected configuration. Administrators should compare the complete four-part version rather than checking only the major release number.A Mac reporting “Chrome 150” is not necessarily compliant. The relevant comparison is against the full value:
150.0.7871.47For an individual user, the verification procedure is direct:
- Open Google Chrome.
- Select the Chrome menu.
- Choose Help.
- Select About Google Chrome.
- Allow Chrome to check for and apply the available update.
- Click Relaunch.
- Return to About Google Chrome.
- Confirm that the displayed running version is 150.0.7871.47 or later.
Administrators should also identify policy conditions that prevent systems from reaching that boundary. Examples include intentionally pinned versions, maintenance exclusions, offline systems, unmanaged Macs, and approved deferral groups. These are general inventory considerations, not evidence of any particular Chrome update failure.
Compact Remediation and Verification Plan
| Phase | Required action | Evidence of completion |
|---|---|---|
| Discover | Find Google Chrome installations on macOS | Asset list containing device, owner, OS, and full Chrome version |
| Prioritize | Isolate versions below 150.0.7871.47 | Remediation group limited to affected Mac installations |
| Update | Apply the organization’s approved Chrome update | Successful update action or confirmed user-assisted update |
| Activate | Relaunch Chrome | Browser process restarted after update |
| Verify | Check the running four-part version | Chrome reports 150.0.7871.47 or later |
| Reconcile | Review systems still below the boundary | Named list of offline devices, failures, exclusions, or exceptions |
| Close | Record platform-specific compliance | Evidence tied to Chrome on macOS rather than fleet-wide Chrome averages |
Record Timeline Without Unsupported Field-Level Claims
CVE records are assembled through submissions, assessments, enrichment, and later modifications. The supplied material supports the following sequence without requiring unsupported assertions about each field-level edit.Timeline
Initial Chrome-originated submission — The vulnerability entered the record with a description identifying a USB use-after-free in Google Chrome on Mac, the renderer-compromise prerequisite, the crafted HTML page, and the affected-version boundary below 150.0.7871.47.NVD publication — The National Vulnerability Database published the CVE record and identified Chrome as the source of the vulnerability description.
CISA-ADP assessment — CISA-ADP supplied a CVSS 3.1 vector producing a 9.6 CRITICAL score. It also supplied SSVC options stating exploitation was none, automation was no, and technical impact was total.
NIST enrichment — NIST added an affected-product configuration associating vulnerable Google Chrome versions with Apple macOS. It also classified the Chrome reference as a vendor-advisory reference and the restricted Chromium link as an issue-tracking reference.
Subsequent modification — The record received an additional CISA-ADP modification after the initial assessment and enrichment activity.
This timeline explains why products ingesting the record at different points may display different combinations of severity, platform, reference, and decision-support information. It does not establish that a specific modification removed or restored CWE-416, nor does it justify attributing every individual field to a particular change without the complete change record.
Restricted Bug Details Demand Restraint
The NVD record includes a reference classified as a vendor advisory and a separate Chromium issue-tracking reference requiring permission. The supplied excerpt establishes those reference classifications, but it does not establish the full contents of the vendor page or independently demonstrate that a particular build was described there as a shipped fix.The supported operational statement is more precise: the affected configuration ends before 150.0.7871.47, making that build the documented version boundary for exposure assessment.
The restricted issue tracker limits responsible technical analysis. The public sources do not establish:
- The vulnerable class or function.
- The precise object-lifetime sequence.
- The page operations needed to reach the flaw.
- Whether a race condition is involved.
- Exploit reliability.
- Required heap manipulation.
- Additional mitigation bypasses.
- Patch mechanics.
- Validated indicators of compromise.
The same standard applies to impact. CISA-ADP’s high confidentiality, integrity, and availability metrics and “technical impact: total” option are modeled assessment results. They are not evidence that attackers have produced each outcome in real incidents.
Similarly, a Chrome crash is not proof of exploitation. The supplied information includes no validated crash signature, malicious domain, file hash, process pattern, or other indicator specific to this CVE. Version-based exposure identification is therefore the primary reliable control available from the record.
What WindowsForum Administrators Should Report
A concise internal advisory can avoid both alarmism and understatement:That wording retains the prerequisite, platform boundary, scoring provenance, exploitation status, and remediation requirement. It avoids calling the score a NIST verdict, claiming Windows exposure, or presenting modeled consequences as observed incidents.
The Practical Bottom Line
CVE-2026-13880 is serious because it may help an attacker cross a major browser containment boundary. It is constrained because the public description requires a renderer compromise first. Both statements belong in any accurate assessment.The difference between Chromium’s Medium classification and CISA-ADP’s 9.6 CRITICAL score is not a reason to delay remediation while analysts debate which label is more persuasive. It is a reminder that vendor severity, CVSS impact modeling, SSVC decision data, and NVD enrichment answer different questions.
For defenders, the operational decision does not require inaccessible exploit details. Find Google Chrome on macOS, identify versions below 150.0.7871.47, update them, relaunch the browser, and verify the running version. Do not widen the affected scope to Windows, Linux, other browsers, or macOS itself without separate evidence.
Future record changes may refine the scoring, references, configuration, or technical description. They may also expose more of the underlying Chromium analysis once disclosure restrictions change. Until then, administrators should anchor their response to the source-proven facts: a Mac-specific Chrome version boundary, a renderer-compromise prerequisite, a potential sandbox escape, and a clear verification target of 150.0.7871.47 or later.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:39:39-07:00
NVD - CVE-2026-13880
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:39:39-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
