This is a peeping hole in the wall, not a front-door kick-in
CVE-2026-10998 is an out-of-bounds read in Chrome's Media component affecting Google Chrome versions prior to 149.0.7827.53. Public wording says the attacker must be on the *local network segment*, which makes this an adjacent-network bug rather than an internet-reachable browser issue. The disclosed impact is memory disclosure, not code execution: think small slices of process memory if a crafted media-related network interaction reaches the vulnerable path.
The vendor's MEDIUM bucket is basically right, but the supplied AV:L score baseline is too low-level for the actual story. If the advisory text is accurate, this is closer to *adjacent network* reachability than *local attacker on the host*, so I bump the score a bit; still, the local-LAN prerequisite, sparse technical disclosure, lack of exploitation evidence, and low confidentiality-only impact keep it firmly out of HIGH.
4 steps from start to impact.
Get onto the victim's network segment
- Attacker has adjacent-network access to the target
- Victim endpoint is running vulnerable Chrome prior to 149.0.7827.53
- Requires post-compromise or physical proximity in many real environments
- Segmentation, NAC, and separate guest SSIDs can cut this path off entirely
Reach the media-related network handling path
- A media/network feature path in Chrome is active or reachable
- The crafted traffic reaches the target endpoint without being filtered
- Sparse public bug detail means weaponization is less turnkey
- Feature-specific trigger paths usually reduce exploitable population versus broad HTML/JS bugs
Trigger the out-of-bounds read
- Targeted parser/state machine accepts the crafted input
- Browser process survives long enough to expose useful memory
- Many OOB reads crash noisily before producing useful data
- Chrome sandboxing and memory-hardening reduce blast radius
Turn disclosure into useful theft
C:L disclosed, expect limited and situational value rather than broad account takeover at scale. That makes exploitation opportunistic, not a dependable enterprise-wide kill chain.- Leaked memory contains sensitive material
- Attacker can capture or reconstruct returned/crashed-state data
- Low-confidence reward from each attempt
- No published evidence that attackers are chaining this into reliable post-exploitation
The supporting signals.
| In-the-wild status | No public exploitation evidence found in retrieved sources; not KEV-listed. |
|---|---|
| Proof-of-concept availability | No public PoC or weaponized repo found in retrieved sources. |
| EPSS | User-supplied EPSS is 0.00005, which is effectively near-floor exploit probability; percentile was not independently confirmed from retrieved FIRST data. |
| KEV status | No — absent from the CISA KEV catalog as checked against retrieved sources. |
| CVSS vector reality check | Vendor-supplied vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, but the description says *attacker on the local network segment*, which operationally reads more like adjacent network than local host. |
| Affected versions | Google Chrome prior to 149.0.7827.53; retrieved Chrome release material shows 149.0.7827.53/.54 in the early stable rollout for desktop. |
| Fixed version | Patch baseline is 149.0.7827.53; later tags such as 149.0.7827.54 and above are beyond the vulnerable cutoff. |
| Exposure model | This is client-side adjacent-network exposure, not a public-facing server surface. Shodan/Censys-style internet counts are therefore not a meaningful prioritization signal. |
| Disclosure date | 2026-06-04 per the supplied intel and third-party CVE aggregators in retrieved results. |
| Reporting details | Publicly retrieved sources did not expose a researcher credit or bug ID for this specific CVE; Chrome often withholds bug detail until most users are updated. |
noisgate verdict.
The decisive factor is the attacker position requirement: same-LAN access massively shrinks the reachable population compared with normal Chrome drive-by bugs. I raised the score slightly because the published description implies adjacent-network reachability rather than a purely local-on-host attacker, but the limited confidentiality impact and zero exploitation evidence keep it in MEDIUM.
Why this verdict
- Baseline adjusted up: vendor says MEDIUM/4, but the description says *local network segment*, which is more reachable than
AV:Land justifies a modest score increase. - Major downward pressure: attacker must be on the same network segment, which usually implies physical proximity, rogue Wi-Fi presence, or a prior internal foothold.
- Impact capped: disclosed effect is out-of-bounds read with
C:L/I:N/A:N, so this is not the kind of Chrome bug that reliably turns into endpoint takeover.
Why not higher?
Because every serious step in the chain narrows the real-world population: adjacent network only, likely feature-specific traffic, and confidentiality-only impact. If this were internet-reachable or paired with code execution, the score would jump fast; it is not.
Why not lower?
Because Chrome is ubiquitous, no user interaction is stated, and a hostile same-LAN actor is a real enterprise scenario on guest Wi-Fi, branch networks, and already-compromised segments. Also, the vendor's AV:L framing likely understates operational reachability if the advisory text is taken at face value.
What to do — in priority order.
- Enforce browser auto-update compliance — Make sure managed endpoints actually converge on
149.0.7827.53or later and flag stragglers via fleet inventory. For a MEDIUM finding there is no mitigation SLA — use this as routine control enforcement while you work inside the 365-day remediation window. - Segment guest and untrusted Wi-Fi from corporate endpoints — The bug's entire value proposition starts with adjacent-network access, so isolate guest SSIDs, contractor VLANs, lab segments, and unmanaged BYOD away from employee workstations. There is no mitigation SLA for MEDIUM, but this is worthwhile hardening immediately because it cuts off the main prerequisite.
- Restrict local discovery and casting where unused — If your environment does not need media discovery/casting workflows, limit or disable them through enterprise policy and network controls such as mDNS/SSDP filtering between segments. This is a temporary exposure reducer, not a substitute for patching, and for MEDIUM there is no mitigation SLA.
- Watch for Chrome crash clusters — Correlate EDR/browser telemetry for sudden spikes in
chromerenderer/GPU/media-process crashes on specific Wi-Fi or branch segments. Use it as a hunting signal while the fleet rolls forward; there is no mitigation SLA for MEDIUM.
- A generic perimeter WAF does not help; the attack is not described as a public web-app request path.
- MFA is irrelevant to the memory-safety trigger itself; it may reduce follow-on abuse of stolen data, but it does not stop the browser bug.
- Internet exposure reduction alone misses the point; this is about adjacent-network reachability, not inbound exposure from the public internet.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tooling. Invoke it with python3 verify_cve_2026_10998.py on macOS/Linux or py verify_cve_2026_10998.py on Windows; no admin rights are usually needed, though registry access on locked-down Windows images may require standard local read permissions.
#!/usr/bin/env python3
# verify_cve_2026_10998.py
# Checks whether Google Chrome is older than 149.0.7827.53
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
PATCHED = (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 cmp_version(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 get_windows_version():
candidates = [
["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"],
]
for cmd in candidates:
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v
exe_candidates = [
os.path.join(os.environ.get("ProgramFiles", r"C:\Program Files"), "Google", "Chrome", "Application", "chrome.exe"),
os.path.join(os.environ.get("ProgramFiles(x86)", r"C:\Program Files (x86)"), "Google", "Chrome", "Application", "chrome.exe"),
os.path.join(os.environ.get("LOCALAPPDATA", ""), "Google", "Chrome", "Application", "chrome.exe"),
]
for exe in exe_candidates:
if exe and os.path.exists(exe):
out = run_cmd([exe, "--version"])
v = parse_version(out)
if v:
return v
return None
def get_macos_version():
app = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
if os.path.exists(app):
out = run_cmd([app, "--version"])
v = parse_version(out)
if v:
return v
mdls = run_cmd(["mdls", "-name", "kMDItemVersion", "/Applications/Google Chrome.app"])
v = parse_version(mdls)
if v:
return v
return None
def get_linux_version():
bins = ["google-chrome", "google-chrome-stable", "chrome"]
for b in bins:
path = shutil.which(b)
if path:
out = run_cmd([path, "--version"])
v = parse_version(out)
if v:
return v
return None
def main():
system = platform.system().lower()
if 'windows' in system:
ver = get_windows_version()
elif 'darwin' in system:
ver = get_macos_version()
else:
ver = get_linux_version()
if not ver:
print("UNKNOWN")
sys.exit(2)
if cmp_version(ver, PATCHED) < 0:
print("VULNERABLE")
sys.exit(1)
else:
print("PATCHED")
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
149.0.7827.53, especially on laptops that roam onto shared Wi-Fi, branch offices, labs, and contractor networks. For a MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, because this is Chrome and updates are easy, use your normal browser ring to get compliant quickly and finish well inside the noisgate remediation SLA of ≤365 days, while using segmentation and discovery/casting restrictions as temporary exposure reducers for laggards.Sources
- Chrome Releases: Early Stable Update for Desktop
- Chrome for Developers: Change in release schedule from Chrome 110
- Chromium source tags including 149.0.7827.53
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS data and statistics
- Quanteta CVE tracker entry set showing CVE-2026-10998 metadata
- VulDB search result for CVE-2026-10998
- CVE.report search result containing CVE-2026-10998
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.