Active Exploitation Detected: Chrome Zero-Days (Skia & V8)
Hey everyone,
Just saw the update drop from Google regarding two Chrome zero-days actively exploited in the wild. While details are somewhat limited (as usual to prevent wider abuse), we have specifics on CVE-2026-3909.
CVE-2026-3909 (CVSS 8.8) is an out-of-bounds (OOB) write vulnerability in the Skia 2D graphics library. The attack vector involves a remote attacker using crafted HTML to trigger OOB memory access. The second zero-day impacts the V8 JavaScript engine, though the specific CVE for that one wasn't detailed in the initial advisory.
Given the "in the wild" designation, patching should be treated as an emergency. If you manage fleets, you need to verify you are on the latest version immediately.
For those of us who can't rely solely on auto-updates due to enterprise policies, here is a quick PowerShell snippet to check the Chrome version on your endpoints:
$chromePath = "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe"
if (Test-Path $chromePath) {
$version = (Get-Item $chromePath).VersionInfo.ProductVersion
Write-Host "Current Chrome Version: $version"
} else {
Write-Host "Chrome not found at standard path."
}
Are you seeing any specific IOCs related to the Skia exploitation in your telemetry yet, or are we mostly flying blind on detection signatures right now?
From a SOC perspective, we're prioritizing alerts for chrome.exe spawning child processes (specifically cmd or powershell) over the next few days. Browser sandbox escapes often hinge on that post-exploitation activity. The Skia vulnerability is particularly nasty because it affects the rendering pipeline, meaning just viewing a malicious page is enough. We've updated our EDR policies to flag any unusual memory allocations tied to the Chrome renderer process.
The Skia OOB write reminds me of the older Font parsing bugs. It's complex to exploit but high reward. For my pentesting clients, I'm advising them to check if their Extended Stable versions are patched, as enterprise builds often lag behind. Usually, V8 bugs are easier to weaponize than graphics libs, so I'm curious to see if the V8 zero-day is actually the primary delivery method here.
I run an MSP and this is exactly why we enforce the 'Auto-update on restart' policy via Group Policy. It's a pain for users when they have to restart, but it beats explaining a ransomware infection. If you can't push updates instantly, consider blocking untrusted Flash/HTML content at the proxy level as a temporary mitigation while you deploy the patches.
Great insights, everyone. For teams needing immediate visibility into their exposure before the auto-update cycle completes, querying the registry is often faster than waiting for asset inventory updates.
You can use this PowerShell snippet to check the Chrome version on local machines:
Get-ItemProperty 'HKLM:\Software\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}' | Select-Object pv
Does anyone have a list of specific hash indicators for the malicious HTML payloads yet?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access