This is a peephole in the browser sandbox, not a front-door break-in
CVE-2026-7999 is an *information disclosure* bug in Chrome's V8 JavaScript engine. A remote attacker can serve a crafted HTML page that causes the browser to expose potentially sensitive data from process memory. The affected range is Google Chrome prior to 148.0.7778.96 on Linux and prior to 148.0.7778.96/97 on Windows and macOS; Chromium downstreams inherit the same engine fix on their own release cadence.
In practice, the scary part is the browser ubiquity, not the impact class. This is not remote code execution, not sandbox escape, and not a server-side bug attackers can mass-scan from the internet. The vendor-side picture is also telling: Chromium labeled it *Low* severity even though NVD scored it 4.3 as Medium. Reality is closer to Chromium's label because exploitation requires a user to render attacker content and the likely payoff is limited memory disclosure from a browser process, which is usually more valuable as a chain component than as a one-shot enterprise incident.
3 steps from start to impact.
Deliver crafted web content
- Target runs vulnerable Chrome/Chromium-derived browser build
- Target visits attacker-controlled or attacker-tainted web content
- JavaScript execution is allowed
- Requires *user interaction* and browser rendering of hostile content
- Enterprise URL filtering, Safe Browsing, DNS controls, and ad-blocking reduce reach
- No public PoC or active-campaign reporting found, so attacker tradecraft is not yet commoditized
Trigger V8 information disclosure
- The bug is reachable through the target's exact browser build
- Relevant V8 execution path is hit by the crafted page
- Browser process isolation and modern hardening constrain what memory is exposed
- The value of leaked data depends heavily on what happened to be resident in that process
- Reliability may vary by OS, tab/process model, and site isolation state
Extract useful secrets or chain onward
- Leaked memory contains actionable secrets or useful exploit material
- Attacker can exfiltrate data before the browsing session ends
- Many sessions will leak low-value or non-reusable data
- Site isolation and separate renderer processes reduce cross-site jackpot outcomes
- Standalone blast radius is usually one browser process for one user
The supporting signals.
| In-the-wild status | No evidence of active exploitation in the reviewed source set. Chromium's release note does not flag exploitation, and CISA KEV does not list CVE-2026-7999. |
|---|---|
| PoC availability | No public GitHub PoC or exploit write-up was found in the reviewed sources. Chromium bug links remain partially restricted, which is common early in the patch window. |
| EPSS | 0.00031 from the user-supplied intel — extremely low predicted exploitation probability. Percentile was not independently verified from the accessible FIRST source set. |
| KEV status | Not KEV-listed as of 2026-05-29 based on the current CISA catalog page reviewed. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N = remote delivery with user interaction required, confidentiality-only impact, and no integrity/availability damage. |
| Affected versions | Google Chrome before 148.0.7778.96 on Linux and before 148.0.7778.96/97 on Windows/macOS. Chromium downstreams pick up the same engine fix on their own schedules. |
| Fixed versions | Google Chrome fixed in 148.0.7778.96/97. Microsoft Edge Stable incorporated the Chromium security fixes in 148.0.3967.54 on 2026-05-07. Debian backports show 148.0.7778.96-1~deb12u1 for bookworm and 148.0.7778.96-1~deb13u1 for trixie. |
| Scanning / exposure reality | This is a client-side browser bug, so Shodan/Censys/FOFA-style internet census data is mostly irrelevant. GreyNoise-style scanning telemetry is also a poor fit because attackers target *users*, not exposed TCP services; asset inventory and EDR software version data are the authoritative exposure sources. |
| Disclosure timeline | Published 2026-05-06 in NVD/CVE context; Chrome 148 stable with the fix began rolling out on 2026-05-05. |
| Reporting researcher | Reported by Taisic Yun (@taisic) of Theori on 2026-03-16, per the Chromium release note. |
noisgate verdict.
The decisive factor is that this is a *user-driven, client-side information leak* rather than a remotely reachable service bug or code-execution primitive. Even on a 10,000-host fleet, the expected blast radius is usually one user session at a time unless an attacker already has strong lure delivery and a follow-on chain.
Why this verdict
- Downgrade for attacker position: exploitation starts from hostile web content rendered by a user, not an unauthenticated hit on an enterprise service. That sharply narrows reachable population compared with internet-facing RCEs.
- Downgrade for impact class: public descriptions support *confidentiality-only* process-memory disclosure, not code execution, persistence, or server compromise. The likely outcome is opportunistic data leakage or exploit-chain support, not instant fleet damage.
- Downgrade for ecosystem signals: Chromium itself labeled the bug *Low* severity, EPSS is extremely low, there is no KEV entry, and no public PoC or campaign reporting was found. Those are strong downward indicators against a Medium operational priority.
Why not higher?
To rate this Medium or higher, you would want at least one amplifier: public exploit code, active exploitation, evidence of cross-origin high-value token leakage at scale, or demonstrated use as a reliable exploit-chain primitive. None of that is present in the reviewed source set. This is also a browser client bug with required user interaction, which keeps mass exploitation slower and noisier than service-side vulnerabilities.
Why not lower?
It is still a remote bug in a massively deployed browser, and browsers sit directly on hostile content all day. Information disclosure flaws in V8 can matter because they sometimes expose session material or help stabilize later exploitation, so ignoring it entirely would be too casual for a large endpoint fleet.
What to do — in priority order.
- Enforce browser auto-update — Make sure Chrome and Edge stable channels are updating without user discretion, and verify failed-update populations in your software inventory. For a LOW verdict there is no mitigation SLA and no remediation SLA; treat this as backlog hygiene and close it in the next normal browser servicing wave.
- Turn on hardened browsing modes for high-risk users — Use Microsoft Edge Enhanced Security mode or equivalent hardened browser settings for admins, executives, finance, and researchers who frequently touch untrusted sites. These controls reduce exploit reliability by disabling or constraining risky JIT-driven paths; for LOW, deploy as normal hardening rather than emergency change.
- Reduce exposure to untrusted web content — Keep Safe Browsing, DNS filtering, URL filtering, and ad/malvertising controls enabled so fewer endpoints ever render hostile pages. For this verdict, that is general defense-in-depth work with no special deadline beyond your routine endpoint hardening backlog.
- Use browser or remote isolation for risky populations — If you already run RBI/browser isolation for contractors, kiosks, or privileged users, keep those groups in it because it directly blunts browser-side content exploitation. This is optional risk reduction, not emergency containment, under a LOW assessment.
- A perimeter firewall does not solve this; the exploit arrives over ordinary web browsing traffic the user is already allowed to make.
- Server-side WAF rules do not meaningfully help unless you control the destination site and can sanitize or block the malicious content before users render it.
- Credential rotation by itself is overkill here; there is no evidence this bug directly yields account takeover without a successful leak of something actually reusable.
Crowdsourced verification payload.
Run this on the endpoint itself or through your EDR/MDM script runner. Invoke it with python3 check_cve_2026_7999.py or python check_cve_2026_7999.py --product chrome; no admin rights are normally required, though reading app paths on some managed builds may work more reliably with elevated context.
#!/usr/bin/env python3
# check_cve_2026_7999.py
# Detect vulnerable Chrome / Edge versions for CVE-2026-7999.
# Outputs one of: 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
from typing import Optional, Tuple, List
TARGETS = {
'chrome': {
'linux': '148.0.7778.96',
'darwin': '148.0.7778.97',
'windows': '148.0.7778.97',
},
'edge': {
'linux': '148.0.3967.54',
'darwin': '148.0.3967.54',
'windows': '148.0.3967.54',
}
}
def norm_os() -> str:
s = platform.system().lower()
if 'windows' in s:
return 'windows'
if 'darwin' in s or 'mac' in s:
return 'darwin'
return 'linux'
def parse_ver(v: str) -> Tuple[int, ...]:
nums = re.findall(r'\d+', v)
return tuple(int(x) for x in nums)
def cmp_ver(a: str, b: str) -> int:
av = list(parse_ver(a))
bv = list(parse_ver(b))
n = max(len(av), len(bv))
av += [0] * (n - len(av))
bv += [0] * (n - len(bv))
if av < bv:
return -1
if av > bv:
return 1
return 0
def run_version(cmd: List[str]) -> Optional[str]:
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
m = re.search(r'(\d+\.\d+\.\d+\.\d+)', out)
return m.group(1) if m else None
except Exception:
return None
def candidates(product: str, osname: str) -> List[List[str]]:
cmds = []
if osname == 'linux':
if product == 'chrome':
for exe in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
path = shutil.which(exe)
if path:
cmds.append([path, '--version'])
elif product == 'edge':
for exe in ['microsoft-edge', 'microsoft-edge-stable']:
path = shutil.which(exe)
if path:
cmds.append([path, '--version'])
elif osname == 'darwin':
if product == 'chrome':
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
]
else:
paths = [
'/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge',
os.path.expanduser('~/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge')
]
for p in paths:
if os.path.exists(p):
cmds.append([p, '--version'])
elif osname == 'windows':
base = []
for env in ['ProgramFiles', 'ProgramFiles(x86)', 'LocalAppData']:
val = os.environ.get(env)
if val:
base.append(val)
if product == 'chrome':
rels = [
['Google', 'Chrome', 'Application', 'chrome.exe'],
]
else:
rels = [
['Microsoft', 'Edge', 'Application', 'msedge.exe'],
]
for b in base:
for rel in rels:
p = os.path.join(b, *rel)
if os.path.exists(p):
cmds.append([p, '--version'])
return cmds
def detect_one(product: str) -> Tuple[str, Optional[str], Optional[str]]:
osname = norm_os()
fixed = TARGETS[product][osname]
for cmd in candidates(product, osname):
ver = run_version(cmd)
if ver:
if cmp_ver(ver, fixed) < 0:
return ('VULNERABLE', ver, fixed)
return ('PATCHED', ver, fixed)
return ('UNKNOWN', None, fixed)
def main() -> int:
ap = argparse.ArgumentParser(description='Check Chrome / Edge version exposure for CVE-2026-7999')
ap.add_argument('--product', choices=['chrome', 'edge', 'both'], default='both', help='Product to check')
args = ap.parse_args()
products = ['chrome', 'edge'] if args.product == 'both' else [args.product]
results = []
for prod in products:
status, ver, fixed = detect_one(prod)
results.append((prod, status, ver, fixed))
for prod, status, ver, fixed in results:
found = ver if ver else 'not found'
print(f'{prod.upper()}: {status} (found={found}, fixed>={fixed})')
# Decision logic:
# - If any installed checked product is vulnerable => VULNERABLE
# - Else if at least one checked product is patched and none vulnerable => PATCHED
# - Else => UNKNOWN
if any(r[1] == 'VULNERABLE' for r in results):
print('VULNERABLE')
return 1
if any(r[1] == 'PATCHED' for r in results) and not any(r[1] == 'VULNERABLE' for r in results):
print('PATCHED')
return 0
print('UNKNOWN')
return 2
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
148.0.7778.96/97 and Edge below 148.0.3967.54, make sure browser auto-update failures are getting corrected, and roll the remaining stragglers into the next normal desktop/browser patch wave. Because this is LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA; treat it as backlog hygiene, but keep an eye on threat intel in case a browser exploit chain or public PoC appears and forces a reprioritization.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.