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

Inappropriate implementation in Downloads in Google Chrome prior to 149

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

This is a crooked road sign inside a very common car, not a missing door lock

CVE-2026-11243 affects Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. A crafted HTML page can abuse the Downloads/navigation flow to weaken a browser restriction, but the public record is messy: NVD describes it as an *inappropriate implementation* that lets an attacker bypass navigation restrictions, while Google's June 2, 2026 stable-release notes label the same CVE as *incorrect security UI in Downloads*. Either way, this is a client-side browser trust/UX problem reached through web content, not a memory-corruption or sandbox-escape bug.

The vendor baseline of 5.4 MEDIUM is defensible in CVSS math but too generous for enterprise patch triage. Real-world exploitation still requires a user to hit attacker-controlled content and then benefit from a narrow browser-UI edge case, with low blast radius and no evidence of in-the-wild exploitation, no KEV listing, and an extremely low EPSS; that pushes this down into LOW despite Chrome's huge install base.

"Wide deployment, narrow abuse: this is a user-driven Chrome UI bug, not an enterprise fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a crafted web page

The attacker needs a victim running vulnerable Chrome to render attacker-controlled HTML. The weaponized tool here is just a malicious page or ad-driven landing page, using normal browser navigation rather than an exploit kit. This is consistent with the public CVE description and requires no prior foothold on the endpoint.
Conditions required:
  • Victim uses Chrome earlier than 149.0.7827.53
  • Victim reaches attacker-controlled content
  • Normal web browsing is permitted
Where this breaks in practice:
  • Email/web filtering, Safe Browsing, ad blocking, and DNS filtering reduce reach
  • Enterprise browsers usually auto-update quickly, shrinking the vulnerable window
Detection/coverage: Vulnerability scanners can reliably flag outdated Chrome versions, but they cannot validate whether the page logic for this UI/navigation edge case is actually reachable.
STEP 02

Trigger the Downloads/navigation edge case

The malicious page must steer Chrome into the flawed Downloads flow. Public technical detail is restricted in the Chromium issue, so the exact primitive is not published; based on NVD and Google's release notes, the abuse lives in Downloads handling and results in either a navigation-restriction bypass or misleading security UI. No memory safety primitive or sandbox break is described.
Conditions required:
  • Specific Downloads UI code path must be reachable
  • Browser behavior must match the vulnerable build
Where this breaks in practice:
  • Issue details are still restricted, limiting copy-paste exploitation
  • Minor UI timing or browser-state assumptions often make these bugs brittle in the field
Detection/coverage: Version-based checks work; exploit-attempt telemetry is weak unless you have browser telemetry or content-inspection around suspicious download flows.
STEP 03

Rely on user interaction

The CVSS vector includes UI:R, and recent analogous Chrome Downloads UI bugs required the victim to engage with misleading prompts or gestures. In practice, the attacker still needs the user to trust or click through the manipulated flow. That sharply narrows reliable exploitation compared with silent browser compromise.
Conditions required:
  • Victim interacts with the page or related download prompt
  • User trusts the page enough to continue
Where this breaks in practice:
  • Security awareness, browser warnings, and download reputation checks all cut success rates
  • Privileged admins are not the default target population for routine web-browsing lures
Detection/coverage: Hard to detect as a discrete exploit; best signals are suspicious referrers, abnormal download patterns, and user reports of misleading browser prompts.
STEP 04

Cash out limited browser-level impact

If the attacker succeeds, the payoff is a bypass of a browser navigation/security restriction or UI trust boundary, not direct code execution on the host. That can support phishing, confusing download flows, or modest confidentiality/availability impact inside the browser session. The blast radius stays per-user and per-session unless chained with something stronger.
Conditions required:
  • Attacker achieves the UI/navigation misrepresentation outcome
  • Victim continues into the next malicious step
Where this breaks in practice:
  • Chrome sandboxing and OS execution prompts still stand between this bug and host compromise
  • Without a second-stage flaw or social-engineering success, enterprise impact is usually limited
Detection/coverage: EDR is unlikely to see anything unless a follow-on payload is executed; this is primarily a browser/version management problem.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence located. As of 2026-06-05, Google did not flag exploitation in the release notes, and CISA does not list this CVE in KEV.
Proof-of-concept availabilityNo public PoC found. The Chromium issue is permission-restricted, which slows opportunistic weaponization but does not eliminate private research risk.
EPSS0.00011 *(user-provided intel)* — effectively noise-floor exploit probability for the next 30 days.
KEV statusNot KEV-listed as of 2026-06-05; no CISA due date applies.
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L — network-reachable but user interaction required, with only light confidentiality/availability impact and no integrity change in the published vector.
Affected versionsGoogle Chrome before 149.0.7827.53; NVD maps this to Chrome on Windows, Linux, and macOS.
Fixed versionsGoogle's stable rollout lists Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54 as fixed. I found no official distro backport advisory for this specific CVE in the sources reviewed, so treat the browser build itself as the remediation target.
Exposure / populationChrome's desktop footprint is enormous — Statcounter shows roughly 71.48% worldwide desktop browser share — so install base is broad, but this is not an internet-exposed server surface and cannot be found via Shodan-style perimeter scanning.
Disclosure / reporting timelinePublic dates do not line up cleanly: Google published Chrome 149 stable on 2026-06-02, NVD shows the CVE was published 2026-06-04 and modified by CISA-ADP 2026-06-05. Google's release notes say the issue was reported by Google on 2026-03-29.
Pattern match with prior bugsThis looks like another member of Chrome's recurring Downloads UI/security-boundary bug class. Similar issues include CVE-2026-5897 and CVE-2024-8906, both Downloads UI spoofing problems with low-to-medium scoring and user-interaction dependence.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.4/10)

The decisive factor is mandatory user interaction inside a narrow browser UI path: this is not silent remote compromise, it is a user-driven trust-boundary glitch. Chrome's large footprint keeps it relevant, but the absence of exploitation evidence and the limited browser-level blast radius keep it out of the MEDIUM bucket.

MEDIUM Severity reassessment despite restricted Chromium bug details
HIGH Version scope and fixed build identification
HIGH No current KEV / no public exploitation evidence

Why this verdict

  • **Downward adjustment: attacker position is only *unauthenticated remote via web content*, but it still requires UI:R.** That means no hands-off exploitation; the victim must browse to attacker content and interact with the flawed flow.
  • Downward adjustment: the prerequisite implies social-engineering success, not initial access by itself. Requiring the user to do something meaningful inside Chrome sharply reduces conversion versus silent browser RCE or sandbox escape.
  • Downward adjustment: blast radius is per-user and browser-scoped. The published impact is a navigation/security-boundary bypass, not arbitrary code execution, privilege escalation, or tenant-wide compromise.
  • Downward adjustment: real deployment exposure is broad in population but narrow in exploit surface. Chrome is everywhere, but this is not a server endpoint and not something an internet scanner can sweep up at enterprise scale.
  • Downward adjustment: modern controls should interrupt the chain. Safe Browsing, web filtering, ad filtering, DNS controls, and rapid browser auto-update all act before the attacker can monetize the bug.
  • Small upward adjustment: Chrome is massively deployed. A flaw in a high-share browser matters operationally, but ubiquity alone does not overcome the heavy friction from user interaction and low impact.

Why not higher?

This is not a memory-corruption bug, sandbox escape, auth bypass into enterprise infrastructure, or a silent browser compromise. The attacker still needs a victim to hit malicious content and then successfully leverage a low-detail Downloads/UI edge case for limited payoff, with no public evidence of active exploitation.

Why not lower?

It is still a real browser security-boundary weakness in a massively deployed product, reachable through normal web content with no authentication required. If you run a large unmanaged or slow-to-update endpoint fleet, the population at risk is large enough that this should stay on the patch radar rather than being ignored outright.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update health — Validate that enterprise policy is actually moving endpoints to 149.0.7827.53+ during the next normal browser maintenance cycle. For a LOW verdict there is no SLA; treat this as backlog hygiene and use routine endpoint compliance reporting instead of emergency change control.
  2. Tighten download reputation controls — Keep Google Safe Browsing, browser download warnings, and any secure web gateway file-reputation features enabled so a misleading Downloads flow has less room to trick users. For LOW, do this in the next routine policy review rather than as an urgent exception.
  3. Reduce risky web reach for high-exposure users — Apply stronger DNS/web filtering or browser isolation to admins, finance, and other phishing-prone roles that routinely touch untrusted content. There is no mitigation SLA here, so fold the control into your standard hardening roadmap.
  4. Watch for stale browser cohorts — Use EDR, MDM, RMM, or software inventory to find endpoints stuck below the fixed build, especially VDI gold images and kiosk-like systems that often miss browser refreshes. For LOW, clear these through the next standard image-update or software deployment wave.
What doesn't work
  • A WAF does not help; the vulnerable surface is the user's browser UI/Downloads path, not your server-side request handling.
  • Perimeter scanning does not help; Chrome clients are not externally enumerable the way internet-facing appliances are.
  • EDR-only thinking is insufficient; unless this is chained into payload execution, the bug can stay entirely in browser UX territory and never trip classic malware detections.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your RMM/EDR live-response shell. Invoke it as python3 check_cve_2026_11243.py or point to a specific binary with python3 check_cve_2026_11243.py --chrome "C:\Program Files\Google\Chrome\Application\chrome.exe"; standard user rights are usually enough because it only reads the installed browser version and executes chrome --version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11243.py
# Detects whether installed Google Chrome is below the fixed version for CVE-2026-11243.
# Outputs exactly one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 1 = vulnerable, 0 = patched, 2 = unknown/error

import argparse
import os
import platform
import re
import subprocess
import sys
from typing import Optional, List

FIXED = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[tuple]:
    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_to_str(v: tuple) -> str:
    return '.'.join(str(x) for x in v)


def candidate_paths() -> List[str]:
    system = platform.system().lower()
    paths = []
    if system == 'windows':
        env_paths = [
            os.environ.get('ProgramFiles'),
            os.environ.get('ProgramFiles(x86)'),
            os.environ.get('LOCALAPPDATA'),
        ]
        suffixes = [
            r'Google\Chrome\Application\chrome.exe',
        ]
        for base in env_paths:
            if base:
                for suffix in suffixes:
                    paths.append(os.path.join(base, suffix))
    elif system == 'darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ])
    else:
        paths.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/opt/google/chrome/chrome',
            '/snap/bin/chromium',
        ])
    return paths


def get_version_from_binary(path: str) -> Optional[tuple]:
    try:
        cp = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
        out = (cp.stdout or '') + ' ' + (cp.stderr or '')
        return parse_version(out)
    except Exception:
        return None


def locate_version(explicit_path: Optional[str]) -> Optional[tuple]:
    checked = []
    if explicit_path:
        checked.append(explicit_path)
    checked.extend(candidate_paths())

    seen = set()
    for path in checked:
        if not path or path in seen:
            continue
        seen.add(path)
        if os.path.exists(path):
            v = get_version_from_binary(path)
            if v:
                return v

    # Fallback: rely on PATH
    for cmd in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
        try:
            cp = subprocess.run([cmd, '--version'], capture_output=True, text=True, timeout=10)
            out = (cp.stdout or '') + ' ' + (cp.stderr or '')
            v = parse_version(out)
            if v:
                return v
        except Exception:
            pass

    return None


def main() -> int:
    parser = argparse.ArgumentParser(description='Check Google Chrome against fixed version for CVE-2026-11243')
    parser.add_argument('--chrome', help='Path to Chrome binary/executable', default=None)
    args = parser.parse_args()

    version = locate_version(args.chrome)
    if not version:
        print('UNKNOWN')
        return 2

    if version < FIXED:
        # Optional diagnostic is kept in comments to preserve exact output requirement.
        # print(f'Installed version {version_to_str(version)} is below fixed {version_to_str(FIXED)}')
        print('VULNERABLE')
        return 1
    else:
        # print(f'Installed version {version_to_str(version)} meets/exceeds fixed {version_to_str(FIXED)}')
        print('PATCHED')
        return 0


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

If you remember one thing.

TL;DR
On Monday morning, do not burn an emergency browser patch window for this one. There is no noisgate mitigation SLA and no noisgate remediation SLA for a LOW verdict — treat it as backlog hygiene: verify Chrome auto-update health, find any endpoints still below 149.0.7827.53, and roll them into your next routine browser update wave while prioritizing only high-risk user groups and stale image pools for faster cleanup.

Sources

  1. NVD entry for CVE-2026-11243
  2. Google Chrome stable desktop release 149
  3. Chromium issue 497394061
  4. CISA Known Exploited Vulnerabilities Catalog
  5. Statcounter desktop browser market share worldwide
  6. NVD entry for analogous Downloads UI bug CVE-2026-5897
  7. NVD entry for analogous Downloads UI bug CVE-2024-8906
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.