Google Fixes Two Chrome Zero-Days Exploited in the Wild Affecting Skia and V8

Chrome Patches Two Zero-Days: What You Need to Know

Quick Action Items

• Patch now: Chrome stable release | Google official advisory
  • Minimum safe version: 125.0.6422.141 or above (release note)
• Check Electron/embedded apps: Audit for outdated Chromium dependencies; rebuild and redeploy.
• IoT/Legacy: Search for embedded browser frameworks (libchromiumcontent, libskia, package.json versions).
• Detection: Scan EDR/SIEM logs for unusual renderer child processes, JIT anomalies, network beacons.

What Was Patched

Google shipped fixes for two critical zero-days in Chrome (Chromium Security Advisory, June 12, 2024). The bugs:

• Heap buffer overflow in WebRTC (CVE-2024-5275)
  • What it is: Out-of-bounds write lets an attacker smash heap memory during complex audio/video handling. (MITRE CVE-2024-5275)
  • Why it matters: Can lead to code execution, especially if chained with sandbox bypass.
• Type confusion in V8 (CVE-2024-5276)
  • What it is: JIT compiler assigns wrong object type; attacker tricks engine into unsafe memory access. (MITRE CVE-2024-5276)
  • Impact: Potential remote code execution or privilege escalation, seen before in major exploit chains (V8 prior incident: Project Zero’s report).

Both bugs were reported as exploited in the wild. Google’s official wording (advisory).

Who’s Affected

• Anyone running Chrome < 125.0.6422.141 on Windows, macOS, or Linux.
• Electron apps: Many use embedded Chromium; check your runtime.
• Mobile webviews: Android/iOS wrappers lag on updates.
• Enterprise fleets: Kiosks, point-of-sale, anything with auto-update disabled.

If you’re using Chromium-based frameworks—Flutter, NW.js, Electron—you need a dependency audit.

How to Patch

• Chrome Browser:
  • Open chrome://settings/help and confirm your version matches or exceeds 125.0.6422.141 (Google instructions).
  • Linux (Debian/Ubuntu):

    sudo apt-get update && sudo apt-get --only-upgrade install google-chrome-stable
    

    (Official update docs)
  • macOS:
    Use Homebrew or Chrome auto-update.
  • Windows:
    Chrome updates by default, but verify manually.
• Enterprise:
  • Follow Chrome Enterprise update channels.
• Electron Apps:
  • Check package.json for "electron" version; run electron --version.
  • Audit libchromiumcontent and libskia binaries.
  • Rebuild apps using patched Electron releases (Electron Security Advisories).

Detection & Mitigation

• Immediate steps for security teams:

  • Prioritize patching by exposure (public-facing browsers, client endpoints).
  • Roll out updates, reboot endpoints.
  • Search logs for suspicious renderer child processes post-update (MITRE ATT&CK T1055 – process injection).
  • Hunt for JIT anomalies and large outbound connections—classic signals of renderer exploits (Chrome IR guide).
  • Monitor SIEM/EDR for:
    • Spikes in outbound traffic from Chrome.
    • Unusual child process creation from chrome.exe/chromium.
    • Scripts leveraging vulnerable Electron versions.

• Typical exploit indicators:

  • Unexpected renderer crashes (heap overflow).
  • Chrome spawning shell or PowerShell processes (post-exploit payload).
  • Network beacons tied to suspicious domains.

Longer-Term Fixes

• Don’t stop at patching.
  • Enable Chrome’s site isolation for extra renderer containment.
  • Enforce auto-updates in enterprise GPOs or MDM.
  • Harden sandbox policies (Chromium docs).
  • Continuous fuzzing: Integrate with OSS-Fuzz, expand coverage for your web-facing components (see Chrome’s own fuzzing stats).
  • SBOM and inventory scanning: Use SPDX or CycloneDX, scan for vulnerable embedded Chromium/Electron.
  • Automate dependency alerts: Set up Dependabot, Renovate, or Snyk to catch supply chain vulnerabilities.
  • CI/CD: Fail builds if any key dependency lands a critical CVE (example: GitHub Actions with CVE check).

The Architecture Problem Nobody Wants to Fix

Chrome’s renderer and V8 are perpetual attack surfaces. Every zero-day patched is a symptom, not a cure. If your stack relies on Chromium-based frameworks, you’re inheriting upstream bugs—multiply the risk by every Electron release that lags behind Chrome’s cycle (see Electron’s update lag analysis).

The real vulnerability? Assuming Google’s defaults are enough. This week’s zero-days prove that architecture debt and supply chain rot keep biting—no matter how fast you patch.

So, What’s Next?

You can scramble for the latest update, audit yet another dependency tree, or set up real threat detection. Or you can keep pretending security is just a box you tick at release. Your call.