This is a bad lock on an interior office door, not an unlocked front entrance
CVE-2026-11286 is an input-validation flaw in Chrome's Wallet component affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. Based on the supplied description and the surrounding Chrome advisory patterns for this release, the meaningful attack path is not direct internet-to-host compromise: the attacker first needs a renderer-process foothold and then abuses Wallet handling to tamper with browser behavior, with impact closer to *integrity manipulation* than code execution.
Reality is lower than the generic CVSS framing suggests. The decisive friction is the prerequisite: renderer compromise first means this bug is a second-stage helper inside an already-successful browser exploit chain, and there is no evidence here of KEV listing, in-the-wild exploitation, or public weaponized PoC. Chrome's own June 2, 2026 release notes classify this one as Low, which fits enterprise patch priority better than the user-provided 4.3 baseline.
3 steps from start to impact.
Land code in the renderer first
- Target is running vulnerable Chrome before
149.0.7827.53 - Attacker can get the user to load attacker-controlled content
- A separate renderer-compromise bug is available and successful
- This is not a standalone remote exploit
- Modern Chrome exploit chains are expensive and rare compared with commodity phishing
- Browser sandboxing, site isolation, exploit mitigations, and rapid auto-update all work against this step
Drive malformed input into Wallet
- Renderer process is already compromised
- Wallet-related code path is reachable in the victim's browsing session
- Wallet is a narrower feature surface than core HTML/JS rendering
- Enterprises with limited wallet/payment feature use reduce reachable population
- Impact appears limited to low-integrity browser-side effects
Convert browser-side tampering into user harm
- Victim uses the relevant Wallet flow
- Attacker can align timing with a wallet or payment interaction
- User follows through on the manipulated action
- Many enterprise users never touch browser wallet functions
- Managed browser policies can restrict payments, sync, and extensions
- MFA, payment controls, and user friction reduce successful abuse
The supporting signals.
| In-the-wild status | No public evidence found of active exploitation specific to CVE-2026-11286, and it is not in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC repo or write-up found for this CVE. The Chromium issue exists at issues.chromium.org but is access-restricted, which is common for fresh Chrome bugs. |
| EPSS | User-supplied EPSS is 0.00022, which is effectively floor-level exploit likelihood for broad internet activity. |
| KEV status | Not KEV-listed as of the CISA catalog checked today; no CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N maps to *user interaction required* and only *low integrity* impact. That already caps urgency unless exploitation evidence shows otherwise. |
| Affected versions | Google's June 2, 2026 stable-channel advisory says Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS is affected. |
| Fixed versions | Patch level is Chrome 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS. openSUSE also lists this fix in its Chromium 149 update: patchinfo. |
| Scanning / exposure reality | Shodan/Censys/FOFA are poor signals here because Chrome is a client-side browser flaw, not an internet-listening service. Real exposure is endpoint population, and Chrome still held about 65.14% US desktop browser share in StatCounter's May 2026 data, so fleet prevalence is high even though internet discoverability is low. |
| Disclosure timeline | There is a date mismatch worth noting: the user supplied 2026-06-05, but Google's public stable-channel bulletin for the fixed build is dated June 2, 2026. |
| Reporter / source | Google's advisory attributes this CVE to Google and lists the report date as 2026-04-13. |
noisgate verdict.
The single biggest severity reducer is that this bug only matters after a renderer compromise already exists, which makes it post-initial-access and sharply narrows the real attacker population. In a 10,000-host fleet, that means this CVE is not your front-door problem; it is a low-value link in a much harder browser exploit chain.
Why this verdict
- Major downward pressure: requires prior compromise. A renderer foothold implies the attacker has already beaten Chrome's primary content-execution boundary with a separate bug or chain.
- Reachability is narrow. This sits in
Wallet, not a ubiquitous parser like V8, Image, or PDFium, so only a subset of browsing sessions ever exercises the interesting code path. - No field evidence. No KEV listing, no public PoC, and the supplied EPSS is near-zero, which is exactly what low-priority browser follow-on bugs tend to look like.
Why not higher?
There is no credible case for HIGH or CRITICAL without evidence that CVE-2026-11286 is independently exploitable from the web. The need for a prior renderer compromise compounds with likely user-context requirements around wallet/payment flows, cutting both attacker reach and operational blast radius.
Why not lower?
It is still a real security bug in a massively deployed browser, and Chrome's footprint means even low-probability edge cases can exist somewhere in a large estate. Also, Wallet-adjacent integrity flaws can amplify fraud or spoofing after compromise, so this should stay on the patch backlog rather than be ignored.
What to do — in priority order.
- Enforce evergreen browser updates — Make sure managed Chrome channels auto-update and that version drift is visible in your endpoint tooling. For a LOW verdict there is no mitigation deadline; treat this as backlog hygiene and close it in your normal browser maintenance cycle.
- Reduce renderer-to-wallet reach — Use enterprise browser policy to limit unneeded payment, wallet, and extension features where business use is low. This cuts reachable attack surface while the normal patch wave finishes; for LOW, there is no mitigation SLA, so do this as policy hardening rather than emergency response.
- Hunt for unmanaged Chrome variants — The practical risk is stale side-loaded Chrome/Chromium builds on developer and BYOD-adjacent systems, not your centrally managed stable channel. Fold detection into routine hygiene and remove or update stragglers during the normal backlog window.
- A perimeter firewall or WAF does not meaningfully help; this is a client-side browser flaw, not a server-side web app issue.
- Relying on EDR alone is weak because EDR may catch the *precursor exploit chain* but usually will not tell you that this specific Wallet validation bug was reachable.
- Internet exposure scans are misleading here; Shodan/Censys can tell you nothing useful about whether endpoints run vulnerable Chrome versions.
Crowdsourced verification payload.
Run this on the target endpoint or through your RMM/EDR live-response shell. Invoke it as python3 verify_cve_2026_11286.py on Linux/macOS or py verify_cve_2026_11286.py on Windows; it needs only normal read access to common install paths and registry keys.
#!/usr/bin/env python3
# verify_cve_2026_11286.py
# Checks local Google Chrome / Chromium version against fixed build for CVE-2026-11286.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
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_to_str(v):
return '.'.join(str(x) for x in v)
def compare(v1, v2):
return (v1 > v2) - (v1 < v2)
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 or p.stderr).strip()
except Exception:
pass
return None
def find_windows_version():
commands = [
['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'],
['powershell', '-NoProfile', '-Command', r"(Get-ItemProperty 'HKLM:\Software\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
['powershell', '-NoProfile', '-Command', r"(Get-ItemProperty 'HKLM:\Software\WOW6432Node\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
['powershell', '-NoProfile', '-Command', r"(Get-ItemProperty 'HKCU:\Software\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
]
for cmd in commands:
out = run_cmd(cmd)
v = parse_version(out or '')
if v:
return ('Google Chrome', v)
paths = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles%\Chromium\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Chromium\Application\chrome.exe'),
]
for p in paths:
if p and os.path.exists(p):
out = run_cmd([p, '--version'])
v = parse_version(out or '')
if v:
name = 'Chromium' if 'Chromium' in (out or '') else 'Google Chrome'
return (name, v)
return None
def find_macos_version():
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
]
for p in paths:
if os.path.exists(p):
out = run_cmd([p, '--version'])
v = parse_version(out or '')
if v:
name = 'Chromium' if 'Chromium' in (out or '') else 'Google Chrome'
return (name, v)
return None
def find_linux_version():
commands = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium', '--version'],
['chromium-browser', '--version'],
]
for cmd in commands:
out = run_cmd(cmd)
v = parse_version(out or '')
if v:
name = 'Chromium' if 'Chromium' in (out or '') else 'Google Chrome'
return (name, v)
return None
def main():
system = platform.system().lower()
result = None
if 'windows' in system:
result = find_windows_version()
elif 'darwin' in system:
result = find_macos_version()
else:
result = find_linux_version()
if not result:
print('UNKNOWN: Chrome/Chromium version could not be determined on this host')
sys.exit(2)
name, version = result
if compare(version, FIXED) < 0:
print(f'VULNERABLE: {name} {version_to_str(version)} < fixed {version_to_str(FIXED)}')
sys.exit(1)
else:
print(f'PATCHED: {name} {version_to_str(version)} >= fixed {version_to_str(FIXED)}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53 stragglers while you spend urgent effort on first-stage browser RCEs and KEV-listed flaws instead.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.