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

Integer overflow in Blink in Google Chrome prior to 149

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

This is picking the lock on the lobby door, not the vault behind it

CVE-2026-11171 is an integer overflow in Blink, Chrome's rendering engine, affecting Google Chrome before 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. A malicious site can feed crafted HTML to the renderer and achieve code execution *inside the renderer sandbox*, which means attacker code lands in a tightly constrained browser process rather than on the host OS outright.

The vendor-to-reality gap is meaningful here. NVD shows a CISA-ADP 8.8/HIGH CVSS vector, but Google's own release notes classify the bug as Medium, and the decisive reason is practical blast radius: this bug still needs user interaction and stops at sandboxed renderer execution unless the attacker brings a second bug, a sandbox escape, or a high-value browser-data objective.

"This is a renderer bug, not an endpoint takeover bug; the sandbox is the whole story here."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker HTML

The attacker needs a user running vulnerable Chrome to render a hostile page or embedded content. In practice this is phishing, malvertising, compromised sites, or an internal web app serving attacker-controlled markup. The weaponized component is simply crafted HTML/JS targeting Blink.
Conditions required:
  • Unauthenticated remote reachability to the user through web content
  • Victim uses Chrome below 149.0.7827.53/.54
  • User opens or renders the page
Where this breaks in practice:
  • Requires user interaction (UI:R), so there is no direct network self-propagation
  • Email gateways, Safe Browsing, web proxies, and browser isolation can break the lure before render
  • Enterprise users are usually spread across multiple browser versions because of auto-update cadence
Detection/coverage: Version-based scanners can flag vulnerable installs well. Network detection of the exploit itself is weak; most defenders will see only the lure URL, browser crash telemetry, or EDR exploit-guard signals.
STEP 02

Trigger Blink integer overflow

Once the page is rendered, the attacker drives a Blink code path into integer overflow and turns that into renderer-process code execution. The public bug tracker entry is still access-restricted, so there is no authoritative exploit recipe published. The weaponized tool here is a browser exploit page, not an off-the-shelf wormable service exploit.
Conditions required:
  • Precise trigger path reachable in the victim's platform/build
  • Exploit reliability against current mitigations
Where this breaks in practice:
  • Chrome's exploit mitigations, memory-safety hardening, and site isolation increase reliability costs
  • Restricted bug details slow opportunistic copycat exploitation
Detection/coverage: Exploit content is hard to signature. Crash spikes in chrome.exe/Google Chrome renderer processes, EDR memory-exploit detections, and sandbox violation telemetry are more realistic signals.
STEP 03

Execute inside the renderer sandbox

Successful exploitation gives code execution in a sandboxed renderer, not in the browser's privileged broker and not on the host with user rights by default. That sharply limits filesystem, device, and OS interaction, and it narrows impact to what the compromised renderer can reach. The official Chromium architecture is designed specifically to make this post-exploit state painful for attackers.
Conditions required:
  • Renderer compromise achieved
  • Target objective achievable from renderer context
Where this breaks in practice:
  • Sandbox prevents this CVE from being a one-bug workstation takeover
  • Site Isolation and process separation reduce cross-site data reach
  • A lot of modern endpoint controls trigger on browser child-process abuse or suspicious broker interactions
Detection/coverage: Local telemetry is stronger than perimeter telemetry here. Watch for renderer crashes followed by unusual Chrome child processes, broker requests, or credential/session abuse.
STEP 04

Turn browser foothold into meaningful enterprise impact

For host compromise, the attacker usually needs a second vulnerability such as a sandbox escape or another privilege boundary failure. Without that, the more realistic outcomes are same-session abuse, page-content manipulation, or theft of data already reachable inside the compromised process. This is where the CVSS label overstates the standalone business impact.
Conditions required:
  • Access to valuable browser-resident data or a second exploit primitive
  • Target user has high-value sessions open
Where this breaks in practice:
  • No public evidence of active chaining or in-the-wild exploitation as of 2026-06-05
  • No KEV listing
  • Many enterprises isolate admin activity away from daily browsing
Detection/coverage: There is no scanner that proves exploit chaining from this CVE alone. Hunt for suspicious browser session theft, token reuse, or anomalous follow-on process activity rather than the CVE in isolation.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence found of active exploitation as of 2026-06-05; not in CISA KEV. Chromium also keeps some bug details restricted until most users are updated, which limits public exploit insight but is not itself exploitation evidence.
Proof-of-concept availabilityNo public PoC or GitHub exploit repo located in primary-source searching. The Chromium issue for 502322843 is access-restricted, which usually suppresses quick copycat weaponization.
EPSS0.0008 (~0.08% 30-day exploitation probability). Percentile was not authoritatively verified from available primary-source data in this review.
KEV statusNo KEV listing found in the CISA catalog.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H from CISA-ADP in NVD. The important real-world caveat is UI:R plus sandboxed-only code execution.
Affected versionsGoogle Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS, per the Chrome stable release and NVD CPE entry.
Fixed versionsPatch level is Chrome 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS. For packaged environments, treat vendor or distro backports as authoritative if they preserve the vulnerable-code fix without bumping upstream-major version semantics.
Exposure realityThis is client-side and not meaningfully enumerable through Shodan/Censys/FOFA like a server bug. Exposure is your browser footprint and user browsing behavior, not an open internet service.
Disclosure timelineBug was reported by Google on 2026-04-13, Chrome stable shipped the fix on 2026-06-02, and the CVE/NVD publication landed on 2026-06-04.
Reporter / severity mismatchReported by Google. Chrome release notes rate it Medium, while NVD shows CISA-ADP 8.8/HIGH; that mismatch is the core reason for this downgrade.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.3/10)

The single decisive downgrade factor is that successful exploitation yields code execution inside Chrome's sandboxed renderer, not a clean host compromise. Combine that with required user interaction and the absence of KEV or public exploitation evidence, and this behaves like a serious browser bug that still lacks the second-stage primitive needed to justify a HIGH patch emergency on its own.

HIGH Affected version and fix version mapping
MEDIUM Assessment that standalone enterprise impact is limited by sandbox containment
MEDIUM No-public-PoC / no-public-exploitation conclusion from primary-source review

Why this verdict

  • Downward pressure: renderer sandbox means the bug stops at sandboxed code exec, so the CVSS host-impact assumptions are too generous for the standalone CVE
  • Downward pressure: user interaction required; this is not unauthenticated remote-to-service exploitation, it needs a victim to render attacker content
  • Downward pressure: no active exploitation signal; not KEV-listed and the supplied EPSS is extremely low
  • Upward pressure: huge fleet footprint; Chrome is ubiquitous, so even a sandboxed bug can matter at enterprise scale
  • Upward pressure: low attack complexity in theory once a victim visits the malicious page, so targeted phishing and drive-by delivery remain plausible

Why not higher?

It is not higher because this is not a one-CVE workstation takeover in the facts we have. The attack path requires user interaction, lands in a sandboxed renderer, and needs either valuable browser-resident data or a second bug to become full host compromise; that is too much compounded friction for HIGH in a 10,000-host enterprise queue.

Why not lower?

It is not lower because renderer compromise is still real code execution against one of the most widely deployed userland targets in the estate. Even sandboxed bugs can be operationally important for high-risk users, targeted phishing populations, and future exploit chains if a sandbox escape appears later.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update and version compliance — Use enterprise browser management to block lagging channels and verify all managed endpoints move to 149.0.7827.53/.54 or later. With a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers should still be kept on normal rapid-update policy because version drift is the easiest way these bugs stay exploitable.
  2. Apply browser isolation for high-risk users — Route internet browsing for admins, finance, executives, and exposed users through remote browser isolation or equivalent containment where available. For this MEDIUM verdict there is no mitigation SLA, so use this as risk reduction for sensitive populations while staying within the ≤365 day remediation horizon.
  3. Separate admin activity from daily browsing — Keep privileged accounts off general web browsing sessions so that a renderer compromise cannot immediately touch high-value admin cookies or workflows. There is no mitigation SLA for MEDIUM, but this control is worth standardizing because it shrinks the payoff of the bug even if exploitation happens.
  4. Keep Site Isolation and exploit protections enabled — Do not relax Chrome hardening flags or enterprise policies that weaken process isolation, sandboxing, or Safe Browsing. There is no mitigation SLA here, but preserving those defaults is one of the main reasons this CVE reassesses downward in the first place.
What doesn't work
  • A perimeter WAF does not help; the exploit is delivered as client-rendered web content in the user's browser, not against your server endpoint.
  • Generic network vulnerability scanning will not prove exploitability; this is a local browser version problem, not an internet-facing socket problem.
  • MFA does not stop the initial exploit path; it helps with follow-on session abuse, but it does not prevent the renderer bug from triggering.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or from your software-audit tooling on each host. Invoke it with python3 check_chrome_cve_2026_11171.py on macOS/Linux or py check_chrome_cve_2026_11171.py on Windows; no admin rights are required unless your EDR blocks process version queries.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11171.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

PATCHED = (149, 0, 7827, 53)

WINDOWS_CANDIDATES = [
    r"C:\Program Files\Google\Chrome\Application\chrome.exe",
    r"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe",
    os.path.expandvars(r"%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe"),
]

MAC_CANDIDATES = [
    "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
    os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
]

LINUX_CANDIDATES = [
    which("google-chrome"),
    which("google-chrome-stable"),
    which("chromium-browser"),
    which("chromium"),
    "/opt/google/chrome/chrome",
    "/usr/bin/google-chrome",
    "/usr/bin/google-chrome-stable",
]


def parse_version(text):
    m = re.search(r"(\d+)\.(\d+)\.(\d+)\.(\d+)", text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def version_string(v):
    return ".".join(str(x) for x in v)


def compare_versions(a, b):
    return (a > b) - (a < b)


def get_candidates():
    system = platform.system().lower()
    if system == "windows":
        return [p for p in WINDOWS_CANDIDATES if p]
    if system == "darwin":
        return [p for p in MAC_CANDIDATES if p]
    return [p for p in LINUX_CANDIDATES if p]


def get_version_from_binary(path):
    try:
        out = subprocess.check_output([path, "--version"], stderr=subprocess.STDOUT, text=True, timeout=10)
        return parse_version(out)
    except Exception:
        return None


def main():
    candidates = get_candidates()
    existing = [p for p in candidates if p and os.path.exists(p)]

    if not existing:
        print("UNKNOWN: Chrome binary not found in standard locations")
        sys.exit(2)

    for path in existing:
        version = get_version_from_binary(path)
        if version is None:
            continue

        status = "PATCHED" if compare_versions(version, PATCHED) >= 0 else "VULNERABLE"
        print(f"{status}: {path} version {version_string(version)} (fixed: {version_string(PATCHED)})")
        sys.exit(0 if status == "PATCHED" else 1)

    print("UNKNOWN: Chrome found but version could not be determined")
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning, query your fleet for Chrome versions and clean up laggards, but do not treat this like a one-bug endpoint-RCE fire drill. For a MEDIUM verdict there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤365 days, though in practice browser auto-update policy should bring users to 149.0.7827.53/.54 far sooner. If you have high-risk browsing populations, use isolation and admin/session separation now while you let normal browser patch governance finish the rollout.

Sources

  1. NVD entry for CVE-2026-11171
  2. Chrome Stable Channel Update for Desktop
  3. Chromium issue 502322843
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. Chromium Security page
  7. Chromium Site Isolation overview
  8. Chrome sandbox diagnostics for Windows
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.