DEV Community

DeepSeaX
DeepSeaX

Posted on

CVE-2026-2441: Chrome's First Zero-Day of 2026 — CSS Use-After-Free Exploited in the Wild

#cve20262441 #chrome #zeroday #cybersecurity

They Weaponized CSS

Google just patched Chrome's first actively exploited zero-day of 2026, and the attack vector is something most security teams don't even monitor: CSS rendering.

CVE-2026-2441 is a use-after-free vulnerability in Chrome's CSS engine that allows remote code execution inside the browser sandbox via a crafted HTML page. No user interaction beyond visiting a malicious page. No JavaScript required in the initial payload.

CVSS: 8.8 (High). Actively exploited in the wild. Patch now.

How the Exploit Works

Use-after-free (UAF) bugs occur when a program frees a block of memory but continues to reference it. In CVE-2026-2441, the vulnerability lies in the interaction between CSS @property registration and paint() worklet initialization on Chrome's compositor thread.

Here's the attack chain:

  1. Attacker crafts malicious HTML page with CSS that triggers a specific rendering sequence
  2. Chrome allocates memory for a CSS element during style computation
  3. Memory is marked as freed during a layout recalculation triggered by the CSS manipulation
  4. Chrome's compositor thread still holds a dangling pointer to the freed memory
  5. Attacker-controlled data is sprayed into the freed memory region
  6. The dangling pointer is dereferenced, executing attacker-controlled code inside the renderer sandbox
  7. Sandbox escape is achieved by corrupting shared memory buffers between the renderer and GPU process

The critical detail: this exploit targets the compositor thread, not the main thread. Most browser security instrumentation focuses on the main JavaScript execution context. The compositor thread handles rendering, animations, and paint operations — a blind spot for many EDR solutions.

Why CSS Is a Perfect Attack Surface

CSS cannot be disabled. It cannot be blocked. It cannot be filtered without breaking every website on the internet.

Unlike JavaScript exploits — which can be mitigated with Content Security Policy, script blocking, or sandboxing — CSS is processed by the rendering engine at the lowest level. Every page load triggers CSS parsing. Every single one.

This makes CSS-based exploits particularly dangerous:

  • No JavaScript needed for the initial trigger
  • CSP headers don't help — CSS is always allowed
  • Ad blockers don't help — inline CSS in the page itself
  • Browser extensions can't intercept CSS rendering pipeline
  • No user interaction beyond visiting the page

Affected Versions

Platform Vulnerable Patched
Windows < 145.0.7632.75 145.0.7632.75/76
macOS < 145.0.7632.75 145.0.7632.75/76
Linux < 144.0.7559.75 144.0.7559.75
Extended Stable < 144.0.7559.177 144.0.7559.177

All Chromium-based browsers are affected: Microsoft Edge, Brave, Opera, Vivaldi, Arc. Check your version immediately.

Timeline

Date Event
Feb 11, 2026 Shaheen Fazim reports vulnerability to Google
Feb 13, 2026 Google releases patch
Feb 16, 2026 Public advisory confirms active exploitation
Feb 27, 2026 Details of compositor thread attack surface emerge

Google has not disclosed which threat actors are exploiting this vulnerability or who the targets are. Given the sophistication of CSS-based exploitation chains, state-sponsored actors are the most likely operators.

Detection: Finding Exploitation Attempts

Network-Level Detection

CSS exploits are difficult to detect at the network layer because CSS is legitimate traffic. Focus on post-exploitation indicators:

title: Chrome Renderer Sandbox Escape Indicators
status: experimental
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith: '\\chrome.exe'
    selection_child:
        Image|endswith:
            - '\\cmd.exe'
            - '\\powershell.exe'
            - '\\wscript.exe'
            - '\\cscript.exe'
            - '\\mshta.exe'
            - '\\rundll32.exe'
    filter_legitimate:
        CommandLine|contains:
            - '--type='
            - '--utility-sub-type='
    condition: selection_parent and selection_child and not filter_legitimate
level: critical
Enter fullscreen mode Exit fullscreen mode

Endpoint Detection (KQL) 

DeviceProcessEvents
| where InitiatingProcessFileName == "chrome.exe"
| where FileName in ("cmd.exe", "powershell.exe", "wscript.exe", "rundll32.exe")
| where not(ProcessCommandLine has_any ("--type=", "--utility-sub-type="))
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
Enter fullscreen mode Exit fullscreen mode

GPU Process Anomaly Detection

Since the sandbox escape targets the GPU process, monitor for:

DeviceProcessEvents
| where InitiatingProcessFileName == "chrome.exe"
| where InitiatingProcessCommandLine has "--type=gpu-process"
| where FileName !in ("chrome.exe", "chrome_crashpad_handler.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine
Enter fullscreen mode Exit fullscreen mode

Version Verification (PowerShell) 

# Check Chrome version across fleet
$chrome = Get-ItemProperty 'HKLM:\SOFTWARE\Google\Chrome' -ErrorAction SilentlyContinue
if ($chrome) {
    $ver = [version]$chrome.'(Default)'
    $safe = [version]'145.0.7632.75'
    if ($ver -lt $safe) {
        Write-Warning "VULNERABLE: Chrome $ver (need $safe+)"
    } else {
        Write-Host "PATCHED: Chrome $ver"
    }
}
Enter fullscreen mode Exit fullscreen mode

Remediation

Immediate Actions (Today)

  1. Force Chrome update across all endpoints

    • Navigate to chrome://settings/help and verify version >= 145.0.7632.75
    • For managed environments: push update via Group Policy or MDM

  2. Check Chromium-based browsers — Edge, Brave, Opera need separate patches

    • Edge: check edge://settings/help
    • Brave: check brave://settings/help

  3. Audit browser versions fleet-wide

   # Osquery
   SELECT name, version FROM programs WHERE name LIKE '%Chrome%' OR name LIKE '%Edge%';
Enter fullscreen mode Exit fullscreen mode

Strategic Defense

  1. Deploy browser isolation for high-risk users (executives, finance, IT admins)

    • Cloud-based rendering eliminates local exploitation
    • Menlo Security, Zscaler Browser Isolation, or Cloudflare Browser Isolation

  2. Enable Chrome's V8 Heap Sandbox (experimental)

    • chrome://flags/#enable-v8-sandbox
    • Adds an additional memory corruption mitigation layer

  3. Monitor crash reports — UAF exploitation often causes renderer crashes before successful exploitation

    • Check chrome://crashes for unusual crash patterns
    • Centralize crash telemetry via Chrome Enterprise reporting

The Bigger Picture: CSS as an Attack Surface

This is not the first CSS-based browser exploit, and it won't be the last. The browser rendering pipeline — CSS parsing, layout computation, paint operations, compositing — represents an enormous attack surface that receives less security scrutiny than JavaScript engines.

Chrome's V8 JavaScript engine has been hardened with:

  • V8 Heap Sandbox
  • Pointer compression
  • Control Flow Integrity (CFI)

The CSS rendering engine (Blink/Skia) lacks equivalent hardening. Expect more CSS-based zero-days in 2026 as attackers shift to less-defended code paths.

Your browser is the most exposed application in your organization. A single malicious page visit is all it takes.

Need help verifying your browser fleet is patched? Request a free penetration test at theinsider-x.com — currently in open beta.

Sources: Google Chrome Security Advisory, The Hacker News, Malwarebytes, The Register, Menlo Security

MITRE ATT&CK: T1189 (Drive-by Compromise), T1203 (Exploitation for Client Execution), T1068 (Exploitation for Privilege Escalation)

Top comments (0)