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.
4 steps from start to impact.
Land the user on attacker-controlled web content
- Unauthenticated remote reachability to the victim's browser
- The user must open the malicious page in a vulnerable Chrome build
- 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
Trigger the spoofed permissions flow
- Chrome version is older than the fixed build
- The targeted permission flow is reachable from the page
- 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
Convince the user to trust or allow
- User interaction is required
- The user must misread or trust the spoofed prompt
- 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
Turn the spoof into downstream abuse
- The spoof must successfully influence user behavior
- A useful follow-on action must exist, such as enabling notifications or trusting a page workflow
- Impact is bounded; the CVSS vector's
I:Lfits 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
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the reviewed sources as of 2026-06-05; not KEV-listed. |
|---|---|
| Proof-of-concept availability | No public PoC repo or exploit write-up identified. The Chromium issue is present but access-restricted: issue 498405554. |
| EPSS | 0.00017 (~0.017%) per the user-supplied intel, which is extremely low threat pressure. |
| KEV status | No entry in CISA's KEV catalog reviewed for this CVE. |
| CVSS vector readout | CVSS: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 versions | Chrome 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 versions | Upgrade to 149.0.7827.53 or later on Linux and 149.0.7827.53/54 or later on Windows/macOS. |
| Scanning / exposure reality | This 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. |
| Timeline | Reported 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 / researcher | Google lists the issue as reported by Google in the stable channel advisory. |
noisgate verdict.
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.
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:Lwith 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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.