Incident Report: Chrome Zero-Day CVE-2026-2441 — CSS Use-After-Free Exploited in the Wild

February 17, 2026 • Incident Report, Browser Security, Chrome, Zero-Day

🔴 SEVERITY: HIGH (CVSS 8.8) — CVE-2026-2441 is a use-after-free vulnerability in Chrome's CSS engine, actively exploited in the wild before Google shipped an emergency patch. Visiting a single malicious webpage is enough to trigger remote code execution inside the Chrome sandbox. Added to CISA's Known Exploited Vulnerabilities catalog on February 17, 2026 with a federal remediation deadline of March 10, 2026. Update Chrome right now.

🚨 Immediate Actions (Do This First)

This is an actively exploited, no-interaction-required bug. A crafted HTML page on any site you visit can trigger it. Patch now, investigate later.

1. Update Chrome Immediately

Open Chrome and navigate to:

chrome://settings/help

Chrome will automatically check for updates and download the patch. You must restart the browser for the update to take effect — click the Relaunch button when it appears.

Patched versions:

Anything below these versions is vulnerable.

2. Verify Your Version

After relaunching, confirm you're patched:

chrome://version

Look at the first line ("Google Chrome"). If it shows 145.0.7632.75 or higher on Windows/Linux, or 145.0.7632.76 or higher on macOS, you're safe.

3. Update Other Chromium-Based Browsers

CVE-2026-2441 lives in the Blink/CSS engine used by all Chromium-based browsers. Until each vendor ships the upstream fix, they're also vulnerable:

• Microsoft Edge — Update via edge://settings/help
• Brave — Update via brave://settings/help
• Opera — Update via opera://settings
• Vivaldi — Update via vivaldi://about
• Arc, Comet, SigmaOS, etc. — Check vendor advisories

Check their release notes for confirmation that CVE-2026-2441 is addressed.

4. Enterprise: Force the Update

Don't rely on users clicking "Relaunch." Push the update:

# macOS (Jamf/MDM) — force quit Chrome so next launch picks up new version
launchctl kickstart -k gui/$(id -u)/com.google.keystone.agent

# Windows (Group Policy) — set target version override
# Computer Config → Admin Templates → Google → Google Update → Applications → Google Chrome
# "Target version prefix override" = 145.0.7632.75

# Google Workspace / Chrome Browser Cloud Management
# Admin console → Devices → Chrome → Settings → User & Browser → 
# "Force installation of updates" = Enabled

For fleet visibility, query your endpoint management tool for Chrome version distribution and flag anything below 145.0.7632.75.

5. Temporary Mitigations (If You Can't Patch Immediately)

If patching is blocked for any reason:

• Avoid untrusted websites. Stick to known, trusted domains until patched.
• Disable JavaScript on untrusted sites via chrome://settings/content/javascript (drastic, but effective for triaging).
• Enable Enhanced Safe Browsing: chrome://settings/security → "Enhanced protection"
• Use Site Isolation (enabled by default in modern Chrome, but verify at chrome://flags/#enable-site-per-process)
• Switch browsers temporarily for sensitive work (e.g., Firefox, which uses a different rendering engine)

🔍 Am I Affected?

Check Chrome Version

chrome://version

If the version is below the patched baseline (145.0.7632.75 / .76), you are vulnerable.

Detection Guidance

There are no widely published IOCs (Indicators of Compromise) for this specific exploit yet, since the original exploit chain has not been fully documented publicly. However, post-exploitation indicators you should watch for include:

• Unusual Chrome renderer child processes spawning non-browser executables
• Unexpected outbound network connections from Chrome to unknown hosts
• New persistence mechanisms (startup items, launch agents, scheduled tasks) created after browsing sessions
• Credential access anomalies (password manager, session cookie theft)

EDR platforms that monitor browser process trees should flag anomalous behavior from chrome.exe / Google Chrome Helper / chrome renderer processes.

If You Suspect Compromise

1. Disconnect the affected machine from the network
2. Capture memory/disk images before remediation (for forensics)
3. Rotate credentials — any passwords, session cookies, or tokens accessible to the browser should be considered compromised
4. Clear Chrome profile data (cookies, cache, saved sessions)
5. Run a full EDR scan
6. Review authentication logs for suspicious sessions tied to the user

📋 Vulnerability Details

Official description (NVD):

"Use after free in CSS in Google Chrome prior to 145.0.7632.75 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page."

🧠 What is a Use-After-Free?

If you're not a low-level security person, the phrase "use-after-free" sounds abstract. Let's make it concrete.

Imagine Chrome allocates a chunk of memory to represent a CSS style object — say, the style applied to a <div>. When Chrome is done with that object, it frees the memory so it can be reused elsewhere. So far so good.

A use-after-free (UAF) bug happens when some other part of Chrome still holds a pointer to that freed memory and uses it as if it were still valid. At that moment, one of two things happens:

1. Crash — Chrome reads garbage and panics
2. Exploitation — An attacker has arranged for their data to land in that freed slot, so Chrome reads attacker-controlled bytes as if they were a legitimate style object

Step 2 is where bugs become weapons. By carefully shaping memory (heap spraying, object reuse, etc.), an attacker turns a dangling pointer into a type confusion primitive, then into arbitrary read/write, then into code execution.

Why CSS?

CSS parsing and style resolution are perennial UAF hunting grounds because:

• Complex object lifetimes — Style objects are created, cached, invalidated, and recomputed constantly as the DOM changes
• Incremental style recalculation — When you mutate the DOM, Chrome has to decide which styles are still valid, and this dance is error-prone
• Interaction with JavaScript — JS can trigger style recomputation, destroy elements, and reference detached nodes, opening windows where memory lifetime assumptions break
• Huge surface area — CSS is enormous (selectors, transitions, animations, grid, flex, custom properties, container queries...)

This isn't the first CSS-engine UAF in Chrome, and it won't be the last. It's one of the most targeted subsystems in every browser.

💀 Exploitation Flow

Based on the public description, the exploitation chain looks like this:

Victim visits attacker-controlled URL
           │
           ▼
Browser loads crafted HTML + CSS
           │
           ▼
CSS parser triggers use-after-free
           │
           ▼
Attacker-controlled memory reused as CSS object
           │
           ▼
Type confusion → arbitrary R/W primitive
           │
           ▼
Shellcode execution inside Chrome renderer sandbox

What the Attacker Gets

The exploit achieves code execution inside Chrome's renderer sandbox. That sandbox is an important mitigation — it means the attacker does not immediately own your operating system. But "sandboxed RCE" is still devastating:

• Full access to everything the tab can touch: cookies, localStorage, sessionStorage, IndexedDB for visited sites
• Cross-origin data theft via same-origin violations from native code
• Credential harvesting from autofill and saved passwords (depending on sandbox boundaries)
• Session hijacking for every logged-in service in that profile
• Spyware installation — an attacker with renderer RCE can chain a second bug to escape the sandbox

The CVSS Scope is Unchanged (sandboxed), but in practice, renderer RCE is the entry point for every serious browser attack chain. Most targeted attacks then pair it with a second vulnerability — a sandbox escape or kernel bug — to break out to the host OS.

Required Interaction

UI:R in the CVSS vector means the victim has to do something — in this case, visit a webpage. That's it. No clicking, no downloading, no credentials. Drive-by exploitation via:

• Malvertising networks
• Watering hole attacks on compromised legitimate sites
• Phishing links
• Embedded iframes on otherwise trusted pages

This is about as low-friction as browser exploits get.

🛡️ Defense in Depth

Patching is step one, but good browser hygiene reduces the blast radius of any future zero-day:

Keep Auto-Update Enabled

Chrome's default auto-update is your single most important defense. Do not disable it. If you're an enterprise admin managing policies, never turn off updates — instead, use staged rollouts and target version pinning if you need control.

Enable Enhanced Safe Browsing

chrome://settings/security → "Enhanced protection"

Enhanced Safe Browsing sends more telemetry to Google in exchange for faster detection of malicious URLs, downloads, and extensions. For most users this tradeoff is worth it.

Site Isolation

Make sure Site Isolation is active:

chrome://flags/#enable-site-per-process

This puts every site in its own renderer process, which means a UAF exploit against site A can't read cookies for site B through Spectre-style side channels. It's enabled by default on modern Chrome, but worth verifying in policy-managed environments.

Extension Hygiene

Every installed extension expands your attack surface. Audit chrome://extensions and remove anything you don't actively use. Prefer extensions from reputable publishers with open-source code and recent updates.

Browser-Aware EDR

If you're in an enterprise, your EDR solution should understand browser process trees. Modern tools flag:

• Chrome renderer spawning cmd.exe, powershell.exe, or shell processes
• Chrome making outbound connections to unusual IPs/domains
• Chrome writing to unusual filesystem locations
• New persistence mechanisms created during browsing sessions

📢 For Enterprise Admins

CISA BOD 22-01 Compliance

CVE-2026-2441 was added to CISA's Known Exploited Vulnerabilities (KEV) catalog on February 17, 2026 with a required remediation deadline of March 10, 2026. If you're a U.S. federal agency or federal contractor, BOD 22-01 requires you to patch by that date or formally document a risk acceptance.

Private sector organizations should treat the KEV deadline as a strong signal: if CISA is flagging it for federal networks, you should be patching too.

Deployment Paths

• Chrome Browser Cloud Management (free) — centralized policy and version control for Chrome across your fleet
• Windows Group Policy — use ADMX templates from Google's Chrome Enterprise docs
• Jamf / Intune / Workspace ONE — push via standard MDM workflows
• Homebrew-managed Macs — brew upgrade --cask google-chrome
• Linux package managers — apt upgrade google-chrome-stable / dnf upgrade google-chrome-stable

Monitoring & Detection

Without known-bad IOCs, the best you can do is behavioral monitoring:

• Version inventory — query your asset management system for Chrome versions; alert on anything below 145.0.7632.75
• Process tree anomalies — EDR rules flagging browser → shell child processes
• Network anomalies — unusual outbound connections from Chrome renderer processes
• Persistence monitoring — new scheduled tasks, launch agents, or registry run keys created around browsing activity

If you suspect targeted exploitation, preserve volatile memory before remediating — the exploit chain and any post-exploitation payload will likely only exist in RAM.

📝 Key Takeaways

1. Patch now. Chrome 145.0.7632.75 (Win/Linux) or 145.0.7632.76 (macOS). Restart the browser.
2. Don't forget Chromium derivatives. Edge, Brave, Opera, Vivaldi, and others share the vulnerable code.
3. It's sandboxed — but that's still bad. Sandbox RCE is the entry point for every serious browser attack chain.
4. CISA deadline is March 10, 2026. Federal agencies must patch; everyone else should.
5. Defense in depth matters. Auto-updates, Enhanced Safe Browsing, Site Isolation, EDR, and extension hygiene all reduce your exposure to the next zero-day.

Zero-days in browsers are not rare events. They're a structural feature of how the web works: browsers are the most complex user-facing software most people run, they parse untrusted input constantly, and the attack surface is enormous. Your best defense is fast patching and layered mitigations — not avoiding browsers.

References

• NVD — CVE-2026-2441
• CISA KEV Catalog
• Chromium Issue Tracker #483569511
• UH West Oʻahu Cyber — CVE-2026-2441 Summary
• Chrome Releases Blog

Stay patched out there. If you manage a fleet and need help building a detection/patch rollout plan, reach out on Twitter/X.