CVE-2026-2441

What it actually does

This vulnerability is a use-after-free memory-safety flaw in Google Chrome's CSS handling before version 145.0.7632.75. A crafted HTML page can cause Chrome to reuse freed memory in the renderer process, allowing attacker-controlled data to influence execution flow and execute arbitrary code inside Chrome's sandbox. Successful exploitation can compromise confidentiality, integrity, and availability of browser-session data and may become full system compromise if chained with a sandbox escape or privilege-escalation vulnerability on Windows, macOS, or Linux.

Why it matters to the business

Because this is remotely reachable through a web page, requires only user interaction, is listed in CISA KEV, and has active in-the-wild exploitation, organizations should treat exposed Chrome installations as high priority. Compromise can lead to theft of web session data, credential material available to the browser, unauthorized actions in logged-in applications, malware delivery, or disruption of employee endpoints. The CISA KEV remediation deadline is 2026-03-10, and the vulnerability has been public for 178 days, increasing the likelihood that exploit techniques are understood and incorporated into broader intrusion activity.

How an attack unfolds

An attacker prepares a malicious web page containing specially crafted HTML, CSS, and likely JavaScript that manipulates CSS object lifetimes in Chrome. The victim is lured to the page through phishing, malvertising, a compromised website, or a malicious redirect. When the page is rendered by a vulnerable Chrome version, the CSS engine frees an object and later accesses it again, allowing attacker-controlled memory to be used in its place. With reliable heap shaping, the attacker can turn the memory corruption into code execution in the Chrome renderer sandbox. From there, the attacker may read or manipulate data accessible to that renderer process, abuse active browser sessions, or chain the exploit with a sandbox escape to run code on the underlying operating system. Active exploitation is reported in the wild, so incident responders should assume exploit delivery may have occurred through transient web content rather than a persistent local artifact.

How to fix it

Upgrade Google Chrome to version 145.0.7632.75 or later on all supported platforms. Where enterprise browser management is used, force-update Chrome, prevent users from delaying updates, and verify that automatic updates are functioning. Restart Chrome after patching, because the fixed binaries are not fully active until the browser is relaunched. For systems where immediate patching is not possible, reduce exposure by limiting access to untrusted websites, disabling unnecessary browser extensions, using web isolation or remote browser isolation for high-risk users, and enforcing least privilege on endpoints. Because this vulnerability is in CISA KEV with a due date of 2026-03-10, organizations subject to KEV remediation requirements should track closure against that deadline.

How to confirm the fix worked

Confirm that every Chrome installation reports version 145.0.7632.75 or later using enterprise browser inventory, endpoint management, software inventory, or the browser's chrome://version page. Validate that stale browser processes have been restarted after update deployment. For managed fleets, compare installed versions across Windows, macOS, and Linux endpoints and investigate machines pinned to older release channels or blocked from update services. Exposure exists where Google Chrome is below 145.0.7632.75, including systems where the user has not relaunched the browser after patching. Validate mitigations by confirming update policies, update telemetry, and endpoint inventory all agree on the patched version.

Typical attack path

1. Identify users running Google Chrome versions earlier than 145.0.7632.75.
2. Host or inject a crafted HTML/CSS payload on an attacker-controlled or compromised web page.
3. Deliver the link through phishing, malvertising, watering-hole compromise, messaging platforms, or redirects.
4. Wait for the target to open the page in a vulnerable Chrome browser.
5. Trigger the CSS use-after-free condition during page rendering.
6. Shape browser memory so the freed object is replaced with attacker-controlled data.
7. Execute code inside Chrome's renderer sandbox.
8. Optionally chain with a sandbox escape or OS-level privilege escalation to gain broader endpoint control, persistence, or malware execution.

How to detect it

To determine whether exploitation may already have occurred, correlate browser version history with web, DNS, proxy, EDR, and crash telemetry. Focus on endpoints that used Chrome before version 145.0.7632.75 after public disclosure or during the active exploitation window. Review Chrome crash reports and operating-system application logs for renderer or GPU process crashes shortly after visits to suspicious, newly registered, uncategorized, or compromised websites. In EDR, look for unusual behavior originating from Chrome processes, especially child process creation, script interpreters, archive tools, installers, credential-access tools, or network connections to unfamiliar infrastructure. Review web proxy logs for redirect chains, malvertising traffic, data URLs, heavily obfuscated JavaScript, or uncommon CSS-heavy exploit pages preceding a crash. Because exploit delivery may leave little durable evidence on disk, prioritize behavioral indicators: Chrome crash followed by new files in user-writable locations, unexpected persistence, suspicious outbound connections, token or cookie theft indicators, or malware execution. If threat-intelligence feeds provide campaign infrastructure for observed exploitation, enrich proxy and DNS hunts with those domains and IPs; no universally reliable public exploit URL or payload hash is implied by the vulnerability description alone.

• Google Chrome < 145.0.7632.75
• Chrome/144.
• Chrome/143.
• Chrome/142.
• chrome.exe --type=renderer
• chrome --type=renderer
• Google Chrome Helper (Renderer)
• EXCEPTION_ACCESS_VIOLATION
• SIGSEGV
• Use after free in CSS

What your security team should do

• Immediately inventory Chrome versions and prioritize remediation of all installations below 145.0.7632.75.
• Treat this as urgent because it is in CISA KEV and has active in-the-wild exploitation; track completion before the 2026-03-10 KEV deadline where applicable.
• Force browser updates and restarts through enterprise management rather than relying on user-initiated updates.
• Hunt for suspicious Chrome renderer crashes, exploit-like browsing activity, and post-exploitation behavior on endpoints that ran vulnerable versions after publication.
• Review web proxy, DNS, EDR, and browser telemetry for users who visited unusual newly registered domains, compromised websites, or malvertising chains immediately before Chrome crashes or endpoint alerts.
• Prioritize forensic review for endpoints that show Chrome crashes followed by unusual child processes, credential access, suspicious downloads, persistence creation, or command-and-control traffic.
• Apply browser hardening controls such as extension allowlisting, site isolation where applicable, remote browser isolation for high-risk users, and endpoint least privilege.
• Monitor vendor advisories for related Chromium patches and ensure downstream Chromium-based browsers are assessed separately if present.