Affected: Chrome on macOS before 150.0.7871.47. Action: update Chrome for Mac to 150.0.7871.47 or later. Current record: crafted HTML page plus specific UI gestures; potential sandbox escape; CVSS 9.6 Critical. This scope is important: CVE-2026-13785 is currently published as affecting Chrome on macOS before version 150.0.7871.47. The available record does not place Chrome on Windows within the affected range, so neither the headline nor the response should imply a Windows Chrome exposure.
Google addressed CVE-2026-13785 in Chrome for Mac version 150.0.7871.47. According to the Chrome-sourced description carried by the National Vulnerability Database, the vulnerability is a use-after-free flaw in Chrome’s Bluetooth component. A remote attacker could convince a user to perform specific interface gestures on a crafted HTML page and potentially escape the browser sandbox.
The direct remediation is to update affected Chrome for Mac installations to 150.0.7871.47 or later. The supplied CVE material establishes that fixed-version boundary but does not document Chrome’s update interface, update-check behavior, restart behavior, or other product-specific update procedures. Users and administrators should therefore follow their organization’s approved process or current Google Chrome documentation to deploy the corrected version.
The differentiating operational issue for Windows-centric organizations is not Windows Chrome exposure. It is whether the teams responsible for vulnerability management can locate and update all managed Macs. A company may operate primarily on Windows while still maintaining MacBooks for executives, developers, designers, contractors, or specialist teams. Those systems must not disappear from the response merely because they represent a small part of the endpoint fleet.
A short Mac-focused response is sufficient:
This table should be applied to Chrome on macOS, not extended automatically to other operating systems. Windows and Linux Chrome installations should continue to receive normal security maintenance, but the supplied record does not support labeling them vulnerable to CVE-2026-13785.
The word “Bluetooth” should not be used to broaden the product scope. The published description identifies a flaw in Chrome’s Bluetooth component and the affected configuration lists Chrome on macOS. The published description only establishes a crafted HTML page plus specific user-interface gestures. It does not provide enough detail to redefine this as a general Bluetooth-platform vulnerability or to attribute it to every Bluetooth-capable application.
The supported remediation is reaching the corrected Chrome version. The CVE material does not establish disabling Bluetooth, disconnecting peripherals, changing radio settings, or unpairing devices as substitutes for updating Chrome. Organizations may impose temporary controls under their own risk-management policies, but those controls should not be represented as the documented fix for this vulnerability.
The published description only establishes a crafted HTML page plus specific user-interface gestures. It does not disclose what the page contains, which gestures are required, how the vulnerable state is reached, or what the user would see while interacting with the page.
The accessible material also does not provide:
The CVSS vector records user interaction as required through
Security messaging can continue to reinforce normal caution around unexpected websites and prompts, but such advice is not a replacement for updating. Without details about the necessary gestures, organizations cannot reliably convert the CVE description into a precise user-awareness rule.
The public record does not provide the vulnerable object, the memory-reuse sequence, or a complete exploit chain. Defenders should therefore avoid presenting hypothetical heap manipulation, code execution, privilege escalation, or post-exploitation activity as confirmed behavior for this CVE.
The available facts are serious without that speculation. A browser sandbox is intended to constrain code handling untrusted web content. A potential sandbox escape concerns the crossing of that containment boundary, which raises the consequence beyond an ordinary browser error or isolated tab failure.
The qualification “potentially” remains important. The description does not establish that every trigger succeeds, that each successful trigger produces the same result, or that an attacker automatically receives complete control of the Mac. It also does not specify whether additional conditions or exploit stages are necessary.
The appropriate conclusion is direct: the 9.6 Critical CVSS score, required user interaction represented by UI:R, and potential sandbox escape make prompt deployment of the fixed Chrome version the prudent response.
At a high level, the vector describes a network-delivered scenario assessed as low complexity, requiring no prior attacker privileges but requiring user interaction. It also reflects a scope change and high potential effects on confidentiality, integrity, and availability.
CVSS describes technical severity. It does not, by itself, establish the availability of public exploit code, the existence of an active campaign, the number of vulnerable systems, or the probability that exploitation will succeed in a particular environment. Organizations should combine severity with their own Mac inventory and deployment status rather than treating the numeric score as proof of observed attacks.
The supplied SSVC record lists exploitation as none, automatable as no, and technical impact as total; those values should be reported as the record’s assessment, not expanded into a claim that exploitation has been conclusively ruled out everywhere.
The absence of reported exploitation in that supplied field does not reduce the version-remediation requirement. The fixed boundary is concrete, the potential impact is serious, and the affected browser is exposed to untrusted web content as part of its normal function.
The inventory should include, as applicable:
Administrators should use the inventory and software-deployment capabilities already approved for their environment. The CVE record does not prescribe a universal console query, command, status field, or evidence format. Product-specific instructions should come from the applicable browser-management or endpoint-management documentation rather than being inferred from the vulnerability description.
Prioritization should focus on confirmed affected versions and unresolved visibility:
Teams should also avoid assumptions about which users are most likely to encounter the vulnerability. The supplied record does not establish that developers, executives, administrators, designers, or any other group is specifically targeted. Device ownership may influence operational priority, but it should not be presented as a CVE-specific attack fact.
General browser activity should not be relabeled as evidence for this vulnerability. A browser crash, unfamiliar website, unexpected prompt, or Bluetooth-related event may justify investigation in context, but none is established by the supplied record as an indicator of CVE-2026-13785 exploitation.
This limitation makes preventive remediation especially important. Version inventory can determine whether a Chrome for Mac installation is within the listed affected range even when the public record cannot determine whether that installation was previously exposed to a malicious page.
If an organization has independent evidence of suspicious browser activity or targeted web content, it should use its normal incident-response process. Relevant work may include preserving available browser and endpoint evidence, reviewing network and identity telemetry, identifying other affected devices, and determining whether activity continued beyond the browser. Those are general incident-response actions, not detection steps uniquely specified for this CVE.
The CVE record can support three parts of an investigation:
For remediation tracking, the version boundary is more important than reconstructing an unsupported disclosure chronology. An installation below the threshold requires an update; an installation at or above it is outside the current record’s listed affected range.
This format keeps the report tied to the available facts. It avoids mixing the vulnerability’s product scope with broader Chrome maintenance, avoids claiming that unknown devices are confirmed vulnerable, and avoids implying that a severity score proves active exploitation.
Where an organization maintains exceptions, each exception should identify the affected Mac, its last confirmed Chrome version, the reason deployment has not completed, the responsible owner, and a review date. Those are administrative controls rather than facts supplied by the CVE record, but they can help prevent confirmed affected installations from being lost after the initial advisory cycle.
That leaves administrators with a concrete response. Find the Macs, determine which ones run Chrome, update versions below 150.0.7871.47, and confirm the corrected installed version. Do not broaden the advisory into an unsupported Windows Chrome warning, and do not replace the fixed-version boundary with speculative Bluetooth controls or detection claims.
For Windows-centric organizations, the lasting lesson is straightforward: a macOS-specific vulnerability can still belong to the central Windows-oriented security team when that team owns enterprise inventory and patch accountability. Accurate platform scope and complete visibility are complementary goals. Keep the CVE limited to the product identified by the record, while ensuring that every managed Mac remains visible enough to receive the fix.
Update Chrome for Mac Now
Google addressed CVE-2026-13785 in Chrome for Mac version 150.0.7871.47. According to the Chrome-sourced description carried by the National Vulnerability Database, the vulnerability is a use-after-free flaw in Chrome’s Bluetooth component. A remote attacker could convince a user to perform specific interface gestures on a crafted HTML page and potentially escape the browser sandbox.The direct remediation is to update affected Chrome for Mac installations to 150.0.7871.47 or later. The supplied CVE material establishes that fixed-version boundary but does not document Chrome’s update interface, update-check behavior, restart behavior, or other product-specific update procedures. Users and administrators should therefore follow their organization’s approved process or current Google Chrome documentation to deploy the corrected version.
The differentiating operational issue for Windows-centric organizations is not Windows Chrome exposure. It is whether the teams responsible for vulnerability management can locate and update all managed Macs. A company may operate primarily on Windows while still maintaining MacBooks for executives, developers, designers, contractors, or specialist teams. Those systems must not disappear from the response merely because they represent a small part of the endpoint fleet.
A short Mac-focused response is sufficient:
- Enumerate managed and authorized macOS endpoints.
- Determine which Macs have Google Chrome installed.
- Identify Chrome versions earlier than 150.0.7871.47.
- Update those installations to 150.0.7871.47 or later.
- Confirm through an approved inventory or verification method that the corrected version is installed.
- Investigate Macs whose Chrome version remains unknown.
Affected Scope and Version Boundary
The current NVD record lists Google Chrome on Apple macOS before version 150.0.7871.47 as affected. Based on that published scope, Chrome on Mac at version 150.0.7871.47 or later is outside the listed affected range.| Deployment state | Chrome on Mac version | CVE status | Required response |
|---|---|---|---|
| Below the fixed threshold | Earlier than 150.0.7871.47 | Within the affected range | Update to 150.0.7871.47 or later |
| Fixed threshold reached | 150.0.7871.47 or later | Outside the listed affected range | Record the corrected version |
| Version unknown | Not verified | Exposure unresolved | Obtain current inventory or direct version confirmation |
| Chrome not installed | Not applicable | No affected Chrome installation identified | Document the inventory result |
The word “Bluetooth” should not be used to broaden the product scope. The published description identifies a flaw in Chrome’s Bluetooth component and the affected configuration lists Chrome on macOS. The published description only establishes a crafted HTML page plus specific user-interface gestures. It does not provide enough detail to redefine this as a general Bluetooth-platform vulnerability or to attribute it to every Bluetooth-capable application.
The supported remediation is reaching the corrected Chrome version. The CVE material does not establish disabling Bluetooth, disconnecting peripherals, changing radio settings, or unpairing devices as substitutes for updating Chrome. Organizations may impose temporary controls under their own risk-management policies, but those controls should not be represented as the documented fix for this vulnerability.
Attack Condition: A Crafted Page and Required User Interaction
The CVE record describes a remote attacker convincing a user to perform specific interface gestures on a crafted HTML page. That wording establishes two important conditions: delivery through crafted web content and a requirement for user interaction.The published description only establishes a crafted HTML page plus specific user-interface gestures. It does not disclose what the page contains, which gestures are required, how the vulnerable state is reached, or what the user would see while interacting with the page.
The accessible material also does not provide:
- The HTML, script, or browser-state requirements needed to trigger the flaw.
- The exact user-interface gestures involved.
- A public proof of concept.
- A malicious domain, URL, file hash, or network signature.
- A browser or endpoint artifact specific to successful exploitation.
- The privileges obtained after a potential sandbox escape.
- A complete sequence connecting the initial browser interaction to later system activity.
The CVSS vector records user interaction as required through
UI:R. That is an attack characteristic, not a compensating control. People routinely interact with web pages, and the public material does not identify a distinctive action that employees can be trained to avoid specifically for CVE-2026-13785.Security messaging can continue to reinforce normal caution around unexpected websites and prompts, but such advice is not a replacement for updating. Without details about the necessary gestures, organizations cannot reliably convert the CVE description into a precise user-awareness rule.
Why the Vulnerability Is Urgent
CVE-2026-13785 is classified as CWE-416, Use After Free, in Chrome’s Bluetooth component. The classification identifies a memory-lifetime flaw, while the Chrome-sourced description identifies potential escape from the browser sandbox as the relevant outcome.The public record does not provide the vulnerable object, the memory-reuse sequence, or a complete exploit chain. Defenders should therefore avoid presenting hypothetical heap manipulation, code execution, privilege escalation, or post-exploitation activity as confirmed behavior for this CVE.
The available facts are serious without that speculation. A browser sandbox is intended to constrain code handling untrusted web content. A potential sandbox escape concerns the crossing of that containment boundary, which raises the consequence beyond an ordinary browser error or isolated tab failure.
The qualification “potentially” remains important. The description does not establish that every trigger succeeds, that each successful trigger produces the same result, or that an attacker automatically receives complete control of the Mac. It also does not specify whether additional conditions or exploit stages are necessary.
The appropriate conclusion is direct: the 9.6 Critical CVSS score, required user interaction represented by UI:R, and potential sandbox escape make prompt deployment of the fixed Chrome version the prudent response.
Reading the Severity Information Carefully
NIST’s National Vulnerability Database and CISA-ADP display a CVSS 3.1 score of 9.6, rated Critical, with the following vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:HAt a high level, the vector describes a network-delivered scenario assessed as low complexity, requiring no prior attacker privileges but requiring user interaction. It also reflects a scope change and high potential effects on confidentiality, integrity, and availability.
CVSS describes technical severity. It does not, by itself, establish the availability of public exploit code, the existence of an active campaign, the number of vulnerable systems, or the probability that exploitation will succeed in a particular environment. Organizations should combine severity with their own Mac inventory and deployment status rather than treating the numeric score as proof of observed attacks.
The supplied SSVC record lists exploitation as none, automatable as no, and technical impact as total; those values should be reported as the record’s assessment, not expanded into a claim that exploitation has been conclusively ruled out everywhere.
The absence of reported exploitation in that supplied field does not reduce the version-remediation requirement. The fixed boundary is concrete, the potential impact is serious, and the affected browser is exposed to untrusted web content as part of its normal function.
What Windows-Centric Administrators Should Inventory
Although the affected product is Chrome on macOS, remediation may fall to a security or infrastructure team whose primary tools, policies, and reporting processes are Windows-centered. The response should begin with locating the organization’s Macs, not with scanning Windows Chrome installations for a macOS-only affected range.The inventory should include, as applicable:
- Corporate-owned Macs enrolled in endpoint management.
- Developer or engineering Macs maintained through separate tooling.
- Executive, design, media, laboratory, and specialist systems.
- Contractor Macs authorized to access organizational resources.
- Macs recorded in identity, access, or device-compliance systems.
- Authorized Macs known to support teams but absent from the main endpoint console.
Administrators should use the inventory and software-deployment capabilities already approved for their environment. The CVE record does not prescribe a universal console query, command, status field, or evidence format. Product-specific instructions should come from the applicable browser-management or endpoint-management documentation rather than being inferred from the vulnerability description.
Prioritization should focus on confirmed affected versions and unresolved visibility:
- Confirmed affected: A Mac reports Chrome earlier than 150.0.7871.47.
- Confirmed corrected: A Mac reports Chrome 150.0.7871.47 or later.
- Not applicable: The Mac does not have Chrome installed.
- Unknown: The organization cannot currently establish whether Chrome is installed or which version is present.
Teams should also avoid assumptions about which users are most likely to encounter the vulnerability. The supplied record does not establish that developers, executives, administrators, designers, or any other group is specifically targeted. Device ownership may influence operational priority, but it should not be presented as a CVE-specific attack fact.
Detection Limits and Incident Handling
The supplied public material contains no CVE-specific indicators of compromise or detection logic. It does not provide malicious URLs, file hashes, network signatures, browser artifacts, endpoint events, process relationships, or other observables that independently identify exploitation of CVE-2026-13785.General browser activity should not be relabeled as evidence for this vulnerability. A browser crash, unfamiliar website, unexpected prompt, or Bluetooth-related event may justify investigation in context, but none is established by the supplied record as an indicator of CVE-2026-13785 exploitation.
This limitation makes preventive remediation especially important. Version inventory can determine whether a Chrome for Mac installation is within the listed affected range even when the public record cannot determine whether that installation was previously exposed to a malicious page.
If an organization has independent evidence of suspicious browser activity or targeted web content, it should use its normal incident-response process. Relevant work may include preserving available browser and endpoint evidence, reviewing network and identity telemetry, identifying other affected devices, and determining whether activity continued beyond the browser. Those are general incident-response actions, not detection steps uniquely specified for this CVE.
The CVE record can support three parts of an investigation:
- Establishing whether the Mac was running an affected Chrome version.
- Describing the publicly documented crafted-page and user-interaction conditions.
- Communicating the potential seriousness of a sandbox escape.
Concise Remediation Timeline
The record can be summarized without inferring unsupported publication events or dates:- The CVE record describes a use-after-free vulnerability in Chrome’s Bluetooth component on Mac, involving a crafted HTML page, specific interface gestures, and a potential browser sandbox escape.
- The current NVD record lists Google Chrome on Apple macOS before version 150.0.7871.47 as affected.
- NVD and CISA-ADP display a CVSS 3.1 score of 9.6 with a Critical rating.
- The operational threshold is Chrome for Mac 150.0.7871.47 or later.
For remediation tracking, the version boundary is more important than reconstructing an unsupported disclosure chronology. An installation below the threshold requires an update; an installation at or above it is outside the current record’s listed affected range.
Action Checklist for Administrators
- [ ] Enumerate managed and authorized macOS endpoints.
- [ ] Include Macs owned by teams whose primary endpoint environment is Windows.
- [ ] Determine which Macs have Google Chrome installed.
- [ ] Identify Chrome for Mac versions earlier than 150.0.7871.47.
- [ ] Update affected installations to 150.0.7871.47 or later using an approved method.
- [ ] Confirm the corrected installed version through an approved inventory or verification method.
- [ ] Follow up on Macs whose Chrome installation or version cannot be established.
- [ ] Keep Chrome on Windows, Linux, Android, and ChromeOS out of this CVE’s affected inventory unless separate authoritative information expands the scope.
- [ ] Do not present Bluetooth shutdown, peripheral disconnection, unpairing, or radio changes as substitutes for the Chrome update.
- [ ] Do not claim knowledge of the exact crafted page or required gestures beyond the published description.
- [ ] Do not present ordinary browser or Bluetooth events as CVE-specific indicators.
- [ ] Use normal incident-response procedures if independent evidence suggests malicious browser activity.
- [ ] Record completion when Chrome for Mac is confirmed at 150.0.7871.47 or later.
Administrator Reporting Template
A concise internal report can communicate the result without overstating the evidence:| Reporting field | Recommended entry |
|---|---|
| Vulnerability | CVE-2026-13785 |
| Affected product | Google Chrome on Apple macOS |
| Affected versions | Earlier than 150.0.7871.47 |
| Remediation target | 150.0.7871.47 or later |
| Published attack condition | Crafted HTML page plus specific user-interface gestures |
| Published potential outcome | Browser sandbox escape |
| Severity | CVSS 3.1 score 9.6, Critical |
| Windows Chrome status | Not included in the current published affected range |
| Detection status | No CVE-specific indicators supplied in the available record |
| Fleet status | Count of affected, corrected, not-applicable, and unknown Macs |
Where an organization maintains exceptions, each exception should identify the affected Mac, its last confirmed Chrome version, the reason deployment has not completed, the responsible owner, and a review date. Those are administrative controls rather than facts supplied by the CVE record, but they can help prevent confirmed affected installations from being lost after the initial advisory cycle.
What Defenders Should Carry Forward
The established facts support prompt and narrowly scoped remediation:- CVE-2026-13785 affects Google Chrome on macOS before version 150.0.7871.47.
- The current record does not place Chrome on Windows within the affected range.
- The vulnerability is classified as a CWE-416 use-after-free in Chrome’s Bluetooth component.
- The published description establishes a crafted HTML page plus specific user-interface gestures.
- Successful exploitation could potentially escape the browser sandbox.
- NIST NVD and CISA-ADP display a 9.6 Critical CVSS 3.1 score.
- The supplied SSVC values are exploitation none, automatable no, and technical impact total.
- The supplied record provides no exploit indicators or CVE-specific detection logic.
- The remediation target is Chrome for Mac 150.0.7871.47 or later.
That leaves administrators with a concrete response. Find the Macs, determine which ones run Chrome, update versions below 150.0.7871.47, and confirm the corrected installed version. Do not broaden the advisory into an unsupported Windows Chrome warning, and do not replace the fixed-version boundary with speculative Bluetooth controls or detection claims.
For Windows-centric organizations, the lasting lesson is straightforward: a macOS-specific vulnerability can still belong to the central Windows-oriented security team when that team owns enterprise inventory and patch accountability. Accurate platform scope and complete visibility are complementary goals. Keep the CVE limited to the product identified by the record, while ensuring that every managed Mac remains visible enough to receive the fix.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:39:28-07:00
NVD - CVE-2026-13785
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:39:28-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-13785 - Google Chrome Use-after-free Sandbox Escape
Use after free in Bluetooth in Google Chrome on Mac prior to 150.0.7871.47 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)cvefeed.io - Related coverage: chromium.googlesource.com
- Related coverage: issues.chromium.org
Chromium
issues.chromium.org
