This is less a front-door break-in than tricking someone to unlock the maintenance panel from inside
Based on the prompt, this issue affects Google Chrome before 149.0.7827.53 and sits in DevTools, not the normal browsing path. That matters: the exploit chain is not just 'visit a page and lose the box' — the attacker still has to steer the victim into a DevTools-driven workflow or specific UI action, which sharply narrows the reachable population inside a 10,000-host estate.
There is an intel quality problem here: Google's June 2026 desktop release notes list CVE-2026-11022 as a *Medium* DevTools input-validation bug and do not show CVE-2026-10922 in that release. So I am treating your submission as a first-principles assessment of the described DevTools flaw, not blindly inheriting severity from mismatched metadata. On real-world conditions, this lands at = ASSESSED AT MEDIUM because Chrome is everywhere, but the exploit path is gated by DevTools usage and user interaction rather than broad drive-by reach.
4 steps from start to impact.
Deliver a crafted web lure
- Victim uses Chrome below
149.0.7827.53 - Victim can be reached by web content, link, or embedded browser workflow
- Attacker can socially engineer a user into following instructions
- This is not an unauthenticated service listening on the internet
- Email security, URL filtering, and browser isolation can block the lure before the bug matters
- No public in-the-wild exploitation evidence found
Move the victim into DevTools
- Victim is willing and able to open DevTools or perform the required UI gestures
- Chrome policies do not fully restrict DevTools usage
- The exploit path depends on the exact vulnerable interaction surface in DevTools
- Most enterprise users never touch DevTools
- Managed-browser policy can restrict DevTools in some populations
- User training and secure admin workstation patterns reduce compliance with 'press F12 and paste this' lures
Trigger the input-validation flaw through the DevTools UI
- The vulnerable code path is reached in the installed Chrome build
- The victim performs the exact sequence the exploit expects
- Browser hardening or policy does not break the exploit chain
- Restricted bug details make copycat exploitation slower
- Modern Chrome sandboxing and site isolation reduce blast radius for many browser-only bugs
- A fragile UI-driven exploit often breaks across minor build, locale, or workflow differences
Harvest browser-side impact
- Victim session contains data worth stealing or privileged access worth abusing
- The attacker can monetize browser-context access
- No downstream controls interrupt follow-on abuse
- Impact is usually tied to the active user session, not full fleet compromise
- EDR, CASB, and IdP anomaly detection may catch follow-on abuse
- Blast radius is endpoint- and session-scoped unless chained with another bug
The supporting signals.
| Record quality | Intel mismatch: Google’s June 2026 Chrome desktop release notes show CVE-2026-11022 as the DevTools input-validation entry; CVE-2026-10922 is not listed there. I assessed the *described flaw*, not the typo. |
|---|---|
| In-the-wild status | No confirmed active exploitation found. Google’s June 2, 2026 desktop advisory does not include the explicit 'Google is aware of an exploit' language it uses on real zero-days like CVE-2025-6554. |
| KEV status | Not KEV-listed based on the current CISA KEV catalog. |
| EPSS | 0.00021 from your prompt. That is effectively background noise and fits the narrow, user-steered DevTools attack path. |
| Proof-of-concept availability | No public PoC located for CVE-2026-10922, and no public exploit repository surfaced for the likely intended CVE-2026-11022 either. |
| Affected versions | Prompt states Chrome before 149.0.7827.53. Google’s desktop update on June 2, 2026 patched Windows/macOS at 149.0.7827.53/.54 and Linux at 149.0.7827.53. |
| Fixed versions | Windows/macOS: 149.0.7827.53/.54 or later. Linux: 149.0.7827.53 or later. Chrome on Android inherited the same desktop security fixes in 149.0.7827.59. |
| Vendor severity baseline | None for CVE-2026-10922. For the likely adjacent official record, Google labeled CVE-2026-11022 (DevTools, insufficient validation of untrusted input) as Medium in the June 2026 stable release. |
| Comparable Chrome history | Chrome has rated similar DevTools bugs across Low to Medium: CVE-2025-4051 was Medium, while CVE-2026-5901 (policy bypass in DevTools) and CVE-2026-11250 (inappropriate implementation in DevTools) were Low. |
| Exposure reality | Product exposure is huge; vulnerable workflow exposure is not. Chrome is ubiquitous, but only a minority of enterprise users enter DevTools or comply with DevTools-specific lures, which is the main downward pressure on severity. |
noisgate verdict.
The single biggest severity reducer is the DevTools interaction requirement: this is not broadly reachable through normal browsing and it does not behave like a mass-exploitable browser zero-click. I kept it at MEDIUM instead of LOW because Chrome is everywhere, the component sits on sensitive admin/developer workstations, and browser security-boundary flaws can still be valuable when they land on the right user.
Why this verdict
- Downward adjustment: requires attacker steering into DevTools — that implies a narrower user population than ordinary drive-by browser bugs and usually means developers, admins, or power users.
- Downward adjustment: user interaction is part of the exploit chain — the attacker needs a believable lure and exact actions, which modern web/email controls and user skepticism frequently break.
- Downward adjustment: no active exploitation or KEV signal — there is no evidence this is being operationalized in the wild today, and the EPSS provided is extremely low.
- Upward adjustment: Chrome is fleet-wide software — even a niche browser bug matters when the product footprint is enormous and privileged users browse from sensitive endpoints.
- Upward adjustment: browser-session impact can still be valuable — successful exploitation against an admin or developer workstation can expose cross-origin data, tokens, or follow-on access despite the narrow entry path.
Why not higher?
This does not read like an internet-facing service bug, a zero-click browser exploit, or a confirmed in-the-wild Chrome zero-day. The path is gated by DevTools-specific behavior and likely exact UI actions, which is too much friction for a HIGH or CRITICAL rating in a real enterprise environment.
Why not lower?
Chrome is one of the highest-footprint applications in the enterprise, and browser flaws on privileged workstations can turn into meaningful access even when the initial primitive is constrained. The combination of large deployment base plus potentially sensitive user populations keeps this above simple backlog-only hygiene.
What to do — in priority order.
- Enforce Chrome auto-update — Make sure managed endpoints are actually consuming the fixed builds and not pinned on stale versions by broken update rings or frozen VDI images. For a MEDIUM finding there is no mitigation SLA, but this is still the cleanest control to deploy while you work through the remediation window.
- Restrict DevTools where you can — Use Chrome enterprise policy to disable or limit DevTools for non-developer populations, kiosks, and shared admin jump boxes where it is not business-required. This directly attacks the main prerequisite in the exploit chain; for MEDIUM, there is no mitigation SLA.
- Segregate privileged browsing — Keep admin, cloud control-plane, and production support sessions off general-purpose browsing endpoints or run them in hardened admin workstations/browser isolation. That reduces the payoff if a user-targeted browser exploit lands; for MEDIUM, there is no mitigation SLA.
- Block 'open DevTools and do X' social engineering — Tune secure email/web awareness and detection rules around lures that instruct users to press
F12, paste console snippets, or inspect elements. That is a high-signal behavioral choke point for this class of issue; for MEDIUM, there is no mitigation SLA.
WAFdoes not solve an endpoint-side DevTools bug; the vulnerable parser/UI lives in the browser, not your edge reverse proxy.Perimeter vulnerability scanningwill mostly miss this because the issue is triggered through local browser behavior, not a remotely fingerprintable server banner.MFAhelps for account takeover aftermath but does not prevent exploitation of the browser bug itself.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory agent. Invoke it with python3 check_chrome_149.py on macOS/Linux or py check_chrome_149.py on Windows; no admin rights are required, though access to the Windows registry improves coverage. It checks common Chrome/Chromium install locations and prints exactly one of VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_149.py
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
TARGET = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(text):
if not text:
return None
m = VERSION_RE.search(text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_version(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def windows_registry_versions():
versions = []
try:
import winreg
except Exception:
return versions
paths = [
r'SOFTWARE\Google\Chrome\BLBeacon',
r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
r'SOFTWARE\Chromium\BLBeacon',
r'SOFTWARE\WOW6432Node\Chromium\BLBeacon',
]
hives = []
try:
import winreg
hives = [winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE]
for hive in hives:
for path in paths:
try:
k = winreg.OpenKey(hive, path)
val, _ = winreg.QueryValueEx(k, 'version')
v = parse_version(str(val))
if v:
versions.append(('registry:' + path, v))
except Exception:
pass
except Exception:
pass
return versions
def windows_file_versions():
candidates = [
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'),
]
found = []
for path in candidates:
if path and os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
found.append((path, v))
return found
def unix_versions():
names = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser',
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
'/usr/bin/google-chrome', '/usr/bin/google-chrome-stable',
'/usr/bin/chromium', '/usr/bin/chromium-browser'
]
found = []
for name in names:
path = shutil.which(name) if not name.startswith('/') else name
if path and os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
found.append((path, v))
return found
def main():
system = platform.system().lower()
detections = []
if 'windows' in system:
detections.extend(windows_registry_versions())
detections.extend(windows_file_versions())
else:
detections.extend(unix_versions())
# Deduplicate by version while preserving evidence paths
if not detections:
print('UNKNOWN')
sys.exit(2)
# If any detected Chrome/Chromium build is below target, mark vulnerable.
vulnerable = []
patched = []
for src, ver in detections:
if cmp_version(ver, TARGET) < 0:
vulnerable.append((src, ver))
else:
patched.append((src, ver))
if vulnerable:
print('VULNERABLE')
for src, ver in vulnerable:
print(f'{src} -> {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]}')
sys.exit(1)
if patched:
print('PATCHED')
for src, ver in patched:
print(f'{src} -> {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]}')
sys.exit(0)
print('UNKNOWN')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53/.54, let standard Chrome update channels pull them forward, and finish patching within the noisgate remediation SLA of ≤365 days. If you have developer workstations, admin browsers, kiosks, or VDI images with frozen Chrome builds, prioritize those first because they are the subset most likely to satisfy the DevTools prerequisite.Sources
- Google Chrome Releases 2026 overview with June 2 desktop update and CVE listings
- Chrome stable desktop update April 29, 2025 showing Medium DevTools CVE-2025-4051
- Chrome stable desktop update April 2026 showing Low DevTools policy-bypass precedent
- Canadian Centre for Cyber Security advisory for Chrome versions prior to 149.0.7827.53/54
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- FIRST EPSS overview
- Chrome stable desktop update June 30, 2025 showing how Google flags active exploitation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.