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

Inappropriate implementation in Downloads in Google Chrome prior to 149

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

This is a fake badge on the download door, not a master key to the building

CVE-2026-11107 is a Downloads UI spoofing flaw in Google Chrome caused by inappropriate implementation in the Downloads component. A remote attacker can use a crafted HTML page to make Chrome present misleading download-related UI, which can trick a user about what file is being downloaded or what action they are approving. Affected versions are Chrome prior to 149.0.7827.53; Google's stable rollout notes show 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS as the fixed train.

Google's MEDIUM 4.3 label is technically fair in CVSS terms, but operationally it is still below the line for urgent enterprise disruption. The exploit chain stops at deception: the attacker still needs a user to visit the page, believe the fake UI, and take a follow-on action, and the bug by itself does not provide code execution, sandbox escape, account takeover, or a security-boundary break.

"A spoofed download prompt can help phishing, but this is not a code-exec fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a crafted web page using plain browser primitives

The attacker hosts or sends a malicious page using ordinary HTML/JS/CSS; no special exploit kit is required based on currently public information. The page is the weaponized delivery tool here, and the Chromium advisory describes the trigger simply as a crafted HTML page.
Conditions required:
  • Unauthenticated remote reachability to a target user
  • User must open attacker-controlled content in vulnerable Chrome
  • Chrome version is below 149.0.7827.53
Where this breaks in practice:
  • Email gateways, browser isolation, URL filtering, and user suspicion all reduce opens
  • Enterprise Chrome often auto-updates quickly, shrinking the vulnerable population
  • There is no evidence of a public turnkey exploit kit for this CVE
Detection/coverage: Network scanners will miss this because it is a client-side browser flaw. Detection is mostly indirect: web proxy logs, phishing telemetry, EDR browser-child-process chains, and local version inventory.
STEP 02

Trigger spoofed Downloads UI inside Chrome

Once rendered, the malicious page abuses the Downloads component's flawed UI handling to present misleading download-related signals. The practical effect is user-interface deception, not memory corruption or policy escape.
Conditions required:
  • The victim must remain on the page long enough for the spoof to render
  • The specific UI path must still be reachable in the user's browser state
Where this breaks in practice:
  • Modern browser UX, Safe Browsing warnings, and pop-up restrictions can break or blunt the illusion
  • UI spoofing is brittle across window size, locale, theme, and OS chrome differences
Detection/coverage: There is no reliable signature-only network pattern. Browser hardening policies and safe-browsing events are more useful than content scanning.
STEP 03

Convert deception into a user action

The attacker only gets value if the victim believes the spoof and takes a next step such as approving a download, opening a file, or trusting a fake security indicator. This is the decisive friction point: exploitation depends on successful social engineering, not just technical reachability.
Conditions required:
  • User interaction is required
  • The spoof must be convincing in the victim's environment
Where this breaks in practice:
  • MFA, download restrictions, SmartScreen/Gatekeeper, and application control often stop the follow-on objective
  • Awareness training and browser familiarity reduce conversion rates
Detection/coverage: Good telemetry shows the follow-on, not the spoof itself: suspicious downloads, unsigned binaries launched from user download paths, or credential capture attempts after browser activity.
STEP 04

Land the real payload outside the vulnerability

Any meaningful impact—malware execution, credential theft, or consent phishing—comes from the next stage payload or workflow the attacker chains after the spoof. CVE-2026-11107 is therefore an attack amplifier for phishing and malicious-download campaigns, not a standalone host-compromise primitive.
Conditions required:
  • Attacker has a separate payload or fraud objective
  • Endpoint or identity controls fail to stop the next step
Where this breaks in practice:
  • EDR, app allowlisting, sandbox detonation, and identity protections routinely stop post-download abuse
  • Blast radius is per-user and non-wormable
Detection/coverage: High detection coverage exists for post-download execution and credential phishing. Coverage is much weaker for the initial UI-spoof step itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in reviewed primary sources, and Google did not attach an exploited-in-the-wild warning in the release notes.
KEV statusNot listed in CISA KEV as of the current catalog review; that materially lowers urgency versus browser zero-days with confirmed abuse.
Proof-of-concept availabilityNo public PoC or exploit repo found in reviewed primary-source references. The Chromium bug reference exists, but bug details are restricted.
EPSS0.00035 (about 0.035% probability over 30 days per the user-supplied intel). That is extremely low and lines up with the absence of exploit reporting.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N means remote reachability with no auth, but it still needs user interaction and only claims low integrity impactno confidentiality or availability impact.
Affected versionsGoogle Chrome before 149.0.7827.53; the CVE record and Chrome release notes tie the fix to the Chrome 149 stable train.
Fixed versions149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS per Google's Chrome 149 stable rollout and early-stable notes.
Exposure / scanning realityThis is a client-side browser issue, so Shodan/Censys/FOFA-style internet exposure counts are not meaningful. You need endpoint version inventory, not perimeter scanning.
Disclosure and reporting timelineCVE publication landed on 2026-06-04; Google shipped Chrome 149 stable on 2026-06-02 and lists this bug as reported by Google on 2026-04-08.
Researcher / reporting orgGoogle is listed as the reporter in the Chrome release notes; no external researcher credit or bug bounty is shown for this CVE.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

The decisive downgrade factor is the mandatory user-belief step: the bug only creates misleading Downloads UI and still needs a victim to trust it and act. In a 10,000-host enterprise, that makes this a social-engineering multiplier, not a reliable direct-compromise path, and modern endpoint and identity controls usually have another chance to stop the kill chain afterward.

HIGH Severity bucket driven by attacker-position and user-interaction friction
MEDIUM Exact exploit mechanics inside the restricted Chromium bug

Why this verdict

  • User interaction is the real gate: the attacker is remote and unauthenticated, but exploitation still requires the victim to open hostile content and believe spoofed download UI.
  • No direct compromise primitive: this bug provides UI deception only; it does not itself grant code execution, sandbox escape, credential theft, or policy bypass with durable host impact.
  • Broad deployment, narrow blast radius: Chrome is everywhere, but exploitation is one-user-at-a-time and non-wormable, so exposure breadth does not translate into emergency patch priority.

Why not higher?

There is no KEV listing, no reviewed evidence of active exploitation, and no public PoC that would make this a fast-moving campaign enabler. More importantly, the vulnerability's effect ends at spoofing; the attacker still needs a second-stage payload or phishing objective and another user decision.

Why not lower?

This is still a real security weakness in a ubiquitous client application, and convincing download UI spoofing can materially improve phishing or malware-delivery conversion rates. On populations with weak browser update hygiene or permissive download execution, the business risk is not zero.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update and relaunch — Make sure enterprise policy forces Chrome onto the fixed 149 train and actually relaunches long-lived sessions so the patched binary is in use. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and close it during normal browser maintenance.
  2. Harden download handling — Use Chrome enterprise policies, secure web gateway rules, and attachment controls to restrict risky file types from webmail, chat, and newly observed domains. This directly cuts the payoff of a spoofed Downloads prompt and is appropriate as standard hygiene rather than an urgent exception action.
  3. Block execution from user download paths — Use AppLocker, WDAC, Gatekeeper, or equivalent endpoint controls so a tricked user cannot easily convert a spoofed download into code execution. This is the best compensating layer because it attacks the post-spoof stage where most real harm occurs.
  4. Watch for browser-to-payload pivots — Tune EDR analytics for browser-originated downloads followed by execution from Downloads, temp paths, disk images, scripts, or archive extraction chains. That is where you will actually catch abuse if someone uses this flaw in a phishing flow.
What doesn't work
  • A WAF does not meaningfully solve this; the problem is client-side browser UI rendering, not a server request pattern you can reliably normalize away.
  • External internet exposure scanners do not help because there is no listening service to fingerprint; you need endpoint version inventory.
  • Generic phishing awareness alone is not enough because the whole point of the bug is to make malicious download flows look more trustworthy.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR live-response shell. Invoke it as python3 chrome_cve_check.py for auto-discovery or python3 chrome_cve_check.py --version 149.0.7827.52 / python3 chrome_cve_check.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; local user privileges are usually enough, though some locked-down systems may require elevated read access to program files.

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

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

PATCHED_MIN = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def parse_ver(s):
    if not s:
        return None
    m = VERSION_RE.search(s)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def ver_to_str(v):
    return '.'.join(str(x) for x in v)


def is_patched(v):
    return v >= PATCHED_MIN


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 candidate_paths():
    system = platform.system().lower()
    paths = []

    if 'windows' in system:
        envs = [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]
        rels = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe'
        ]
        for base in envs:
            if base:
                for rel in rels:
                    paths.append(os.path.join(base, rel))
    elif 'darwin' in system:
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            '/Applications/Chromium.app/Contents/MacOS/Chromium'
        ])
    else:
        paths.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
            '/snap/bin/chromium'
        ])

    return [p for p in paths if p and os.path.exists(p)]


def detect_version_from_path(path):
    out = run_cmd([path, '--version'])
    return parse_ver(out), out.strip()


def detect_version_auto():
    for exe in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
        p = which(exe)
        if p:
            v, raw = detect_version_from_path(p)
            if v:
                return p, v, raw

    for p in candidate_paths():
        v, raw = detect_version_from_path(p)
        if v:
            return p, v, raw

    return None, None, ''


def main():
    ap = argparse.ArgumentParser(description='Check whether installed Chrome/Chromium is vulnerable to CVE-2026-11107.')
    ap.add_argument('--version', help='Version string to evaluate directly, e.g. 149.0.7827.52')
    ap.add_argument('--path', help='Path to browser executable, e.g. C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe')
    args = ap.parse_args()

    if args.version:
        v = parse_ver(args.version)
        if not v:
            print('UNKNOWN - Could not parse supplied version string')
            sys.exit(2)
        if is_patched(v):
            print(f'PATCHED - Version {ver_to_str(v)} is >= {ver_to_str(PATCHED_MIN)}')
            sys.exit(0)
        else:
            print(f'VULNERABLE - Version {ver_to_str(v)} is < {ver_to_str(PATCHED_MIN)}')
            sys.exit(1)

    if args.path:
        if not os.path.exists(args.path):
            print(f'UNKNOWN - File not found: {args.path}')
            sys.exit(2)
        v, raw = detect_version_from_path(args.path)
        if not v:
            print(f'UNKNOWN - Could not determine version from {args.path}')
            sys.exit(2)
        if is_patched(v):
            print(f'PATCHED - {args.path} reports {raw}')
            sys.exit(0)
        else:
            print(f'VULNERABLE - {args.path} reports {raw}')
            sys.exit(1)

    path, v, raw = detect_version_auto()
    if not v:
        print('UNKNOWN - Could not automatically locate Chrome/Chromium or parse its version')
        sys.exit(2)

    if is_patched(v):
        print(f'PATCHED - {path} reports {raw}')
        sys.exit(0)
    else:
        print(f'VULNERABLE - {path} reports {raw}')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning: do not let this jump the queue ahead of RCEs, sandbox escapes, or KEV-listed browser flaws. Roll the Chrome 149 update through normal endpoint hygiene, verify stragglers with version inventory, and use download-execution controls as the practical backstop; because this is LOW, there is no noisgate mitigation SLA and noisgate remediation SLA is backlog hygiene, but for a browser used every day by the whole workforce you should still clean up laggards in the next regular patch cycle rather than leaving them indefinitely.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases - Early Stable Update for Desktop
  3. Chromium issue reference for CVE-2026-11107
  4. CIRCL Vulnerability-Lookup mirror of Chrome CVE records
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. Chrome Enterprise browser release channels
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.