CVE-2026-14385 is a High-severity heap buffer overflow in Google Chrome that the supplied record documents on macOS before version 150.0.7871.46. The Chrome-originated description says a remote attacker could use a crafted HTML page to cause out-of-bounds memory access. CISA-ADP assigned a CVSS 3.1 score of 8.8, with user interaction required and no prior privileges required. The immediate response is clear: update affected Macs to Google Chrome 150.0.7871.46 or later, relaunch Chrome, and verify the complete version number.
That version boundary is the remediation test established by the available evidence. It does not establish when the corrected release first became available, whether 150.0.7871.46 was an initial Chrome 150 desktop build, or how the release was promoted across operating systems.
The scope boundary is equally important: the supplied record documents Google Chrome on macOS. It does not establish that Microsoft Edge, Chrome on Windows, Chrome on Linux, or every Chromium-derived browser is affected by CVE-2026-14385. Those products should be evaluated through their own vendor advisories rather than being added to this CVE by assumption.
The vulnerability warrants prompt patching, but the record does not show that attacks are underway. More precisely, the CISA-ADP SSVC exploitation field was recorded as “none” at
Mac users should complete the update and confirm the result rather than relying on a notification that an update is available.
If Chrome still displays a version earlier than 150.0.7871.46 after the update attempt and relaunch, the Mac remains inside the affected range documented for this CVE. On an organization-managed device, the user should contact the responsible support or security team rather than attempting to bypass management controls.
This procedure is directed at Mac users because macOS is the platform documented in the supplied vulnerability record. Windows users should continue following normal browser-update requirements, but they should not treat this Mac-specific procedure as proof that their Windows installation is affected by CVE-2026-14385.
That wording establishes several useful facts:
Those outcomes should not be inserted into the article merely because memory-corruption vulnerabilities can sometimes lead to broader consequences. The accurate description is the one the record supports: crafted HTML could trigger out-of-bounds memory access in an affected Chrome installation.
The associated Chromium issue is permission-restricted. That fact limits public technical analysis, but the supplied material does not establish why access is restricted, how long the restriction will continue, or which disclosure policy applies. Administrators do not need those missing details to apply the version-based remediation.
Being outside this CVE’s documented affected range is not a general certificate that the browser contains no other security defects. The table answers only whether an installation has crossed the version boundary supplied for CVE-2026-14385.
Administrators should also avoid copying Chrome’s version number into compliance rules for Edge or another browser. Different products use their own release and version schemes. Even when products share upstream technology, the Chrome version threshold does not automatically become the correct threshold for another vendor’s browser.
The supplied evidence does not identify Microsoft Edge as affected. It does not identify Google Chrome on Windows as affected. It does not establish that Brave, Opera, Vivaldi, or another Chromium-derived product contains the same vulnerable condition in a corresponding release.
Shared code may justify investigation, but it is not enough to establish affected-product status. Vendors can incorporate code at different points, apply different patches, enable different configurations, and use unrelated product version numbers. A vulnerability finding should therefore preserve the product, platform, and version conditions given in the underlying record.
For Windows administrators, the correct inventory question is:
This does not make the vulnerability irrelevant to Windows-focused organizations. Many Windows-centered IT teams also administer Macs used by executives, developers, designers, contractors, or other employees. The lesson is to find those Macs without mislabeling unrelated Windows endpoints.
That vector describes the vulnerability’s assessed technical characteristics and potential impact:
CVSS also should not be presented as evidence of active exploitation. It describes technical severity under a standardized model. Whether attacks have been observed is a separate question.
The relevant CISA-ADP SSVC contribution lists:
The field does not prove that exploitation is impossible, and it should not be treated as a permanent status. At the same time, the available evidence does not justify claims about active attacks, exploit kits, private proofs of concept, or attackers developing an exploit from source or binary comparisons.
“Automatable: no” should likewise remain an attributed SSVC selection. The supplied information does not support a detailed account of how malicious content might be delivered or scaled.
“Technical impact: total” helps explain the urgency of remediation, but it does not broaden the documented outcome beyond the public description or broaden the platform scope beyond Chrome on macOS.
Taken together, the available assessment supports a measured conclusion: this is a technically serious browser vulnerability with no exploitation identified in the dated SSVC record. Patch promptly, but do not declare that affected Macs are already compromised solely because their Chrome version falls inside the vulnerable range.
The taxonomy does not change the operational answer. Administrators do not need to resolve which weakness label is more descriptive before acting. The product, platform, and version boundary are sufficient:
Chrome-originated disclosure stage — Chrome supplied the core vulnerability description, including the heap buffer overflow, crafted-HTML condition, macOS scope, and affected-version boundary.
CISA-ADP enrichment stage — CISA-ADP contributed the CVSS 3.1 score of 8.8 HIGH and the associated vector.
Dated SSVC assessment — At
NIST affected-product analysis stage — The affected configuration associated the vulnerable Chrome range with Apple macOS and placed 150.0.7871.46 outside the affected range.
Current remediation stage — An in-scope Mac remains unresolved until Google Chrome reports version 150.0.7871.46 or later.
This staged view preserves the provenance of the record without assigning an unsupported release date to the corrected Chrome build. It also prevents fields supplied by Chrome, CISA-ADP, and NIST from being flattened into a single unattributed assessment.
For an individual Mac user, the acceptance criterion is visible and specific:
Similarly, fleet teams may use deployment status, application inventory, endpoint queries, or local checks as part of their normal operations. The vulnerability record does not prescribe a particular management product, telemetry system, installation type, or update schedule. Those are implementation choices.
The universal closure condition is simpler: obtain trustworthy evidence that the in-scope Chrome installation reports version 150.0.7871.46 or later.
A missing, stale, truncated, or major-version-only result should remain unresolved. “Chrome 150” is insufficient because it does not prove that the browser is at or above 150.0.7871.46.
Organizations may already use endpoint security, web filtering, application controls, least privilege, or isolated administrative workflows. Those measures can remain useful parts of a broader defensive program, but they should not be presented as CVE-specific remediation unless supporting evidence becomes available.
Likewise, the absence of identified exploitation in the dated SSVC record is not a compensating control. It supplies prioritization context; it does not move an old Chrome installation outside the affected range.
The reliable response established here is version based:
Removing the macOS qualifier creates unsupported Windows and Edge findings. Reporting only “Chrome 150” loses the fixed-build precision. Calling the CISA-ADP score an NVD score loses attribution. Turning a dated SSVC field into “CISA certified no exploitation” overstates what the record says. Turning out-of-bounds memory access into proven system compromise overstates the documented consequence.
The accurate alert is narrower:
The forward-looking task is to continue monitoring authoritative product and vulnerability information for a changed exploitation assessment, expanded affected-product scope, or additional technical guidance. If Microsoft or another browser vendor later identifies a corresponding issue, that advisory should be handled using that vendor’s own affected versions and remediation boundary.
Until then, keep this finding disciplined: patch Google Chrome on affected Macs, verify the full version after relaunch, and do not extrapolate CVE-2026-14385 to Edge, Windows, Linux, or every Chromium browser without supporting evidence.
That version boundary is the remediation test established by the available evidence. It does not establish when the corrected release first became available, whether 150.0.7871.46 was an initial Chrome 150 desktop build, or how the release was promoted across operating systems.
The scope boundary is equally important: the supplied record documents Google Chrome on macOS. It does not establish that Microsoft Edge, Chrome on Windows, Chrome on Linux, or every Chromium-derived browser is affected by CVE-2026-14385. Those products should be evaluated through their own vendor advisories rather than being added to this CVE by assumption.
The vulnerability warrants prompt patching, but the record does not show that attacks are underway. More precisely, the CISA-ADP SSVC exploitation field was recorded as “none” at
2026-07-02T13:11:12.204696Z. That is a dated assessment field, not an independent certification by CISA that exploitation had never occurred or could not occur later.
Update Chrome on an Affected Mac
Mac users should complete the update and confirm the result rather than relying on a notification that an update is available.- Open Google Chrome.
- Select the three-dot Chrome menu in the upper-right corner.
- Select Help.
- Select About Google Chrome.
- Allow Chrome to complete its update check.
- If Chrome presents a Relaunch button, select it.
- After Chrome reopens, return to Chrome menu → Help → About Google Chrome.
- Confirm that the complete displayed version is 150.0.7871.46 or later.
If Chrome still displays a version earlier than 150.0.7871.46 after the update attempt and relaunch, the Mac remains inside the affected range documented for this CVE. On an organization-managed device, the user should contact the responsible support or security team rather than attempting to bypass management controls.
This procedure is directed at Mac users because macOS is the platform documented in the supplied vulnerability record. Windows users should continue following normal browser-update requirements, but they should not treat this Mac-specific procedure as proof that their Windows installation is affected by CVE-2026-14385.
The Record Establishes a Narrow but Serious Browser Flaw
According to the Chrome-originated description, CVE-2026-14385 is a heap buffer overflow that could allow a remote attacker to cause out-of-bounds memory access through a crafted HTML page.That wording establishes several useful facts:
- The named product is Google Chrome.
- The documented platform scope is macOS.
- The affected range ends before 150.0.7871.46.
- Attacker-controlled HTML is the documented input.
- The attacker does not require prior privileges.
- User interaction is required.
- The documented technical result is out-of-bounds memory access.
Those outcomes should not be inserted into the article merely because memory-corruption vulnerabilities can sometimes lead to broader consequences. The accurate description is the one the record supports: crafted HTML could trigger out-of-bounds memory access in an affected Chrome installation.
The associated Chromium issue is permission-restricted. That fact limits public technical analysis, but the supplied material does not establish why access is restricted, how long the restriction will continue, or which disclosure policy applies. Administrators do not need those missing details to apply the version-based remediation.
Version 150.0.7871.46 Is the Operational Boundary
The affected-version rule is straightforward: Google Chrome on macOS before 150.0.7871.46 is inside the range documented for CVE-2026-14385. Version 150.0.7871.46 or later crosses the supplied remediation threshold.| Product and platform state | Status in the supplied record | Required response |
|---|---|---|
| Google Chrome on macOS earlier than 150.0.7871.46 | Documented as affected | Update, relaunch, and verify the complete version |
| Google Chrome on macOS 150.0.7871.46 or later | Outside the documented affected range | Record the verified version and continue normal update enforcement |
| Google Chrome on Windows | Not identified as affected | Do not create a CVE-specific finding from this record alone |
| Google Chrome on Linux | Not identified as affected | Do not extrapolate the macOS finding |
| Microsoft Edge | Not identified as affected | Obtain Edge-specific evidence from Microsoft |
| Other Chromium-derived browsers | Not established | Evaluate each browser using product-specific vendor information |
Administrators should also avoid copying Chrome’s version number into compliance rules for Edge or another browser. Different products use their own release and version schemes. Even when products share upstream technology, the Chrome version threshold does not automatically become the correct threshold for another vendor’s browser.
Do Not Turn Shared Chromium Code Into Unsupported Scope
The strongest reporting discipline in this case is refusing to convert a Chrome-on-macOS record into an all-Chromium or all-platform warning.The supplied evidence does not identify Microsoft Edge as affected. It does not identify Google Chrome on Windows as affected. It does not establish that Brave, Opera, Vivaldi, or another Chromium-derived product contains the same vulnerable condition in a corresponding release.
Shared code may justify investigation, but it is not enough to establish affected-product status. Vendors can incorporate code at different points, apply different patches, enable different configurations, and use unrelated product version numbers. A vulnerability finding should therefore preserve the product, platform, and version conditions given in the underlying record.
For Windows administrators, the correct inventory question is:
It is not:
The first question finds the population supported by the supplied evidence. The second can create false-positive tickets for Windows systems and other browsers while distracting attention from the Macs that actually fall inside the documented configuration.
This does not make the vulnerability irrelevant to Windows-focused organizations. Many Windows-centered IT teams also administer Macs used by executives, developers, designers, contractors, or other employees. The lesson is to find those Macs without mislabeling unrelated Windows endpoints.
Severity and Exploitation Need Separate Interpretation
CISA-ADP assigned CVE-2026-14385 a CVSS 3.1 base score of 8.8 HIGH using the vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HThat vector describes the vulnerability’s assessed technical characteristics and potential impact:
- AV:N — Network attack vector: The vulnerable path can be reached through network-delivered content.
- AC:L — Low attack complexity: The CVSS assessment does not depend on unusually specific conditions outside the attacker’s control.
- PR:N — No privileges required: The attacker does not need an existing account or prior permissions on the target.
- UI:R — User interaction required: The target must interact with attacker-controlled content.
- S:U — Scope unchanged: The CVSS calculation records unchanged scope. This should not be rewritten as a guarantee about every Chrome or operating-system containment boundary.
- C:H/I:H/A:H — High potential impact: The assessment assigns high potential effects to confidentiality, integrity, and availability.
CVSS also should not be presented as evidence of active exploitation. It describes technical severity under a standardized model. Whether attacks have been observed is a separate question.
The relevant CISA-ADP SSVC contribution lists:
- Exploitation: none
- Automatable: no
- Technical impact: total
2026-07-02T13:11:12.204696Z. The careful wording is that the SSVC exploitation field was “none” at that timestamp. “CISA says no known exploitation” may be used as shorthand only if that limitation remains clear.The field does not prove that exploitation is impossible, and it should not be treated as a permanent status. At the same time, the available evidence does not justify claims about active attacks, exploit kits, private proofs of concept, or attackers developing an exploit from source or binary comparisons.
“Automatable: no” should likewise remain an attributed SSVC selection. The supplied information does not support a detailed account of how malicious content might be delivered or scaled.
“Technical impact: total” helps explain the urgency of remediation, but it does not broaden the documented outcome beyond the public description or broaden the platform scope beyond Chrome on macOS.
Taken together, the available assessment supports a measured conclusion: this is a technically serious browser vulnerability with no exploitation identified in the dated SSVC record. Patch promptly, but do not declare that affected Macs are already compromised solely because their Chrome version falls inside the vulnerable range.
Weakness Labels Add Context, Not a Different Remediation
The supplied record associates the issue with heap-buffer-overflow and out-of-bounds-write weakness categories. These are related descriptions of a memory-safety problem: one emphasizes the affected memory region, while the other emphasizes access beyond a valid boundary.The taxonomy does not change the operational answer. Administrators do not need to resolve which weakness label is more descriptive before acting. The product, platform, and version boundary are sufficient:
- Google Chrome is the documented product.
- macOS is the documented platform.
- Versions earlier than 150.0.7871.46 are affected.
- Updating to 150.0.7871.46 or later is the established remediation threshold.
Evidence Timeline
The available material supports an evidence timeline, but not the previously asserted June 30, July 1, or July 2 release and publication narrative. Those unsupported calendar claims have been removed rather than treated as established facts.Chrome-originated disclosure stage — Chrome supplied the core vulnerability description, including the heap buffer overflow, crafted-HTML condition, macOS scope, and affected-version boundary.
CISA-ADP enrichment stage — CISA-ADP contributed the CVSS 3.1 score of 8.8 HIGH and the associated vector.
Dated SSVC assessment — At
2026-07-02T13:11:12.204696Z, the supplied SSVC record listed exploitation as “none,” automatable as “no,” and technical impact as “total.”NIST affected-product analysis stage — The affected configuration associated the vulnerable Chrome range with Apple macOS and placed 150.0.7871.46 outside the affected range.
Current remediation stage — An in-scope Mac remains unresolved until Google Chrome reports version 150.0.7871.46 or later.
This staged view preserves the provenance of the record without assigning an unsupported release date to the corrected Chrome build. It also prevents fields supplied by Chrome, CISA-ADP, and NIST from being flattened into a single unattributed assessment.
End-User Verification Is Part of the Fix
A browser update should be considered complete only when the user or administrator can verify the resulting version.For an individual Mac user, the acceptance criterion is visible and specific:
General browser-administration experience may justify reminding users to complete offered restart or relaunch actions, but the article should not convert assumptions about background downloads, application process state, or on-disk files into CVE-specific facts. The supplied evidence establishes a version threshold, not Chrome’s exact update behavior on every managed or unmanaged Mac.
Similarly, fleet teams may use deployment status, application inventory, endpoint queries, or local checks as part of their normal operations. The vulnerability record does not prescribe a particular management product, telemetry system, installation type, or update schedule. Those are implementation choices.
The universal closure condition is simpler: obtain trustworthy evidence that the in-scope Chrome installation reports version 150.0.7871.46 or later.
A missing, stale, truncated, or major-version-only result should remain unresolved. “Chrome 150” is insufficient because it does not prove that the browser is at or above 150.0.7871.46.
Action Checklist for Administrators
Identification
- Inventory Google Chrome specifically on managed Macs.
- Collect the complete four-part Chrome version.
- Flag every Mac reporting a version earlier than 150.0.7871.46.
- Treat missing, stale, incomplete, or major-version-only results as unresolved.
- Preserve the initial in-scope device list as the remediation baseline.
Deployment
- Use the organization’s approved browser-management or software-deployment process.
- Deploy a currently supported Chrome release that is 150.0.7871.46 or later.
- Tell affected users that a Chrome relaunch and version check are required.
- Escalate systems that cannot receive an approved supported release through the normal endpoint-support process.
Verification
- Collect fresh version information after deployment.
- Investigate every Mac that remains below 150.0.7871.46.
- On a representative sample—or on each device when central inventory is unavailable—open Chrome menu → Help → About Google Chrome.
- Select Relaunch if offered.
- Return to the About page and verify version 150.0.7871.46 or later.
- Keep devices with unknown or conflicting status open in the remediation ticket.
- Close the affected-device list only when no unexplained in-scope Mac remains below the threshold.
Reporting
- Describe the issue as a heap buffer overflow permitting out-of-bounds memory access through crafted HTML.
- Record 8.8 HIGH as the CISA-ADP CVSS 3.1 assessment, not as an NVD-authored score.
- Record the SSVC exploitation value as “none” at
2026-07-02T13:11:12.204696Z. - Do not translate that field into a timeless claim that exploitation does not exist.
- Preserve macOS as part of the affected configuration.
- Do not add Windows, Linux, Edge, or other Chromium browsers without product-specific supporting evidence.
- Avoid unsupported claims about delivery methods, exploit development, code execution, sandbox escape, or full system compromise.
What Not to Use as a Substitute for Updating
The supplied record does not establish a supported configuration workaround, browser flag, graphics setting, monitoring signature, network rule, or operating-system control that removes the vulnerable condition.Organizations may already use endpoint security, web filtering, application controls, least privilege, or isolated administrative workflows. Those measures can remain useful parts of a broader defensive program, but they should not be presented as CVE-specific remediation unless supporting evidence becomes available.
Likewise, the absence of identified exploitation in the dated SSVC record is not a compensating control. It supplies prioritization context; it does not move an old Chrome installation outside the affected range.
The reliable response established here is version based:
- Find affected Chrome installations on Macs.
- Update them to 150.0.7871.46 or later.
- Complete the offered relaunch.
- Verify the full displayed version.
- Keep unresolved devices visible until verification succeeds.
A Precise Alert Is More Useful Than a Broad One
CVE-2026-14385 demonstrates why browser security notices must keep product, platform, version, attack conditions, and assessment provenance attached to one another.Removing the macOS qualifier creates unsupported Windows and Edge findings. Reporting only “Chrome 150” loses the fixed-build precision. Calling the CISA-ADP score an NVD score loses attribution. Turning a dated SSVC field into “CISA certified no exploitation” overstates what the record says. Turning out-of-bounds memory access into proven system compromise overstates the documented consequence.
The accurate alert is narrower:
That statement provides enough information for users and administrators to act without inventing unavailable technical or release-history details.
The forward-looking task is to continue monitoring authoritative product and vulnerability information for a changed exploitation assessment, expanded affected-product scope, or additional technical guidance. If Microsoft or another browser vendor later identifies a corresponding issue, that advisory should be handled using that vendor’s own affected versions and remediation boundary.
Until then, keep this finding disciplined: patch Google Chrome on affected Macs, verify the full version after relaunch, and do not extrapolate CVE-2026-14385 to Edge, Windows, Linux, or every Chromium browser without supporting evidence.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:39:50-07:00
NVD - CVE-2026-14385
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:39:50-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromium.googlesource.com
- Related coverage: chromium.org
- Related coverage: blog.chromium.org
Introducing Skia Graphite: Chrome's rasterization backend for the future
Today's The Fast and the Curious post covers the launch of Skia's new rasterization backend, Graphite, in Chrome on Apple Silicon Macs. Graphite is instrumental in helping Chrome achieve exceptional scores on Motionmark 1.3 and is key to unlocking a ton of future improvements in Chrome...blog.chromium.org - Related coverage: new.chromium.org
