Chrome 140 Security Update: High-Severity V8 Use-After-Free CVE-2025-9864

Chrome’s September security update closes a high-severity use-after-free vulnerability in the V8 JavaScript engine — tracked as CVE-2025-9864 — that could allow an attacker to corrupt memory and potentially achieve remote code execution through a crafted web page, and administrators of Chromium-based browsers including Microsoft Edge must prioritize updates immediately. (thecyberthrone.in, cvefeed.io)

Background​

The V8 engine is the high-performance JavaScript and WebAssembly runtime embedded in Google Chrome and many Chromium-based browsers. Memory-safety bugs in V8 — most notably use-after-free and type confusion defects — have repeatedly produced high-risk security advisories because they provide a direct path for remote exploitation via web content. CVE-2025-9864 is the latest in a string of critical V8 issues and was published alongside Chrome’s Stable Channel update that moved Chrome to the 140.x branch. (chromereleases.googleblog.com, thecyberthrone.in)
Google’s official Stable Channel release for the desktop rollouts for Chrome 140 lists multiple security fixes; independent reporting identified CVE-2025-9864 as a high-severity use-after-free in V8 that was remediated in Chrome 140.0.7339.80/81 builds. Security reporting indicates the vulnerability was reported privately to Google by the Yandex Security Team. (chromereleases.googleblog.com, securityweek.com)

---

What the vulnerability is and why it matters​

Technical nature: use-after-free in V8​

A use-after-free occurs when code retains references to memory after that memory has been returned to the allocator; subsequent allocations can place attacker-controlled data at the same memory address, enabling memory corruption. In JavaScript engines like V8, these flaws allow crafted scripts to manipulate object lifetimes and layout, often leading to heap corruption and potentially arbitrary code execution within the renderer process. CVE-2025-9864 is described in vendor advisories and public analysis as exactly this class of flaw. (cvefeed.io, zeropath.com)

Severity and scoring​

Public vulnerability aggregators report a CVSS v3.1 base score of 8.8 for CVE-2025-9864, classifying it as High. That score reflects the combination of remote attack surface (drive-by web content), potential impact (code execution), and typically low required privileges (any user who can view web content). While CVSS is an imperfect metric, an 8.8 rating signals urgent attention in enterprise patching calendars. (cvefeed.io)

Exploitation potential​

Historically, V8 use-after-free bugs have been weaponized in staged exploit chains: (1) trigger memory corruption in the renderer via malicious JavaScript, (2) convert corruption to code execution in the renderer, (3) escape the renderer sandbox and gain broader system access. Google’s advisory and subsequent reporting do not state that a public exploit exists for CVE-2025-9864 at the time of disclosure, but the pattern of past exploits means defenders must assume a weaponizable path exists until proven otherwise. Public reporting emphasizes that details were restricted until a majority of users could update — a common practice to limit early weaponization. Treat “no public exploit reported” as a provisional assurance, not a guarantee of safety. (chromereleases.googleblog.com, securityweek.com)

---

Affected products and fixed versions​

• Google Chrome prior to 140.0.7339.80 (Linux) and 140.0.7339.80/81 (Windows/macOS) are listed as affected; the Chrome 140 stable rollout contains the V8 fix. (cvefeed.io, thecyberthrone.in)
• Other Chromium-based browsers that incorporate upstream Chromium/V8 releases can be affected until they ingest the upstream patch — this includes Microsoft Edge (Chromium-based), Brave, Opera, Vivaldi, and numerous embedded Chromium forks. Enterprises should verify the installed Chromium-engine versions for any distribution in use and apply vendor-supplied updates. (cvefeed.io, learn.microsoft.com)
• Microsoft’s documentation and security update guidance confirm that Edge’s security cadence follows Chromium upstream fixes and that Microsoft tracks these Chromium security fixes in its security update notes. Enterprise Edge administrators should look for Edge stable/extended-stable builds that include Chromium 140 branch fixes. If an Edge build number predates the Chromium 140 fix, the browser remains vulnerable until updated. (learn.microsoft.com, msrc.microsoft.com)

---

Verification and cross-references​

To ensure the technical points in this article are accurate, the following independent verifications were made:

• Chrome Releases (official Google blog posts) list the Desktop Stable Channel update in the 140 series and indicate the inclusion of V8-related fixes for the stable channel rollouts. This confirms the vendor’s release window and affected builds. (chromereleases.googleblog.com)
• Security reporting from independent outlets (SecurityWeek, CybersecurityNews and others) identified CVE-2025-9864 as a high-severity use-after-free in V8, reported by the Yandex Security Team, and corroborated the fixed versions (140.0.7339.80/81). These independent reports confirm the CVE label, the nature of the vulnerability, and the recommended fixed versions. (securityweek.com, cybersecuritynews.com)
• Vulnerability aggregators and trackers (CVEFeed and similar services) publish the CVSS rating (8.8) and list the canonical remediation version numbers, which align with Google’s release artifacts. Where specific attribution or bounty amounts were reported publicly, independent outlets repeated Google’s notices that some bug bounty payouts applied to related issues while the high-severity V8 issue’s details were retained. When a claim appeared only in one low-trust source, that claim is flagged as unverified below. (cvefeed.io, zeropath.com)

---

Practical guidance: patching, detection and mitigation​

Immediate actions for end users and administrators​

• Update Google Chrome to the latest stable version immediately via the browser’s update mechanism (Help > About Google Chrome) or via managed update channels for enterprise. Confirm that the installed build is >= 140.0.7339.80 / 140.0.7339.81 depending on platform. (thecyberthrone.in, cvefeed.io)
• Microsoft Edge (Chromium-based) users should update to the latest Edge stable build as soon as Microsoft releases the corresponding Chromium 140-based Edge build. Enterprises should track Microsoft Edge release notes and the Microsoft Security Response Center guidance for the presence of the specific Chromium fixes. If Edge has not yet ingested Chromium 140, prioritize manual updates once the vendor build is released. (learn.microsoft.com, msrc.microsoft.com)
• For managed environments:
• Stage the patched browser in test pools and validate critical business web apps.
• Roll forward patches using your standard software deployment system (SCCM/Intune, Jamf, etc.).
• Disable or restrict unsupported browser variants until updates are available.

Short-term mitigations when immediate update isn’t possible​

• Enforce stricter web content policies:
• Set JavaScript restrictions for high-risk endpoints where feasible.
• Use Content Security Policy (CSP) and blocking lists at the gateway to reduce exposure to malicious pages.
• Enable browser safety features:
• Turn on Enhanced Safe Browsing (or equivalent vendor feature) to increase protection against malicious pages.
• Use site isolation and process-per-site settings where available to limit exploitation blast radius.
• Network and perimeter controls:
• Block or isolate known risky domains and phishing hubs at DNS and proxy layers.
• Apply secure web gateway rules to detonate suspicious pages in a sandboxed environment.

Detection guidance​

• Monitor for anomalous Chrome/Edge process behavior:
• Unexpected child processes spawned by browser processes.
• Unusual network traffic initiated by renderer processes.
• Review browser crash reports and telemetry:
• Look for increases in renderer crashes or V8-related crash strings.
• Collect and analyze crash dumps from affected machines; heap corruption signs or repeated renderer crashes tied to JavaScript parsing are suspicious.
• Use EDR/UEBA tools to detect exploitation patterns:
• Flag memory-modifying behavior originating from the browser.
• Watch for post-exploitation lateral movement signatures or persistence attempts following a browser compromise.

---

Enterprise patch management checklist (step-by-step)​

• Inventory
• Identify all Chromium-based browsers in production and their exact build numbers.
• Prioritization
• Classify endpoints by exposure (public-facing, high-privilege, high-availability).
• Test
• Deploy the Chrome 140 build to a representative test group and validate business-critical sites.
• Rollout
• Schedule phased rollouts during maintenance windows; aim for full deployment within 72 hours for high-exposure systems.
• Verification
• Confirm build versions post-patch and monitor crash telemetry for two weeks.
• Post-deployment hardening
• Apply CSP, add deny-lists for risky domains, and enforce security policies that limit extension installation rights.

---

Threat modeling and risk analysis​

Likely attack vectors​

• Drive-by downloads: a user simply visiting a malicious or compromised site hosting exploit code.
• Malicious advertising (malvertising): exploit embedded in ad content served to legitimate sites.
• Phishing pages that host obfuscated JavaScript to trigger the vulnerability.

Impact profile​

• Successful remote code execution within the renderer process can lead to data theft, credential theft, or pivoting to further compromise.
• Sandboxing and site isolation reduce, but do not eliminate, the impact; combined exploitation may be required to escape sandboxes to achieve full system compromise.

Who should worry most​

• Organizations with high-value web-facing user bases, such as financial services, critical infrastructure, and enterprise administrators.
• Devices or systems that do not receive regular updates — kiosks, legacy endpoints, and unmanaged devices.

---

Notable strengths in vendor response​

• Google released fixes in a stable branch and kept vulnerability technical details restricted until the majority of users could update — a standard, measured disclosure approach that reduces short-term weaponization risk. (chromereleases.googleblog.com)
• Multiple Chromium downstream vendors track and document ingestion plans; Microsoft publishes Edge security release notes that show awareness and intent to incorporate Chromium security updates. This coordinated upstream-to-downstream model shortens the window of exposure across the Chromium ecosystem when downstream vendors act promptly. (learn.microsoft.com, thecyberthrone.in)

---

Risks, caveats, and things that remain unverified​

• Public exploit status: at the time of the Chrome 140 rollout there was no confirmed public, reproducible exploit disclosed for CVE-2025-9864 in open sources; however, absence of evidence is not evidence of absence. Past V8 vulnerabilities have been quickly weaponized, so the risk remains elevated until broad deployment of the patch. This article treats the “no public exploit” claim conservatively. (chromereleases.googleblog.com, securityweek.com)
• Attribution nuance: some outlets report the reporter as “Pavel Kuzmin of the Yandex Security Team” while vendor notices credit the Yandex Security Team collectively; single-researcher attribution appears in secondary reporting and is treated as plausible but subject to confirmation from an authoritative vendor advisory. Where only one reporting outlet lists a specific individual, that detail is flagged as less robust pending confirmation. (feedly.com, securityweek.com)
• CVSS and scoring sources: the 8.8 CVSS score is reported by aggregators and trackers; official vendor advisories do not always publish a CVSS score. Where score discrepancies exist between trackers, enterprise risk managers should rely on internal risk assessments in addition to public CVSS numbers. (cvefeed.io)

---

Hardening recommendations beyond patching​

• Restrict extension installation: limit the ability to install third-party extensions in Chromium-based browsers via enterprise policy to reduce attack surface and the possibilities for post-exploitation persistence.
• Network segmentation: place high-sensitivity users and systems behind strict web gateways and enforce least-privilege browsing paths.
• Browser isolation: where practical, use remote browser isolation or cloud-based browsing sandboxes to render untrusted sites off-endpoint.
• Memory safety tooling: ensure AddressSanitizer, fuzzing results, and other memory-hardening techniques are enabled in development pipelines for in-house applications that embed V8 or Chromium.

---

For defenders: what to watch for in telemetry​

• Sudden upticks in Chrome renderer crashes with strings referencing V8, heap corruption, or JavaScript engine errors.
• New or unusual child processes launched by browser processes.
• Exceptions and access violation events in memory near browser process lifetime boundaries.
• Unusual outbound connections originating from browsers directly after rendering heavy JavaScript pages.

---

Conclusion​

CVE-2025-9864 is a high-risk use-after-free vulnerability in Google’s V8 engine that affects Chromium-based browsers until upstream fixes are ingested and rolled out. The public disclosures and independent reporting align on the affected Chrome 140 builds and the need for immediate updates. Organizations should treat this as a priority patch event: inventory Chromium derivatives, stage and deploy Chrome/Edge updates promptly, tighten browser policies, and monitor crash telemetry and EDR signals for signs of attempted exploitation. While the immediate mitigation is straightforward — update your browsers — the incident is a reminder that memory-safety bugs in core web engines remain a systemic risk requiring a defense-in-depth posture across patching, policy, and monitoring. (thecyberthrone.in, cvefeed.io, learn.microsoft.com)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center