← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11124 · CWE-122 · Disclosed 2026-06-04

Integer overflow in Skia in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a cracked windshield on every company car: one bad road can hit a lot of drivers, but most crashes still stop at the glass

CVE-2026-11124 is a client-side memory-corruption bug in Chrome's Skia rendering stack. The CNA record says an *integer overflow* can lead to heap corruption from a crafted HTML page in Google Chrome versions earlier than 149.0.7827.53; Google shipped the fix in the Chrome 149 stable release for Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54. There is a minor metadata mismatch worth noting: Google's release post labels the entry as *heap buffer overflow in Skia*, while the CVE text describes an *integer overflow* that can cause heap corruption.

Google's own severity label is *Medium*, and that is understandable if you score only the immediate bug and assume the browser sandbox holds. In enterprise reality, though, this lands higher: Chrome is everywhere, delivery is cheap for attackers because normal browsing is enough, and rendering bugs are exactly the class that turns malvertising or phishing clicks into initial footholds. The main downward pressures are real too: user interaction is required, there is no public in-the-wild exploitation in the sources reviewed, and the likely first-stage impact is renderer compromise rather than instant full-host takeover.

"Assessed at HIGH: one malicious page can hit a huge Chrome fleet, but sandboxing and no exploit evidence keep it below critical."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious page

The attacker hosts or injects a crafted page that exercises Skia rendering paths through normal browser content. The practical delivery vehicle is boring: phishing link, malvertising, compromised site, or a chat message that gets a user to load the page. No authentication to the target host is needed because the browser is the parser.
Conditions required:
  • Victim uses Chrome earlier than 149.0.7827.53
  • Victim loads attacker-controlled or attacker-influenced web content
  • Network controls do not fully block the destination
Where this breaks in practice:
  • Requires user interaction or at least a browser navigation event
  • Web filtering, Safe Browsing, DNS controls, and mail security can cut down delivery volume
  • Attackers still need a trigger that reaches the vulnerable Skia code path reliably
Detection/coverage: Network and email tooling may catch the lure, but vulnerability scanners only prove version state; they do not see exploit delivery.
STEP 02

Trigger the Skia overflow

Once the page renders, weaponized HTML/JS/SVG/canvas content attempts to force the vulnerable Skia path into integer overflow and heap corruption. This is the exploit's technical hinge: if the crafted content only crashes the renderer, the attacker gets noise; if it creates controlled corruption, they get execution primitives inside the browser sandbox.
Conditions required:
  • The affected Skia code path is reachable on the victim platform/build
  • Heap layout and content shape line up for corruption
  • The browser has not already been updated
Where this breaks in practice:
  • Renderer exploitation reliability varies by platform, allocator state, and hardening level
  • Modern Chrome mitigations raise the bar from crash to code execution
  • Metadata only says 'potentially exploit heap corruption,' not proven RCE
Detection/coverage: EDR may log repeated Chrome crashes or abnormal renderer instability, but there is no dependable network signature for the trigger itself.
STEP 03

Gain execution in the renderer sandbox

If the attacker gets controlled heap corruption, the likely first meaningful outcome is code execution inside Chrome's renderer process. That is enough to steal page-local data, script the session, or stage a second bug, but it is still inside Chrome's sandbox boundary rather than full native admin-level compromise.
Conditions required:
  • Successful memory-corruption exploitation rather than a simple crash
  • Mitigations such as allocator hardening, CFG, and ASLR are bypassed or worked around
  • The attacker can operate within the renderer's privileges
Where this breaks in practice:
  • Chrome sandboxing and site isolation materially reduce immediate blast radius
  • Same-origin and broker boundaries still matter after renderer compromise
  • A lot of real-world exploit attempts die here
Detection/coverage: Behavioral EDR may catch suspicious Chrome child-process behavior or in-memory post-exploitation activity, but pure version scanners cannot.
STEP 04

Chain for higher impact

To convert this from browser compromise into durable endpoint compromise, the attacker usually needs a second stage: sandbox escape, credential theft from reachable browser context, or user-session abuse. That chaining requirement is the biggest reason this is not a critical fleet emergency on its own.
Conditions required:
  • Attacker already achieved renderer execution
  • A second vulnerability or a usable post-exploitation path exists
  • The victim session has valuable data or reachable enterprise apps
Where this breaks in practice:
  • Separate sandbox-escape bugs are uncommon and valuable
  • EDR, application control, and browser isolation can break the follow-on stage
  • Impact can stay confined to the browser session instead of the whole host
Detection/coverage: Post-exploitation is where defenders have the best shot: EDR telemetry, unusual token/session reuse, and abnormal browser child processes.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence in the reviewed sources, and not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC or exploit repository surfaced in the reviewed sources. The Chromium issue is still access-restricted, which is typical while adoption of the fix catches up.
EPSS0.00035 from the user-supplied intel; that is very low threat likelihood. Percentile was not present in the material reviewed.
KEV statusNot KEV-listed in the CISA Known Exploited Vulnerabilities Catalog.
Vendor severityChromium labels it Medium in the release advisory and CVE text.
CVSS / vector situationThere is no published vendor or authority CVSS for this CVE. *Inference only:* adjacent same-release Chrome memory-corruption CVEs on NVD commonly receive CISA-ADP 8.8 with CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, but that vector was not authoritatively published for CVE-2026-11124 in the sources reviewed.
Affected versionsGoogle Chrome earlier than 149.0.7827.53. The desktop stable announcement explicitly covers Windows, macOS, and Linux.
Fixed versionsDesktop stable fix landed in Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54. Chrome for Android 149.0.7827.59 states it includes the same desktop security fixes unless otherwise noted.
Scanning / exposure realityShodan/Censys-style internet exposure counts are not meaningful here because Chrome is endpoint software, not an internet-addressable edge service. Your exposure is your installed browser fleet, not your public IP space.
Disclosure / reportingCVE published 2026-06-04; Google's release post shows it was reported by Google on 2026-04-10.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to HIGH (7.5/10)

The decisive amplifier is reachability at scale: any attacker who can get a user to open a page can target a browser that exists on nearly every endpoint in the fleet. The decisive brake is that this is still a sandboxed, user-interaction-dependent browser bug with no public exploitation evidence, so it does not justify a critical emergency posture by itself.

MEDIUM Severity assessment without an authoritative CVSS baseline
HIGH Affected version range and fixed builds
MEDIUM Attack-path judgment about likely renderer-first impact

Why this verdict

  • Massively exposed client surface: Chrome is ubiquitous, and the attacker position is only *unauthenticated remote plus user browse event*. That means a wide reachable population across enterprise endpoints, not a niche admin-only feature.
  • Low delivery cost, not low exploit cost: the attacker can deliver via ordinary web content, phishing, ads, or compromised sites, so perimeter controls do not eliminate the risk. I adjusted the score upward because the first hop does not require credentials, internal access, or special roles.
  • Sandbox is real downward pressure: successful exploitation likely starts in the renderer, which implies constrained privileges and often requires a second bug for full-host compromise. I adjusted the score downward for that compounding friction.
  • No active exploitation signal: EPSS is extremely low and the CVE is not in KEV. That removes the biggest reason to call this critical.
  • Vendor medium is a bit too calm for fleet prioritization: for a 10,000-host enterprise, one-click browser memory corruption on a universal app deserves faster attention than a generic medium backlog item, even if the browser sandbox keeps it from being top-shelf emergency patching.

Why not higher?

There is no evidence in the reviewed sources that this is being exploited in the wild, and there is no public PoC raising the immediate copycat risk. More importantly, the likely first-stage win is inside Chrome's sandboxed renderer, not an automatic full endpoint takeover, so the blast radius is meaningfully constrained unless the attacker can chain another flaw.

Why not lower?

Scoring this as medium would underweight the real exposure population: browser rendering bugs are one of the cleanest ways to touch a huge endpoint fleet with almost no attacker-side prerequisites. Even with the sandbox, a remotely delivered memory-corruption bug in a universally deployed browser is too operationally important to treat as routine backlog hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Enforce rapid Chrome auto-update — Make sure enterprise policy does not defer stable-channel browser updates longer than necessary, and verify endpoints are actually pulling 149.0.7827.53 or later. For a HIGH verdict, get this enforced within 30 days where patching is lagging.
  2. Block unmanaged or stale browser versions — Use MDM, EDR, NAC, or conditional access to identify and restrict endpoints still running older Chrome builds. This reduces the reachable population while the fleet converges, and for a HIGH verdict the control should be in place within 30 days.
  3. Harden web-content delivery paths — Tighten DNS filtering, secure web gateway policy, Safe Browsing enforcement, and ad/malware category blocking to cut off common delivery channels like phishing pages and malvertising. These are compensating controls, not fixes, and they should be tuned within 30 days.
  4. Prefer browser isolation for high-risk users — For administrators, finance, help desk, and users with broad SaaS access, route untrusted browsing through remote browser isolation if you have it. That meaningfully reduces exploit usefulness during the patch convergence period and should be prioritized within 30 days for exposed groups.
What doesn't work
  • A WAF does not help here because the vulnerable parser is the client's browser, not your server.
  • MFA is good hygiene but does nothing to stop the initial memory-corruption trigger from a malicious page.
  • Network vulnerability scanning alone is weak coverage because it can inventory version state on managed assets but cannot detect exploit attempts or prove renderer-path reachability.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it with python3 chrome_cve_2026_11124_check.py on macOS/Linux or py chrome_cve_2026_11124_check.py on Windows; no admin rights are normally required, but elevated rights can help if Chrome is installed system-wide in nonstandard paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11124 Chrome version check
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple

PATCH_VERSION = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def find_windows_version() -> Optional[Tuple[int, int, int, int]]:
    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
    ]
    powershell = shutil.which('powershell') or shutil.which('pwsh')
    for path in candidates:
        if os.path.exists(path) and powershell:
            script = f"(Get-Item '{path}').VersionInfo.ProductVersion"
            out = run_cmd([powershell, '-NoProfile', '-Command', script])
            v = parse_version(out)
            if v:
                return v
    return None


def find_macos_version() -> Optional[Tuple[int, int, int, int]]:
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for path in candidates:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                return v
    return None


def find_linux_version() -> Optional[Tuple[int, int, int, int]]:
    candidates = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    for exe in candidates:
        path = shutil.which(exe)
        if path:
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                return v
    return None


def compare_versions(found: Tuple[int, int, int, int], fixed: Tuple[int, int, int, int]) -> int:
    if found < fixed:
        return -1
    if found > fixed:
        return 1
    return 0


def main():
    system = platform.system().lower()
    version = None

    if 'windows' in system:
        version = find_windows_version()
    elif 'darwin' in system or 'mac' in system:
        version = find_macos_version()
    elif 'linux' in system:
        version = find_linux_version()

    if not version:
        print('UNKNOWN: Could not determine installed Chrome/Chromium version')
        sys.exit(2)

    cmp_result = compare_versions(version, PATCH_VERSION)
    version_str = '.'.join(str(x) for x in version)
    fixed_str = '.'.join(str(x) for x in PATCH_VERSION)

    if cmp_result < 0:
        print(f'VULNERABLE: Detected version {version_str} < fixed baseline {fixed_str}')
        sys.exit(1)
    else:
        print(f'PATCHED: Detected version {version_str} >= fixed baseline {fixed_str}')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a high-priority browser fleet update, not a pager-worthy zero-day. Inventory every endpoint still running Chrome earlier than 149.0.7827.53, push the stable build through your browser rings immediately, and use policy controls to squeeze down unmanaged or stale versions within 30 days under the noisgate mitigation SLA; finish full remediation across the fleet within 180 days under the noisgate remediation SLA. If you already have fast browser update machinery, this should be in the next rollout wave, not left to normal medium-severity drift.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop
  2. Chromium issue 501511299
  3. CIRCL Vulnerability-Lookup search entry for CVE-2026-11124
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data and stats
  6. Chromium Security Page
  7. NVD entry for adjacent same-release Chrome CVE-2026-11164
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.