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

Inappropriate implementation in Permissions in Google Chrome prior to 149

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

This is a fake badge on a real uniform, not a skeleton key into the building

CVE-2026-11300 is a Permissions UI spoofing flaw in Google Chrome's Permissions component. Affected builds are Chrome prior to 149.0.7827.53; Google’s June 2, 2026 stable notes place the fix in 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS, with 148.0.7778.254 also released on the Extended Stable track for Windows and Mac. The practical risk is not code execution or sandbox escape; it is that a malicious page can make browser permission UX look misleading enough to steer a user into an unsafe click or trust decision.

The 4.3/MEDIUM baseline is still generous for enterprise patch triage. In real deployments this attack chain is throttled by three big friction points: user interaction is mandatory, the impact is mostly phishing/trust manipulation rather than direct compromise, and there is no evidence of active exploitation or KEV listing. Chromium itself labeled the issue Low in its release notes, and that tracks better with what defenders actually have to care about on Monday morning.

"A browser UI spoof that still needs the victim to do the hard part: believe it."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on a malicious page

Tooling: generic phishing kit, malvertising redirect, or social lure. The attacker must first get a target to browse to attacker-controlled content in a vulnerable Chrome build. This is internet-reachable in the broad sense because browsers render untrusted web content all day, but the attacker still needs a successful lure rather than a direct socket-level hit.
Conditions required:
  • Victim is running Chrome older than 149.0.7827.53
  • Victim opens attacker-controlled content
  • Attacker can induce browsing from email, chat, ads, or a compromised site
Where this breaks in practice:
  • Email gateway, web filtering, Safe Browsing, and user skepticism can kill the lure before render
  • This is not wormable and not unaided drive-by RCE
  • Auto-update shrinks vulnerable dwell time on well-managed fleets
Detection/coverage: Exposure scanners do not see this from the perimeter; this is endpoint/browser-version inventory territory. Secure web gateway telemetry and phishing detections are the best early signals.
STEP 02

Trigger the misleading permissions state

Tooling: crafted HTML/JavaScript page using normal browser features. The page must drive the victim into the specific permissions flow where the UI weakness matters, then present content that benefits from the spoof. Because the Chromium bug is still lightly described publicly, there is no public exploit recipe showing a one-click deterministic trigger across all environments.
Conditions required:
  • The targeted page flow reaches a browser permissions prompt or indicator
  • The spoof works in the victim’s platform/UI configuration
  • The user remains on the page long enough to interact
Where this breaks in practice:
  • Permissions UX can vary by OS, channel, and browser state
  • Bug details are restricted, which slows opportunistic copycat weaponization
  • Ad/tracker blockers and enterprise browser policies may suppress relevant permission paths
Detection/coverage: Expect poor signature coverage from commodity scanners. At best, browser telemetry or reproduction testing can validate exploitability.
STEP 03

Convince the user to trust the wrong thing

Tooling: phishing content and lookalike UI, not shellcode. The attacker only gets value if the victim mistakes the spoofed permission context for a legitimate browser or site trust signal and then clicks, grants, or proceeds. That makes the human decision the decisive choke point in the chain.
Conditions required:
  • User interaction is required
  • The spoofed UI is believable enough to override normal caution
  • The target user has a permission or action worth abusing
Where this breaks in practice:
  • Security awareness, modern browser chrome, and site reputation warnings reduce success rate
  • MFA and downstream app controls still block many follow-on goals
  • Blast radius is typically one user/session, not fleet-wide execution
Detection/coverage: Phishing-resistant telemetry helps more than vuln scanners here: suspicious permission grants, unusual browser prompts, SWG logs, and downstream identity alerts.
STEP 04

Cash out into a phishing or consent-abuse outcome

Tooling: follow-on phishing workflow, fake support prompts, or abusive permission requests. The plausible impact is credential theft, fraudulent consent, or unsafe user decisions under a misleading UI—not direct host takeover. In enterprise terms, this is a social-engineering amplifier, not a primary initial-access primitive by itself.
Conditions required:
  • The permission spoof translates into a meaningful user action
  • The attacker has a follow-on objective such as credential capture or abusive permission grant
  • No stronger control interrupts the post-click action
Where this breaks in practice:
  • No demonstrated chain to code execution, sandbox escape, or lateral movement from this bug alone
  • Impact is narrow and user-specific
  • Many environments can detect or stop the downstream phish even if the spoof lands
Detection/coverage: Look for downstream signals: identity-provider alerts, anomalous permission grants, reported phishing pages, and browser history artifacts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in Google’s release notes, and not KEV-listed as of 2026-06-05.
Proof-of-concept availabilityNo public PoC located. The Chromium issue link exists, but bug details are restricted, which materially slows copycat weaponization.
EPSS0.00017 from the prompt, which is effectively floor-level exploit probability. Percentile was not provided in the available data.
KEV statusAbsent from CISA KEV; no CISA due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — the key limiter is UI:R. This is remote only in the sense that the web can deliver it; the victim still has to be fooled into acting.
Affected versionsUser-provided intel says Google Chrome prior to 149.0.7827.53. Google’s stable notes place the fixed build at 149.0.7827.53 Linux and 149.0.7827.53/.54 Windows/Mac.
Fixed versions149.0.7827.53 for Linux, 149.0.7827.53/.54 for Windows/macOS stable, plus 148.0.7778.254 Extended Stable for Windows/Mac. openSUSE maintenance metadata also includes this CVE in packaged browser updates.
Vendor vs realityPrompt says Vendor severity MEDIUM 4.3, but Chromium’s own June 2, 2026 release notes classify CVE-2026-11300 as Low. For enterprise triage, Chromium’s rating aligns better with the real attack friction.
Exposure/scanning realityThere is no Shodan/Censys-style external banner surface here. This is a client-side browser inventory problem, not an internet-exposed service fingerprinting problem.
Disclosure and reporterDisclosed 2026-06-05 per the prompt; Google’s notes show it was reported by Google on 2026-04-17.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

The decisive limiter is mandatory user interaction inside a phishing-style chain. This bug can make deception easier, but by itself it does not hand an attacker code execution, data theft, or broad fleet blast radius, and there is no public exploitation signal pushing it upward.

HIGH Severity is lower than the prompt’s MEDIUM baseline
MEDIUM Exploit mechanics are incompletely public because the Chromium bug remains restricted
HIGH No active exploitation / KEV absence as of 2026-06-05

Why this verdict

  • Down one step for UI:R — the attacker cannot directly cash this bug out without the victim making a trust decision.
  • Down again for impact shape — this is UI spoofing in Permissions, not renderer RCE, sandbox escape, or cross-origin data theft.
  • Down again for exposure reality — every browser is installed everywhere, but only a subset of users will hit the crafted page, hit the relevant permission flow, and believe the spoof strongly enough to act.
  • Down again for control coverage — phishing-resistant MFA, Safe Browsing, SWGs, URL filtering, and user training all intercept parts of this chain before meaningful harm occurs.
  • No upward adjustment for threat intel — EPSS is near zero, there is no KEV entry, and no credible public campaign evidence was found.

Why not higher?

A higher bucket would require either stronger impact or lower friction. We have neither: the bug needs a lure, needs a live victim, needs the right permissions flow, and still only yields a misleading UI state that must be converted into a second-stage outcome.

Why not lower?

This is not IGNORE because Chrome is ubiquitous and the web gives attackers broad delivery opportunities. A UI spoof in a permissions context can still improve phishing success against real employees, so it belongs in routine browser hygiene rather than being dismissed outright.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update compliance — Make sure Chrome stable and Extended Stable update health is visible in endpoint management, because version drift is the only scalable way this stays exploitable in a 10,000-host fleet. For a LOW verdict there is no SLA; treat it as backlog hygiene and clean up stragglers in the normal browser maintenance cycle.
  2. Harden permission prompts with enterprise policy — Reduce risky permission surfaces where business-appropriate by centrally governing camera, microphone, notifications, geolocation, and pop-up behavior. This shrinks the number of flows where a permissions UI spoof can matter; for LOW, there is no SLA and this can be folded into standard browser baseline work.
  3. Lean on phishing-resistant controls — Because the attacker still needs user belief, controls like Safe Browsing, secure web gateways, link isolation, and phishing-resistant MFA are more valuable than emergency outage-style patching. For LOW, there is no mitigation SLA; keep these controls tuned as ongoing hygiene.
  4. Monitor browser-version exceptions — Flag persistent installs below 149.0.7827.53 or below the applicable Extended Stable build and attach them to endpoint owner queues. The risk is modest, but unmanaged laggards are where low-severity browser bugs accumulate into preventable exposure.
What doesn't work
  • A network IDS signature will not save you here; there is no unique exploit packet sequence to reliably key on.
  • Perimeter vuln scanning will miss the real problem because this is not an externally exposed service.
  • EDR alone is not a strong control for the bug itself, because there is no direct payload execution step for it to catch.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/remote-management tooling. Invoke it as python3 chrome_cve_2026_11300_check.py --fixed 149.0.7827.53; no admin rights are required for local checks, though Windows registry access and standard install paths must be readable.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# chrome_cve_2026_11300_check.py
# Checks local Chrome/Chromium version against the fixed build for CVE-2026-11300.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED_DEFAULT = '149.0.7827.53'


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


def cmp_versions(a, b):
    la, lb = len(a), len(b)
    n = max(la, lb)
    a = a + (0,) * (n - la)
    b = b + (0,) * (n - lb)
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        if p.returncode == 0:
            return p.stdout.strip() or p.stderr.strip()
    except Exception:
        pass
    return ''


def candidate_paths():
    system = platform.system().lower()
    paths = []
    if system == 'windows':
        envs = [os.environ.get('PROGRAMFILES'), os.environ.get('PROGRAMFILES(X86)'), os.environ.get('LOCALAPPDATA')]
        suffixes = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe'
        ]
        for base in envs:
            if base:
                for s in suffixes:
                    paths.append(os.path.join(base, s))
    elif system == 'darwin':
        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 paths


def windows_registry_version():
    reg_queries = [
        ["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"]
    ]
    for cmd in reg_queries:
        out = run_cmd(cmd)
        m = re.search(r'version\s+REG_\w+\s+([0-9\.]+)', out, re.I)
        if m:
            return ('Google Chrome (registry)', m.group(1))
    return None


def discover_version():
    system = platform.system().lower()

    if system == 'windows':
        reg = windows_registry_version()
        if reg:
            return reg

    # Try binaries in PATH first
    for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
        p = which(name)
        if p:
            out = run_cmd([p, '--version'])
            m = re.search(r'((Google Chrome|Chromium)\s+)?([0-9]+(?:\.[0-9]+){1,})', out)
            if m:
                product = 'Google Chrome' if 'Google Chrome' in out else 'Chromium'
                return (f'{product} ({p})', m.group(3))

    # Then try standard install paths
    for p in candidate_paths():
        if os.path.exists(p):
            out = run_cmd([p, '--version'])
            m = re.search(r'((Google Chrome|Chromium)\s+)?([0-9]+(?:\.[0-9]+){1,})', out)
            if m:
                product = 'Google Chrome' if 'Google Chrome' in out else 'Chromium'
                return (f'{product} ({p})', m.group(3))

    return None


def main():
    parser = argparse.ArgumentParser(description='Check for CVE-2026-11300 fixed Chrome version')
    parser.add_argument('--fixed', default=FIXED_DEFAULT, help='Fixed version threshold (default: 149.0.7827.53)')
    args = parser.parse_args()

    fixed = parse_version(args.fixed)
    if not fixed:
        print('UNKNOWN - invalid --fixed version supplied')
        sys.exit(2)

    found = discover_version()
    if not found:
        print('UNKNOWN - Chrome/Chromium not found')
        sys.exit(2)

    product, version_str = found
    current = parse_version(version_str)
    if not current:
        print(f'UNKNOWN - could not parse version from {product}: {version_str}')
        sys.exit(2)

    if cmp_versions(current, fixed) < 0:
        print(f'VULNERABLE - {product} version {version_str} is below fixed {args.fixed}')
        sys.exit(1)
    else:
        print(f'PATCHED - {product} version {version_str} meets/exceeds fixed {args.fixed}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like an emergency patch sprint. Fold it into normal browser hygiene: validate auto-update health, identify endpoints still below 149.0.7827.53 or the applicable Extended Stable build, and clean up exceptions in the routine maintenance cycle. For a LOW verdict there is no noisgate mitigation SLA and noisgate remediation SLA is no SLA (treat as backlog hygiene), so the right move is version-compliance enforcement and policy hardening rather than interrupting the patch queue.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases - Early Stable Update for Desktop
  3. Chrome Releases index - Extended Stable update listing
  4. Chromium Security
  5. Chrome Release Channels
  6. FIRST EPSS API documentation
  7. FIRST EPSS overview
  8. openSUSE maintenance patch info including CVE-2026-11300
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.