← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11255 · CWE-20 · Disclosed 2026-06-05

Insufficient validation of untrusted input in Storage Access API in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Treat this as a chain-enabler, not a stand-alone fire drill: widespread app, but post-renderer-compromise friction drags it down."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Gain renderer foothold with a separate browser bug

The attacker first needs code execution or equivalent control inside the Chrome renderer process using some other vulnerability or a same-process compromise primitive. CVE-2026-11255 is not the entry bug; it is the follow-on policy-bypass/data-access step once the attacker already lives inside the tab sandbox. Typical tooling here is a malicious HTML/JS exploit chain delivered by drive-by browsing or a hostile ad slot.
Conditions required:
  • Victim runs Chrome below 149.0.7827.53
  • Attacker has a distinct renderer-compromise primitive
  • Victim visits attacker-controlled or attacker-influenced web content
Where this breaks in practice:
  • 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
Detection/coverage: This step is usually outside normal vuln-scanner visibility. Detection comes from browser crash spikes, exploit protection telemetry, EDR child-process anomalies, and threat intel on active Chrome chains.
STEP 02

Abuse Storage Access API policy handling from the compromised renderer

With renderer control, the attacker manipulates Storage Access API flows to obtain or simulate access to unpartitioned third-party cookies/state that should remain gated by browser policy. The likely weaponized mechanism is crafted iframe content invoking requestStorageAccess() or related flows around requestStorageAccessFor()/permission state, aiming to cross origin boundaries that normally require explicit user-mediated allowance.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Very limited direct coverage. Browser logs and web app telemetry may show unusual storage-access permission grants or cross-site cookie behavior, but most endpoint scanners will miss actual abuse.
STEP 03

Read cross-site session material or sensitive state

If the bypass works, the attacker can pivot from 'code in one tab renderer' to reading data normally protected by cross-site storage partitioning. In practice this is about session cookies, SSO-adjacent state, or embedded service personalization data, then exfiltrating it via normal web requests such as fetch() or sendBeacon().
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: CASB, proxy, and IdP telemetry may catch unusual session reuse or anomalous token use. Version checks can identify exposure, but abuse confirmation is difficult after the fact.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence found of active exploitation as of the supplied intel; not KEV-listed.
Proof-of-concept availabilityNo public PoC located in primary-source searches. That matters less than usual because the bigger hurdle is the separate renderer compromise prerequisite.
EPSS0.00037 from the user intel — effectively near floor exploit-likelihood modeling, which aligns with a chain-dependent browser issue.
KEV statusNot listed in CISA KEV based on the current catalog page.
CVSS vectorCVSS: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 versionsGoogle Chrome prior to 149.0.7827.53; official Chrome release pages show 149.0.7827.53/.54 as the fixed desktop train.
Fixed versionsPatch 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 realityThis 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 date2026-06-05 per the supplied intel; Chrome early-stable 149.0.7827.53/.54 landed on 2026-05-29.
Researcher / reportingNot clearly attributable from the primary sources reviewed. Treat reporting provenance as unknown from available public artifacts.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.4/10)

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.

MEDIUM Severity downgrade driven by the user-supplied 'compromised renderer' prerequisite
HIGH Affected/fixed version boundary at `149.0.7827.53`
MEDIUM No active exploitation / no KEV / no public PoC found

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.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update compliance — Use endpoint management to verify Chrome is on 149.0.7827.53 or 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like an emergency browser zero-day unless new exploitation evidence appears. Put affected Chrome endpoints into your normal browser-update enforcement queue, validate fleet drift with the version check above, and remediate to 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

  1. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases: Chrome Beta for Desktop Update (149.0.7827.53)
  3. openSUSE patchinfo: chromium security fixes in 149.0.7827.53
  4. MDN: Storage Access API overview
  5. Privacy Sandbox Help: How the Storage Access API works
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS API documentation
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.