This is breaking into a locked office cubicle, not the whole building
CVE-2026-11077 is a memory-safety flaw in Dawn, Chromium's WebGPU implementation, affecting Chrome builds before 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. Google's own release notes describe it as an out-of-bounds read in Dawn reported on 2026-04-06; the broader CVSS framing in your intel block treats it like arbitrary code execution inside the browser sandbox via a crafted HTML page.
That vendor-style 8.8/HIGH overstates enterprise patch urgency for defenders. The real friction is stacking: attacker needs a user to hit a malicious page, the primitive is still inside the renderer sandbox, there is no KEV listing, no public exploitation evidence, and EPSS is extremely low; this is a browser exploit-chain component, not a stand-alone workstation takeover.
4 steps from start to impact.
Land the user on attacker HTML
- Victim uses Chrome prior to 149.0.7827.53/.54
- Victim loads attacker-controlled or attacker-influenced web content
- Relevant WebGPU/Dawn path is reachable on that endpoint
- Requires UI:R; this is not a drive-by daemon exploit against a server
- Secure web gateway, ad-blocking, URL filtering, and browser isolation can cut reach sharply
- Some enterprise VDI/headless/unsupported GPU setups will not exercise the same graphics path
Trigger the Dawn memory bug
- The page can invoke the vulnerable API path
- Heap/layout conditions line up well enough for exploitation
- Google classed this specific bug as Medium in its own release notes
- An out-of-bounds read is weaker than a clean browser-to-OS takeover primitive
- Bug details are still restricted, which usually slows commodity weaponization
Gain code execution in the sandboxed renderer
- Exploit is reliable enough to move beyond crash-only behavior
- Chrome sandbox remains the only containment boundary being crossed so far
- Renderer sandbox materially limits post-exploitation options
- Modern EDR often catches suspicious browser child processes, injection attempts, or sandbox-break follow-on behavior
- A second vulnerability is typically needed for full workstation escape
Chain to something bigger
- Attacker has an additional browser or OS escape primitive, or a practical post-sandbox abuse path
- No evidence in sourced material of an active exploit chain using this CVE
- No KEV entry and extremely low EPSS both argue against immediate large-scale weaponization
The supporting signals.
| In-the-wild status | No authoritative evidence of active exploitation found in the sourced material as of 2026-06-05; not in CISA KEV. |
|---|---|
| PoC availability | No public PoC or exploit repo was found from authoritative sources. Chromium notes bug details may stay restricted until the fix has broadly shipped. |
| EPSS | 0.0008 from your intel block, which is extremely low. I could not confirm the exact percentile from a primary source in hand. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| Vendor vs. product-team severity | Your intel block says HIGH 8.8, but Google's release note labels CVE-2026-11077 as Medium and names it an out-of-bounds read in Dawn. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H assumes severe impact once exploited, but the decisive real-world limiter is UI:R + sandboxed renderer impact. |
| Affected versions | Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows/macOS. |
| Fixed versions | Desktop fixed in 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac). Android 149.0.7827.59 carries the corresponding desktop security fixes per Google's release notes. |
| Exposure/scanning reality | This is a client-side browser bug, so Shodan/Censys/FOFA-style internet census is largely irrelevant. Exposure is measured by endpoint inventory and browser version drift, not open ports. |
| Disclosure / reporter | Published in the Chrome stable release on 2026-06-02 and in your intel block as disclosed 2026-06-04; Google attributes the report to Anonymous on 2026-04-06. |
noisgate verdict.
The single biggest downward driver is that the available impact stays inside Chrome's sandbox and still requires a user to load hostile content. That makes this a useful exploit-chain component, not an immediate fleet-wide host takeover condition.
Why this verdict
- UI:R cuts the baseline down immediately — this needs a victim to browse to attacker content, so it is not equivalent to an unauthenticated remote service exploit.
- Sandbox-only impact is the main limiter — even if exploitation succeeds, the public description still lands the attacker inside the browser sandbox, which sharply reduces blast radius versus workstation compromise.
- Dawn/WebGPU reach is narrower than 'all Chrome traffic' implies — the vulnerable code lives in a graphics stack path whose practical reach varies by platform, GPU support, and enterprise endpoint profile.
- Threat intel is cold — no KEV, no sourced active exploitation, and EPSS at 0.0008 all push urgency down from the vendor-style HIGH baseline.
- Google itself called this specific bug Medium — that does not make it harmless, but it is a strong signal that the internal bug quality and exploitability did not justify a top-tier response.
Why not higher?
A HIGH or CRITICAL rating would need at least one major amplifier: active exploitation, a public reliable exploit, a sandbox escape, or no-user-interaction reach. None of those are present in the sourced material. The strongest available descriptions keep the attacker in the renderer sandbox and require page load by a user.
Why not lower?
This is still a browser memory-safety flaw in a massively deployed client application, so ignoring it would be sloppy. Even sandboxed browser code execution or memory disclosure can be chained, and Chrome is one of the few pieces of software your entire workforce touches every day.
What to do — in priority order.
- Verify Chrome auto-update health — Make sure endpoints are actually moving to the fixed build; for a MEDIUM verdict there is no mitigation SLA, so do this in the next normal browser operations cycle and remediate within the 365-day window.
- Disable or constrain WebGPU where business allows — If a subset of endpoints does not need advanced browser GPU features, reduce exposure by policy or hardened browser configuration. Treat this as an optional temporary risk reduction during the standard change cycle; there is no mitigation SLA for MEDIUM.
- Watch for renderer crash spikes — Repeated Chrome renderer/GPU-process crashes after web browsing are often your only early clue for failed exploitation attempts. Add this to normal telemetry review rather than emergency response unless you see corroborating intel.
- Prioritize high-risk user groups first — Even with a MEDIUM verdict, browsers used by executives, developers, finance staff, and high-risk web researchers deserve earlier patch rings because they see more hostile content. Roll those rings first in the normal patch cycle.
- Perimeter scanning doesn't help much, because this is not an internet-exposed service vulnerability.
- MFA does not stop exploitation of a browser memory bug; it only limits some downstream account abuse.
- Generic email filtering is incomplete protection because any web content source capable of delivering attacker HTML can trigger the browser path.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management agent. Invoke it as python3 check_cve_2026_11077.py for auto-discovery, or python3 check_cve_2026_11077.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; no admin rights are required, but local file-system access to the browser binary is needed.
#!/usr/bin/env python3
# check_cve_2026_11077.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIX_LINUX = (149, 0, 7827, 53)
FIX_WINMAC = (149, 0, 7827, 54)
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 version_lt(a, b):
return 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 p.returncode, out.strip()
except Exception:
return None, ''
def candidate_paths_from_arg():
if '--path' in sys.argv:
i = sys.argv.index('--path')
if i + 1 < len(sys.argv):
return [sys.argv[i + 1]]
return []
def find_candidates():
system = platform.system().lower()
cands = []
cands.extend(candidate_paths_from_arg())
if system == 'windows':
envs = [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]
rels = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe'
]
for base in envs:
if base:
for rel in rels:
cands.append(os.path.join(base, rel))
elif system == 'darwin':
cands.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
'/Applications/Chromium.app/Contents/MacOS/Chromium'
])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
p = shutil.which(name)
if p:
cands.append(p)
cands.extend([
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser'
])
seen = set()
uniq = []
for c in cands:
if c and c not in seen:
seen.add(c)
uniq.append(c)
return uniq
def get_version(path):
if not os.path.exists(path):
return None, None
rc, out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return ver, out
return None, out
def main():
system = platform.system().lower()
fix = FIX_WINMAC if system in ('windows', 'darwin') else FIX_LINUX
candidates = find_candidates()
found = []
for path in candidates:
ver, raw = get_version(path)
if ver:
found.append((path, ver, raw))
if not found:
print('UNKNOWN - Chrome/Chromium binary not found or version unreadable')
sys.exit(2)
# Evaluate the newest discovered version.
found.sort(key=lambda x: x[1], reverse=True)
path, ver, raw = found[0]
# Treat Chromium family versions conservatively as UNKNOWN unless clearly Google Chrome.
# The CVE is in Chromium code, but patch availability and branding differ by downstream builds.
is_chrome = 'chrome' in os.path.basename(path).lower() or 'Google Chrome' in raw
if not is_chrome:
print(f'UNKNOWN - Found Chromium-family browser at {path} version {".".join(map(str, ver))}; downstream patch status must be verified separately')
sys.exit(2)
if version_lt(ver, fix):
print(f'VULNERABLE - {path} version {".".join(map(str, ver))} is below fixed version {".".join(map(str, fix))}')
sys.exit(1)
else:
print(f'PATCHED - {path} version {".".join(map(str, ver))} meets or exceeds fixed version {".".join(map(str, fix))}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
- Chrome for Testing availability (shows stable 149.0.7827.53)
- Chrome Enterprise browser release notes / targeted stable dates
- FIRST EPSS API documentation
- CISA Known Exploited Vulnerabilities Catalog
- Chrome Enterprise policy - EnableUnsafeSwiftShader
- Quanteta CVE tracker entry list including CVE-2026-11077 metadata
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.