This is a fake street sign at the edge of the browser, not a bulldozer through your front door
CVE-2026-11273 is an *improper input validation* bug in Chrome's Omnibox security/UI surface. A remote attacker can reach it only by getting a user onto a crafted page or flow, and the impact described so far points to *security UI spoofing / misleading address-bar state* rather than code execution. The affected range is Google Chrome for desktop *before* 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows/macOS, with downstream browser packages inheriting the fix through vendor backports.
Google labeled it MEDIUM at 6.1, which is fair in a vacuum because browsers are ubiquitous and Omnibox trust cues matter. In enterprise reality, though, this chain is heavily gated by *user interaction*, the likely need for a carefully crafted phishing page, and the absence of evidence for in-the-wild weaponization or a public exploit. That makes it a *real but bounded* user-deception issue, not a Monday-morning emergency.
3 steps from start to impact.
Stage a lure page
- Unauthenticated remote reach to a target user
- User runs a vulnerable Chrome build
- Attacker can get the user to open attacker-controlled content
- Email gateways, browser filtering, and user skepticism kill a lot of lures before render
- Enterprise Chrome auto-update shrinks the reachable window quickly
- This is not wormable and cannot self-propagate across hosts
Trigger misleading browser chrome
- The specific vulnerable UI state must be reachable from web content
- User interaction is required per the published CVSS vector
- Browser UI bugs are brittle across versions, screen sizes, and platform builds
- A lot of users will not proceed unless the spoof looks convincing
- Modern anti-phishing controls may still flag the destination or page content
Convert spoofing into credential theft or click-through
- Victim must trust the spoof enough to enter data or approve a flow
- Targeted application must be susceptible to phishing or consent abuse
- MFA, FIDO2/passkeys, conditional access, and IdP risk checks reduce payoff
- Blast radius is generally limited to the fooled user session, not the endpoint fleet
- No published evidence shows this CVE reliably chaining to device compromise
The supporting signals.
| In-the-wild status | No confirmed exploitation evidence found in reviewed sources, and not listed in CISA KEV as of the catalog state reviewed. That is a major downward pressure on urgency for a browser UI bug. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit repo was found in reviewed sources. Chrome bug details are commonly restricted until most users are patched, so absence of a PoC is *helpful but not definitive*. |
| EPSS | User-supplied EPSS is 0.00025 (0.025%), which is extremely low. I could not independently verify the exact percentile from a primary FIRST record in reviewed search results, so treat percentile as unverified. |
| KEV status | Not KEV-listed in the reviewed CISA KEV catalog. No KEV date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = remote reach, no auth, but user interaction required and no availability impact. That is classic phishing-amplifier territory, not autonomous endpoint takeover. |
| Affected versions | Chrome desktop prior to 149.0.7827.53; official release notes show 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS rolling out in late May 2026. |
| Fixed versions | Patch baseline is 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS, with downstream distro/browser packages backporting the same fix lineage; e.g., openSUSE maintenance references this CVE. |
| Exposure / scanning reality | Shodan/Censys/FOFA are basically not useful here because this is a client-side browser flaw, not an internet-exposed service. Your exposure measurement should come from EDR, software inventory, browser management, or SBOM/package telemetry instead. |
| Disclosure date | User-supplied disclosure date is 2026-06-05. Related vendor and national advisories around the 149.0.7827.53/.54 release landed from May 29, 2026 through June 2, 2026. |
| Researcher / reporter | Specific reporter attribution for this CVE was not located in reviewed primary sources. Comparable Chrome release notes often list the reporter, but details for this issue appear restricted or not yet surfaced publicly. |
noisgate verdict.
The decisive factor is user interaction plus browser-UI-only impact: the attacker still has to land a convincing lure and get a human to trust it. This bug may improve phishing conversion, but the reviewed evidence does not support direct host compromise, broad fleet blast radius, or active exploitation.
Why this verdict
- Start at vendor 6.1, then discount for
UI:R— the attacker cannot cash out without convincing a user to open and trust a crafted page. - Discount again for attack outcome — current public description points to Omnibox/UI deception, not RCE, sandbox escape, or credential exfiltration by itself.
- Discount for exposure measurability and blast radius — this is a client-side browser issue affecting individual user sessions, not an internet-facing enterprise service with fleetwide unauthenticated reach.
- Discount for threat intel — no KEV listing, no confirmed in-the-wild exploitation, and an extremely low user-supplied EPSS materially lower near-term operational risk.
- Add back a little for ubiquity — Chrome is everywhere, and Omnibox trust cues matter, so this is not IGNORE territory.
Why not higher?
There is no evidence here of a clean one-click device compromise, privilege gain, or server-side blast radius. The chain depends on social engineering and likely ends in phishing or UI confusion, which sharply lowers enterprise patch urgency compared with memory corruption or sandbox-escape Chrome bugs.
Why not lower?
It still affects the browser trust surface that users rely on to judge destination legitimacy. In a large enterprise, even a low-grade browser UI bug can modestly improve phishing success, so it deserves routine remediation rather than dismissal.
What to do — in priority order.
- Force browser auto-update — Keep managed Chrome channels pinned to the latest stable build and verify relaunch compliance through your browser management stack. For a LOW verdict there is no fixed mitigation deadline, so treat this as backlog hygiene and absorb it into the normal browser-update cadence.
- Harden phishing-resistant auth — Prefer FIDO2/passkeys, conditional access, and IdP risk checks for high-value apps so a spoofed browser trust cue does not automatically translate into account takeover. For this severity there is no mitigation SLA, but these controls reduce the only realistic payoff path.
- Block risky web categories — Use secure web gateway and DNS filtering to reduce first-touch access to newly registered domains, typo-squats, and known phishing infrastructure. This is most useful while waiting for normal endpoint update convergence.
- Watch for stale Chrome builds — Query EDR/software inventory for versions below
149.0.7827.53and focus on systems with disabled updates, long-lived VDI images, kiosk builds, and unmanaged admin workstations. Those laggards are the real residual risk population.
- A WAF does not help; the vulnerable component is the endpoint browser UI, not your server.
- Network segmentation does not meaningfully reduce exposure; the trigger is a user browsing attacker-controlled content over normal web channels.
- EDR alone is weak here; if exploitation stays in the lane of UI spoofing and phishing, there may be little or no exploit-specific host telemetry.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/live-response tooling. Invoke it with python3 chrome_cve_2026_11273_check.py on macOS/Linux or py chrome_cve_2026_11273_check.py on Windows; no admin rights are usually required if the Chrome binary is in a standard install path. It checks the local Chrome version and reports VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# chrome_cve_2026_11273_check.py
# Detect exposure to CVE-2026-11273 by checking installed Google Chrome version.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
PATCH_LINUX = (149, 0, 7827, 53)
PATCH_WIN_MAC = (149, 0, 7827, 53) # .53/.54 both considered fixed; anything >= .53 is acceptable.
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def compare_versions(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
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(Path(base) / s)
elif system == 'darwin':
paths.extend([
Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
Path('/Applications/Chromium.app/Contents/MacOS/Chromium'),
])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
p = shutil.which(name)
if p:
paths.append(Path(p))
paths.extend([
Path('/opt/google/chrome/chrome'),
Path('/usr/bin/google-chrome'),
Path('/usr/bin/google-chrome-stable'),
Path('/usr/bin/chromium'),
Path('/usr/bin/chromium-browser'),
])
# Deduplicate while preserving order
seen = set()
uniq = []
for p in paths:
s = str(p)
if s not in seen:
seen.add(s)
uniq.append(p)
return uniq
def get_version_from_binary(path):
if not path.exists():
return None, ''
out = run_cmd([str(path), '--version'])
ver = parse_version(out)
return ver, out
def get_windows_registry_version():
reg_paths = [
r'HKLM\Software\Google\Chrome\BLBeacon',
r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\Software\Google\Chrome\BLBeacon',
]
for reg in reg_paths:
out = run_cmd(['reg', 'query', reg, '/v', 'version'])
ver = parse_version(out)
if ver:
return ver, out
return None, ''
def classify(ver):
system = platform.system().lower()
if system == 'linux':
return 'PATCHED' if compare_versions(ver, PATCH_LINUX) >= 0 else 'VULNERABLE'
return 'PATCHED' if compare_versions(ver, PATCH_WIN_MAC) >= 0 else 'VULNERABLE'
def main():
findings = []
if platform.system().lower() == 'windows':
ver, raw = get_windows_registry_version()
if ver:
findings.append(('registry', ver, raw))
for path in candidate_paths():
ver, raw = get_version_from_binary(path)
if ver:
findings.append((str(path), ver, raw))
# Deduplicate by path/source and version
normalized = []
seen = set()
for src, ver, raw in findings:
key = (src, ver)
if key not in seen:
seen.add(key)
normalized.append((src, ver, raw))
if not normalized:
print('UNKNOWN: Could not determine a local Chrome/Chromium version from standard paths or registry.')
sys.exit(2)
statuses = []
for src, ver, raw in normalized:
status = classify(ver)
statuses.append(status)
print(f'{status}: {src} -> {".".join(map(str, ver))}')
if 'VULNERABLE' in statuses:
sys.exit(1)
if 'PATCHED' in statuses:
sys.exit(0)
print('UNKNOWN: Version data found but could not be classified.')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Google Chrome Releases home
- Chrome Enterprise previous release notes
- Update Google Chrome help page
- Canadian Centre for Cyber Security advisory AV26-544
- SecurityWeek - Chrome 149 patches 429 vulnerabilities
- openSUSE maintenance patchinfo referencing CVE-2026-11273
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.