This is a side door inside a vault, not the front gate
CVE-2026-11255 is an input-validation flaw in Chrome's Storage Access API affecting Google Chrome versions prior to 149.0.7827.53 on desktop release trains. The Storage Access API governs when embedded cross-site content can regain access to unpartitioned third-party cookies and related state, so a bug here is about privacy and origin-boundary enforcement rather than classic memory corruption or direct RCE.
The vendor's HIGH 7.5 score overstates enterprise urgency if the user-supplied description is accurate that exploitation requires an attacker who has already compromised the renderer process. That prerequisite changes the problem from 'internet-scale unauthenticated browser bug' into a post-compromise chain step for cross-site data access. Chrome is everywhere, so you still patch it, but this is not the item that should jump ahead of KEV-listed initial-access bugs or stand-alone Chrome RCEs.
3 steps from start to impact.
Gain renderer foothold with a separate browser bug
- Victim runs Chrome below
149.0.7827.53 - Attacker has a distinct renderer-compromise primitive
- Victim visits attacker-controlled or attacker-influenced web content
- A separate renderer bug is required before this CVE matters
- Modern browser exploit mitigations, site isolation, and crash telemetry raise attacker cost
- Exploit chains that reliably reach renderer control are scarce compared with generic web attack kits
Abuse Storage Access API policy handling from the compromised renderer
requestStorageAccess() or related flows around requestStorageAccessFor()/permission state, aiming to cross origin boundaries that normally require explicit user-mediated allowance.- Target workflow involves embedded cross-site content or related website set behavior
- Relevant storage/cookie state exists and is valuable
- The compromised renderer can drive the vulnerable code path
- Not every browsing session touches Storage Access API paths
- Chrome normally applies prompts, cookie attribute rules, and per-site restrictions
- Many enterprises block or reduce third-party cookie utility, shrinking payoff
Read cross-site session material or sensitive state
fetch() or sendBeacon().- Accessible high-value unpartitioned cookies/state are present
- Same browser profile contains authenticated sessions worth stealing
- Network egress from the browser is not blocked by site controls
- Impact is primarily confidentiality, not direct OS compromise
- HttpOnly, origin scoping, app-layer token binding, and reauthentication can limit reusable loot
- Many sessions are short-lived or device-bound, reducing replay value
The supporting signals.
| In-the-wild status | No evidence found of active exploitation as of the supplied intel; not KEV-listed. |
|---|---|
| Proof-of-concept availability | No public PoC located in primary-source searches. That matters less than usual because the bigger hurdle is the separate renderer compromise prerequisite. |
| EPSS | 0.00037 from the user intel — effectively near floor exploit-likelihood modeling, which aligns with a chain-dependent browser issue. |
| KEV status | Not listed in CISA KEV based on the current catalog page. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N maps to confidentiality-heavy impact, but that vector does not reflect the user-supplied 'already compromised renderer' prerequisite; that omission is the main reason for the downgrade. |
| Affected versions | Google Chrome prior to 149.0.7827.53; official Chrome release pages show 149.0.7827.53/.54 as the fixed desktop train. |
| Fixed versions | Patch to Chrome 149.0.7827.53 or later on desktop; openSUSE also references Chromium 149.0.7827.53 as containing the security fixes, which is useful for downstream Linux package validation. |
| Exposure reality | This is a client-side browser flaw, not an internet-facing service. There is no meaningful Shodan/Censys/FOFA-style external exposure measurement; enterprise risk is driven by endpoint population and browsing habits, not exposed ports. |
| Disclosure date | 2026-06-05 per the supplied intel; Chrome early-stable 149.0.7827.53/.54 landed on 2026-05-29. |
| Researcher / reporting | Not clearly attributable from the primary sources reviewed. Treat reporting provenance as unknown from available public artifacts. |
noisgate verdict.
The decisive factor is the attacker-position requirement: if exploitation really needs an already-compromised renderer, this is not an initial-access bug but a chain-enabler after the attacker has already crossed a major barrier. Chrome's ubiquity keeps it out of LOW, but the reachable population for the full chain is dramatically narrower than the vendor CVSS suggests.
Why this verdict
- Start at vendor 7.5, then cut for prior compromise: requiring a renderer foothold means the attacker has already won an earlier exploit stage, which is major downward pressure on real-world severity.
- Client-side and non-scannable: this is not a perimeter service you can spray from the internet; exploitation requires user browsing context and compatible application state.
- Impact is mostly confidentiality expansion: the bug appears to widen access to protected cross-site storage/session data, but it is not direct OS code execution, privilege escalation, or broad availability impact.
Why not higher?
It is not HIGH because the exploit chain appears to depend on an earlier renderer compromise, which sharply reduces the number of attackers, victims, and sessions that can reach the vulnerable state. There is also no current KEV listing, no active exploitation evidence found, and no public stand-alone PoC pushing this into emergency territory.
Why not lower?
It is not LOW because Chrome is massively deployed and browser-chain bugs can materially increase the value of an existing foothold by exposing SSO or session material. Even without direct RCE, a confidentiality bypass in a common browser can matter on shared workstations, admin browsing profiles, and SaaS-heavy enterprise environments.
What to do — in priority order.
- Enforce browser auto-update compliance — Use endpoint management to verify Chrome is on
149.0.7827.53or later and close drift as part of normal browser hygiene. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice Chrome should be kept on current stable far sooner than that. - Reduce high-value browser profiles — Separate privileged admin activity from day-to-day browsing so a renderer foothold plus this bug has less session value to steal. Apply this during the normal remediation cycle; it lowers blast radius even if the patch has not yet landed everywhere.
- Harden cross-site session design — Favor short-lived tokens, device binding, and reauthentication on sensitive SaaS paths so stolen browser state is less reusable. This is compensating architecture work, not a substitute for updating Chrome.
- Monitor abnormal IdP and session reuse — Watch for impossible travel, token replay, and new-device session reuse in SSO telemetry because the practical business risk here is session/state theft. Keep this continuously enabled; it helps during and after the remediation window.
- A network perimeter scan doesn't help because this is not an exposed service vulnerability.
- A generic WAF won't meaningfully stop a browser-internal policy flaw once the victim is already rendering attacker-controlled content.
- Relying only on third-party cookie restrictions is not enough because the vulnerable component is specifically the mechanism meant to selectively re-enable storage access.
Crowdsourced verification payload.
Run this on the target endpoint itself, or push it through your RMM/EDR script runner. Invoke with python3 check_chrome_149.py on macOS/Linux or py check_chrome_149.py on Windows; no admin rights are required for standard install paths. The script reports VULNERABLE, PATCHED, or UNKNOWN based on the highest Google Chrome/Chromium version it can find versus 149.0.7827.53.
#!/usr/bin/env python3
# check_chrome_149.py
# Detects whether local Google Chrome / Chromium is below 149.0.7827.53
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
FIXED = (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 ver_to_str(v):
return '.'.join(str(x) for x in v) if v else 'UNKNOWN'
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=8)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def check_binary(path):
if not path or not os.path.exists(path):
return None
out = run_cmd([path, '--version'])
return parse_version(out)
def windows_candidates():
paths = []
envs = ['PROGRAMFILES', 'PROGRAMFILES(X86)', 'LOCALAPPDATA']
suffixes = [
r'Google\\Chrome\\Application\\chrome.exe',
r'Chromium\\Application\\chrome.exe',
]
for env in envs:
base = os.environ.get(env)
if base:
for s in suffixes:
paths.append(os.path.join(base, *s.split('\\')))
return paths
def mac_candidates():
return [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium'),
]
def linux_candidates():
names = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser'
]
paths = []
for name in names:
p = which(name)
if p:
paths.append(p)
paths.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
'/snap/bin/chromium',
])
return paths
def collect_versions():
system = platform.system().lower()
candidates = []
if 'windows' in system:
candidates = windows_candidates()
elif 'darwin' in system:
candidates = mac_candidates()
else:
candidates = linux_candidates()
found = []
seen = set()
for path in candidates:
if path in seen:
continue
seen.add(path)
v = check_binary(path)
if v:
found.append((path, v))
return found
def main():
found = collect_versions()
if not found:
print('UNKNOWN: Google Chrome / Chromium not found in standard locations')
sys.exit(2)
# Use the highest detected version if multiple builds are present.
highest_path, highest_ver = max(found, key=lambda x: x[1])
print(f'Detected: {highest_path} -> {ver_to_str(highest_ver)}')
print(f'Fixed threshold: {ver_to_str(FIXED)}')
if highest_ver >= FIXED:
print('PATCHED')
sys.exit(0)
else:
print('VULNERABLE')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53 or later under the noisgate remediation SLA for MEDIUM findings: no mitigation SLA — go straight to the 365-day remediation window. If you have high-value admin browsing profiles or kiosk/shared-user populations, patch those first inside your regular monthly browser cadence even though the formal noisgate mitigation SLA does not apply here.Sources
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases: Chrome Beta for Desktop Update (149.0.7827.53)
- openSUSE patchinfo: chromium security fixes in 149.0.7827.53
- MDN: Storage Access API overview
- Privacy Sandbox Help: How the Storage Access API works
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.