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

Inappropriate implementation in Safe Browsing in Google Chrome prior to 149

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

This is a guardrail with a gap in it, not a missing wall

CVE-2026-11210 is a Safe Browsing policy/access-control bypass in desktop Google Chrome. Per Google/NVD, affected builds are Chrome before 149.0.7827.53; the fixed builds are 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. The published trigger is a crafted RAR file, so this is not a generic web-page memory corruption bug; the attacker needs the victim to encounter a specific archive-handling path.

The vendor's MEDIUM 6.5 is technically defensible in CVSS terms, but it overstates enterprise urgency. In the real world this is a user-driven, client-side, defense-in-depth bypass with no public sign of in-the-wild exploitation, no public PoC located, and no disclosed path to full code execution by itself. For a team managing 10,000 hosts, this belongs in backlog hygiene, not the emergency lane.

"Client-side Safe Browsing bypass plus crafted RAR and user interaction makes this patchable, not panic-worthy"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the archive

The attacker has to deliver a crafted RAR to a Chrome user, typically with commodity tooling such as a phishing kit or a drive-by download page. There is no CVE-specific public exploit kit identified in the sources; delivery is the hard part, not exploit automation.
Conditions required:
  • Attacker can reach a user by email, chat, ad, or web lure
  • Target uses desktop Chrome below 149.0.7827.53
  • Target is willing to download or interact with the archive
Where this breaks in practice:
  • Secure email gateways often quarantine or strip RAR attachments
  • Web proxies and browser isolation reduce archive delivery success
  • User interaction is mandatory, which kills mass reliability
Detection/coverage: Vulnerability scanners can version-check Chrome, but they cannot validate exploitability from the network. Detection is mostly in mail/web telemetry and download logs.
STEP 02

Trigger the Safe Browsing bypass

Chrome processes the crafted archive through the affected Safe Browsing path. The bug is described by Google as insufficient policy enforcement / inappropriate implementation, meaning the attacker is bypassing a browser safety control rather than corrupting memory or escaping a sandbox.
Conditions required:
  • Victim receives the crafted archive through Chrome's download flow
  • The relevant Safe Browsing decision path is reached
Where this breaks in practice:
  • Bug details remain restricted in Chromium's tracker, limiting attacker reproducibility
  • Archive inspection, content disarm, and endpoint AV reduce success
Detection/coverage: Expect version-based coverage only from standard vuln scanners. Runtime detection would rely on download telemetry, Safe Browsing events, archive inspection, and EDR alerts on follow-on file activity.
STEP 03

Abuse the bypassed control

If the bypass works, the attacker gains whatever the weakened Chrome control was meant to prevent in that archive path. Based on the published CVSS and description, the likely impact is integrity-only within the user workflow, not direct OS-level compromise.
Conditions required:
  • The bypass must actually weaken a meaningful enterprise policy or trust decision
  • The user or a follow-on process must act on the delivered content
Where this breaks in practice:
  • The CVE does not disclose a direct RCE or sandbox-escape outcome
  • EDR, Mark-of-the-Web handling, application control, and attachment detonation still sit downstream
Detection/coverage: Look for follow-on archive extraction, child-process launches from downloaded content, and policy-violation events. The bypass itself is harder to observe than the post-download behavior.
STEP 04

Impact stays in the user lane

The practical blast radius is the current user's browser and file workflow, unless chained with another vulnerability or a weak endpoint policy. That makes this materially different from a one-click browser RCE, sandbox escape, or credential theft zero-day.
Conditions required:
  • A second failure or unsafe user action is needed for bigger impact
Where this breaks in practice:
  • No active exploitation evidence in the cited sources
  • No public chain to system compromise is disclosed
Detection/coverage: SOC visibility is better on the chained payload than on this CVE itself. Treat it as a precursor signal, not a standalone intrusion signature.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current exploitation evidence in the cited primary sources. Not in CISA KEV, and Google did not flag it as exploited.
Proof-of-concept availabilityNo public PoC located in the reviewed primary sources/searches. Chromium bug details are still restricted, which raises attacker friction.
EPSS0.0002 from the prompt, which is effectively negligible as a 30-day exploitation signal. Percentile was not supplied in the prompt and not verified from a primary EPSS response.
KEV statusNot KEV-listed. CISA's catalog page does not list CVE-2026-11210; there is therefore no KEV date-added or due date.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N = remote delivery is possible, but user interaction is required and the disclosed impact is integrity-only, not confidentiality loss or availability hit.
Affected versionsDesktop Chrome before 149.0.7827.53. NVD's CPE mapping ties this to Windows, Linux, and macOS desktop Chrome.
Fixed versionsLinux: 149.0.7827.53. Windows/macOS: 149.0.7827.53/.54 per Google's stable release post.
Scanning / exposure realityShodan/Censys/FOFA-style internet exposure metrics are basically irrelevant here because this is endpoint browser software, not an internet-facing service. GreyNoise-style scanner activity is also a poor fit for a client-side archive-triggered bug.
Disclosure timelineReported by Google on 2026-04-25 in the Chrome release notes; publicly disclosed 2026-06-04 in the CVE/NVD records; NVD added CPEs on 2026-06-05.
Researcher / reporterGoogle is the named reporter in the Chrome stable channel advisory entry for this CVE. No external researcher attribution is published in the visible advisory text.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.9/10)

The deciding factor is that this is a client-side control bypass that still needs user interaction with a crafted RAR, not a no-click browser compromise. Chrome is everywhere, but the reachable exploit path is narrow and the publicly disclosed impact does not show a direct route to code execution or tenant-wide blast radius.

HIGH Affected version range and fixed builds
MEDIUM Severity downgrade based on real-world attacker friction
LOW Exact post-bypass abuse potential because Chromium bug details are restricted

Why this verdict

  • User interaction cuts this down: the attacker needs a victim to receive and engage with a crafted RAR, which implies phishing or a download lure rather than blind internet exploitation.
  • Archive-specific delivery narrows the population: many enterprises block, detonate, or heavily inspect RAR files at mail gateways, proxies, and endpoints.
  • This is a defense-in-depth bypass, not a published RCE: the disclosed outcome is access-control/policy bypass with integrity impact, not arbitrary code execution, sandbox escape, or credential theft by itself.
  • Threat intel is quiet: no KEV listing, no public exploitation callout from Google, and the provided EPSS 0.0002 says attackers are not obviously prioritizing this.
  • Chrome ubiquity stops this from being IGNORE: the browser footprint is huge, and weakening Safe Browsing on thousands of endpoints is still worth closing during normal hygiene.

Why not higher?

To rate higher, I would need either active exploitation, public exploit tooling, or a disclosed path to reliable code execution / sandbox escape / credential theft. None of that is in the primary sources. The attacker also has to clear too many ordinary enterprise controls first: delivery, user action, archive handling, and downstream endpoint controls.

Why not lower?

I am not calling this IGNORE because Chrome is a massively deployed endpoint platform and Safe Browsing exists in a very attacker-relevant part of the chain: getting bad content onto user systems. Even a control bypass with modest standalone impact can become useful when chained with weak archive handling, poor application control, or a second-stage social-engineering payload.

05 · Compensating Control

What to do — in priority order.

  1. Block or detonate RAR at the edge — If your mail gateway, SWG, or sandbox supports archive policy, block or detonate RAR downloads and attachments for standard users. For a LOW verdict there is no SLA (treat as backlog hygiene), so fold this into normal policy tuning rather than emergency change windows.
  2. Enforce Chrome evergreen updates — Make sure enterprise policy is not pinning outdated Chrome builds and that update rings actually move endpoints to 149.0.7827.53+. For LOW, there is no SLA (treat as backlog hygiene); this should ride your standard browser maintenance cycle.
  3. Tighten archive execution controls — Use EDR, application control, ASR, Gatekeeper, or equivalent controls to stop downloaded archive contents from launching freely in user context. That matters because this CVE is most useful to attackers when it can be chained with unsafe post-download execution behavior.
  4. Monitor download-and-extract chains — Alert on Chrome-originated RAR downloads followed by extraction and child-process launches from temp/download locations. This is the best operational signal because the CVE itself is hard to observe directly.
What doesn't work
  • A WAF does not help; this is not a server-side web app exposure.
  • Perimeter network vulnerability scanning does not meaningfully validate exploitability here; it can only inventory browser versions if you have agent or authenticated host access.
  • Relying on Safe Browsing alone is the wrong lesson; this bug is specifically about a Safe Browsing enforcement gap.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/RMM script runner; it needs only standard user privileges because it reads local app metadata. Save it as check_cve_2026_11210.py and run python3 check_cve_2026_11210.py on Linux/macOS or py check_cve_2026_11210.py on Windows; it will print VULNERABLE, PATCHED, or UNKNOWN and exit with 1, 0, or 2 respectively.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check Google Chrome version for CVE-2026-11210
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


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


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


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 get_windows_version():
    try:
        import winreg
    except Exception:
        return None, None

    reg_paths = [
        (winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
    ]

    for hive, path in reg_paths:
        try:
            with winreg.OpenKey(hive, path) as key:
                version, _ = winreg.QueryValueEx(key, 'version')
                pv = parse_version(version)
                if pv:
                    return version, 'registry:' + path
        except Exception:
            pass

    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'),
    ]
    for exe in candidates:
        if exe and os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            pv = parse_version(out)
            if pv:
                return '.'.join(str(x) for x in pv), exe
    return None, None


def get_macos_version():
    app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(app):
        out = run_cmd([app, '--version'])
        pv = parse_version(out)
        if pv:
            return '.'.join(str(x) for x in pv), app
    return None, None


def get_linux_version():
    cmds = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
    ]
    for cmd in cmds:
        out = run_cmd(cmd)
        pv = parse_version(out)
        if pv:
            return '.'.join(str(x) for x in pv), cmd[0]
    return None, None


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

    if 'windows' in system:
        version, source = get_windows_version()
    elif 'darwin' in system:
        version, source = get_macos_version()
    elif 'linux' in system:
        version, source = get_linux_version()

    if not version:
        print('UNKNOWN - Google Chrome version not found on this host')
        sys.exit(2)

    pv = parse_version(version)
    if not pv:
        print(f'UNKNOWN - Unable to parse version: {version}')
        sys.exit(2)

    if cmp_ver(pv, FIXED) < 0:
        print(f'VULNERABLE - Detected Chrome {version} via {source}; fixed version is 149.0.7827.53 or later')
        sys.exit(1)
    else:
        print(f'PATCHED - Detected Chrome {version} via {source}; fixed version is 149.0.7827.53 or later')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: do not burn an emergency lane on this one. Inventory Chrome versions, let your normal browser evergreen process move endpoints to 149.0.7827.53+, and, if you have cheap policy wins, tighten RAR handling at mail/web boundaries. Because this is LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene; fold it into the next standard browser update wave and validate closure with endpoint version checks rather than incident-style response.

Sources

  1. NVD CVE-2026-11210
  2. Google Chrome Stable Channel Update for Desktop
  3. Chromium issue 506473226
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. CVE.org record
  8. CIRCL Vulnerability Lookup entry
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.