← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11254 · 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 at the front desk, not a master key to the building

CVE-2026-11254 is a Chrome Permissions UI spoofing flaw in versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. A malicious site can present crafted content that makes a permission flow look more trustworthy than it should, pushing a user toward clicking through a prompt or trusting a page element they should not trust.

The supplied baseline says MEDIUM 4.3, but Google's own release note classifies the bug as Low. Reality is closer to LOW for enterprise patch triage: exploitation requires a user landing on attacker-controlled content and then being fooled by spoofed UI, and the bug does not itself deliver code execution, sandbox escape, credential theft, or durable endpoint compromise.

"Broadly deployed, but this is still a click-driven browser spoof bug with limited standalone impact."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled web content

The attacker needs the victim browsing to a crafted HTML page, typically via phishing, malvertising, SEO poisoning, or a compromised legitimate site. Weaponized tool: a standard phishing kit or custom JavaScript landing page; no public exploit framework was identified from the sources reviewed.
Conditions required:
  • Unauthenticated remote reachability to the victim's browser
  • The user must open the malicious page in a vulnerable Chrome build
Where this breaks in practice:
  • Email gateways, safe browsing, DNS filtering, and web proxies routinely kill a large share of these lures before the browser ever renders the page
  • Chrome auto-update compresses vulnerable population quickly in well-managed fleets
Detection/coverage: Covered indirectly by secure web gateway, URL filtering, phishing telemetry, and browser history/log enrichment; vulnerability scanners cannot directly prove exploit delivery from the network edge.
STEP 02

Trigger the spoofed permissions flow

Once rendered, the crafted page abuses the Permissions implementation to create misleading UI around a browser permission interaction. Weaponized tool: custom HTML/JS page content; the public Chromium bug is access-restricted, and no public PoC repo was found.
Conditions required:
  • Chrome version is older than the fixed build
  • The targeted permission flow is reachable from the page
Where this breaks in practice:
  • This is not a silent exploit chain; the attacker still needs the browser to show or simulate a user-visible decision point
  • Enterprise policies that deny or suppress sensitive prompts reduce viable abuse paths
Detection/coverage: Minimal signature-based coverage. Browser telemetry can show permission prompt activity, but distinguishing malicious spoofing from noisy ad-tech behavior is hard.
STEP 03

Convince the user to trust or allow

The attack only pays off if the user mistakes the spoofed UI for legitimate Chrome UI or origin-trust signals and clicks through. Weaponized tool: social-engineering copy, fake verification banners, or fake 'click allow' prompts layered into the page.
Conditions required:
  • User interaction is required
  • The user must misread or trust the spoofed prompt
Where this breaks in practice:
  • This is the decisive brake on severity: user interaction is not incidental here, it is the exploit
  • User training, hardened browser settings, and reduced local admin culture all cut success rates
Detection/coverage: EDR usually will not flag the click itself. Detection is behavioral: anomalous permission grants, risky browsing events, and downstream phishing telemetry.
STEP 04

Turn the spoof into downstream abuse

If the user is fooled, the attacker can leverage the misplaced trust for phishing, fraudulent permission grants, or limited content-integrity manipulation. Weaponized tool: follow-on credential harvesting page, scam flow, or nuisance notification campaign.
Conditions required:
  • The spoof must successfully influence user behavior
  • A useful follow-on action must exist, such as enabling notifications or trusting a page workflow
Where this breaks in practice:
  • Impact is bounded; the CVSS vector's I:L fits reality because the bug does not directly hand over code execution or broad data access
  • Blast radius is usually one browsing session or one user decision, not estate-wide compromise
Detection/coverage: Look for unusual notification permissions, help-desk complaints about fake browser prompts, and credential phish indicators tied to the same browsing session.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the reviewed sources as of 2026-06-05; not KEV-listed.
Proof-of-concept availabilityNo public PoC repo or exploit write-up identified. The Chromium issue is present but access-restricted: issue 498405554.
EPSS0.00017 (~0.017%) per the user-supplied intel, which is extremely low threat pressure.
KEV statusNo entry in CISA's KEV catalog reviewed for this CVE.
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N means remote and unauthenticated, but user interaction is mandatory and direct impact is limited to low integrity.
Affected versionsChrome prior to 149.0.7827.53. Google's stable post lists fixed desktop builds as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS.
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux and 149.0.7827.53/54 or later on Windows/macOS.
Scanning / exposure realityThis is a client-side browser bug, so Shodan/Censys-style internet scans are not meaningful exposure measures. Use endpoint inventory, EDR software inventory, Chrome management, or package reporting instead.
TimelineReported by Google on 2026-04-01 in the release note, stable fix shipped 2026-06-02, and public disclosure is listed by the user as 2026-06-05.
Reporter / researcherGoogle lists the issue as reported by Google in the stable channel advisory.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

The single biggest downward pressure is that exploitation depends on successful user deception, not on a silent technical break that hands over code execution or data. Even though Chrome is everywhere, this bug's blast radius is usually one user decision in one browser session, which keeps it out of the enterprise fast-lane queue.

HIGH Exploit preconditions and user-interaction dependence
MEDIUM Absence of public PoC and public in-the-wild exploitation evidence

Why this verdict

  • User interaction is the exploit: the attacker still needs the victim to misread spoofed UI and click through, which is strong real-world friction.
  • Impact is narrow: the supplied vector already says I:L with no confidentiality or availability loss, and nothing in the sources suggests code execution or sandbox escape.
  • Exposure is broad but not externally service-like: Chrome is ubiquitous, but this is not a wormable network service flaw; the attacker must first win a phishing or lure step against the user.

Why not higher?

There is no public evidence here of active exploitation, KEV listing, public weaponized PoC, or an exploit chain that bypasses user choice. More importantly, the flaw does not itself grant arbitrary code execution, origin compromise at scale, or durable persistence on the endpoint.

Why not lower?

This is still a remotely reachable browser flaw in one of the most widely deployed client applications on the planet. If an attacker already has a phishing path, spoofed permissions UI can improve conversion rates and create real downstream abuse, so it is not an IGNORE.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome auto-update — Use enterprise policy and software deployment to keep Chrome on current stable builds. For a LOW verdict there is no SLA beyond backlog hygiene, but this control should still be enforced continuously because it collapses exposure without waiting for user action.
  2. Deny unneeded site permissions by policy — Set conservative defaults for notifications, geolocation, camera, microphone, and similar prompts so spoofed permission flows have less to work with. For a LOW verdict there is no SLA beyond backlog hygiene; apply through normal browser hardening baselines.
  3. Block high-risk web lures — Use DNS filtering, secure web gateways, and Safe Browsing enforcement to cut off phishing and scam pages before the browser renders attacker-controlled content. For a LOW verdict there is no SLA beyond backlog hygiene; fold into standard web-control tuning.
  4. Alert on unusual permission grants — Watch browser telemetry and support tickets for spikes in notification grants, fake verification pages, or scammy browser prompts. For a LOW verdict there is no SLA beyond backlog hygiene; this is a cheap detective control for noisy abuse.
What doesn't work
  • Relying on EDR alone does not solve this; there is typically no payload execution for EDR to intercept.
  • A WAF is mostly irrelevant because the vulnerable surface is the client browser rendering hostile web content, not your server handling requests.
  • MFA helps with downstream credential phishing impact, but it does not stop the browser UI spoof step itself.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software inventory/remote execution tooling. Invoke it as python3 verify_cve_2026_11254.py or python3 verify_cve_2026_11254.py --path "/opt/google/chrome/chrome"; no admin rights are normally required, but the account must be able to execute or inspect the local Chrome binary.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Verify Google Chrome exposure to CVE-2026-11254
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED = (149, 0, 7827, 53)


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


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


def run_version(path):
    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 candidate_paths():
    system = platform.system().lower()
    cands = []

    if system == 'windows':
        local = os.environ.get('LOCALAPPDATA', '')
        pf = os.environ.get('PROGRAMFILES', '')
        pfx86 = os.environ.get('PROGRAMFILES(X86)', '')
        cands.extend([
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ])
    elif system == 'darwin':
        cands.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ])
    else:
        cands.extend([
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/snap/bin/chromium',
        ])

    for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
        found = shutil.which(name)
        if found:
            cands.append(found)

    # Preserve order, drop empties/dupes
    seen = set()
    ordered = []
    for p in cands:
        if p and p not in seen:
            seen.add(p)
            ordered.append(p)
    return ordered


def main():
    ap = argparse.ArgumentParser(description='Check local Chrome version against CVE-2026-11254 fixed build 149.0.7827.53')
    ap.add_argument('--path', help='Explicit path to Chrome executable')
    args = ap.parse_args()

    paths = [args.path] if args.path else candidate_paths()

    for path in paths:
        if not path or not os.path.exists(path):
            continue
        ver = run_version(path)
        if not ver:
            continue

        print(f'DETECTED: {path} -> {version_str(ver)}')
        if ver < FIXED:
            print('VULNERABLE')
            sys.exit(1)
        else:
            print('PATCHED')
            sys.exit(0)

    print('UNKNOWN')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: do not treat this like a fleet emergency. Keep Chrome auto-update healthy, verify that browsers are at 149.0.7827.53/54 or later, and fold any stragglers into normal client patching; for a LOW verdict there is no mitigation SLA and noisgate remediation SLA says treat it as backlog hygiene rather than an accelerated campaign. In practice, document the rationale now, use the verification script to find laggards this week, and clear remaining outdated Chrome installs through the normal browser maintenance cycle rather than burning urgent change windows.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (2026-06-02)
  2. Chromium issue 498405554
  3. Chromium Security
  4. Chromium Severity Guidelines
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS
  7. FIRST EPSS User Guide
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.