This is a bent filing cabinet drawer, not an open vault
CVE-2026-11246 is an *IndexedDB input-validation flaw* in Google Chrome affecting desktop releases *before* 149.0.7827.53 on Linux and *before* 149.0.7827.53/54 on Windows and macOS. Public detail is sparse because Chromium keeps many bug records restricted until broad patch uptake, but the available description points to a malicious web page abusing IndexedDB handling to cause an *integrity-side effect* rather than code execution. Based on the user-supplied CVSS and the component involved, this looks like a crafted-page bug that needs a victim to browse to attacker content and then mishandles browser-managed storage state.
The supplied MEDIUM/5.3 label is too generous for enterprise patch triage. Google itself grouped this CVE as *Low* in the Chrome 149 stable-channel advisory, and that better matches reality: no RCE, no sandbox escape, no evidence of in-the-wild use, no public weaponized PoC, high attack complexity, and a blast radius that is usually limited to the browsing context and local browser data for the fooled user. For a team managing 10,000 endpoints, this belongs in normal browser-update hygiene, not in the interruption queue.
3 steps from start to impact.
Deliver a malicious page
custom HTML/JavaScript using browser APIs; there is no sign of a turnkey exploit kit or public exploit module. Reference: Chrome 149 stable-channel security notes.- Unauthenticated remote attacker can host or inject web content
- Target user must browse to attacker-controlled content
- Affected Chrome version is still deployed
- Requires successful user interaction (
UI:R) - Enterprise web filtering, email security, and browser isolation can stop the lure before execution
- Modern Chrome fleets auto-update quickly, shrinking the reachable population
Trigger malformed IndexedDB handling
IndexedDB API abuse in JavaScript, with the exploit logic embedded in the page.- Victim browser exposes the vulnerable IndexedDB behavior
- Attacker can reliably reproduce the bug across channel/build variants
- Vendor CVSS marks this
AC:H, which usually means brittle timing, state, or crafted sequencing requirements - Lack of public PoC materially slows mass weaponization
Land limited integrity impact
I:H, C:N, A:N), so this is not the usual Chrome headline path to code execution. The likely end state is corruption or unauthorized manipulation of browser-managed storage/state within the victim's browsing context, not host takeover. Weaponized output is therefore a data/state manipulation primitive, not an endpoint-execution primitive.- Bug must produce a controllable integrity effect after trigger
- Victim remains in the affected browsing session/context
- No confidentiality or availability impact published
- No known pivot to OS-level compromise from the disclosed information
- Blast radius is usually one user profile/browser instance, not the enterprise
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found, and *CISA KEV does not list this CVE*. |
|---|---|
| Proof-of-concept availability | No credible public PoC or GitHub exploit surfaced in targeted searches. Chromium bug details remain restricted, which is normal early in Chrome disclosures. |
| EPSS | 0.00027 from the user-supplied intel — extremely low predicted near-term exploitation probability. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N — remote and unauthenticated on paper, but *high complexity* plus *user interaction* sharply reduce operational reach. |
| Affected versions | Desktop Chrome *prior to* 149.0.7827.53/54 on Windows/macOS and *prior to* 149.0.7827.53 on Linux, per Google's June 2, 2026 stable-channel release and Canada's follow-on advisory. |
| Fixed versions | Patch level is 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS. Chrome for Android 149.0.7827.59 inherits the corresponding desktop security fixes unless otherwise noted. |
| Scanning and exposure data | This is a *client-side browser flaw*, so Shodan/Censys/FOFA-style internet census data is mostly meaningless. Exposure should be measured from endpoint inventory and browser version telemetry, not external attack-surface scans. |
| Disclosure date | Publicly disclosed on 2026-06-05 per the supplied intel; Google's stable desktop fix shipped on *June 2, 2026* and Canada's advisory followed on *June 3, 2026*. |
| Reporter | Google's Chrome release notes attribute this issue to *Google* and list the internal issue reference 497660733. |
noisgate verdict.
The decisive factor is *compound friction*: this bug needs a user to load hostile content and then hit a high-complexity IndexedDB path for an impact that stops at integrity manipulation rather than code execution. In enterprise reality, that is a narrow, low-yield attack compared with the browser flaws that actually drive emergency patching.
Why this verdict
- User interaction is mandatory: the attacker still has to get a victim onto attacker-controlled web content, which means email gateway, SWG, browser isolation, and user behavior all get a chance to break the chain.
- Attack complexity is explicitly high:
AC:Hmeans this is not a spray-and-pray browser bug. That alone is downward pressure because brittle browser-state bugs do not scale cleanly across 10,000-host fleets. - Impact is limited to integrity, not takeover: no published confidentiality or availability impact, no evidence of code execution, and no sign of a sandbox escape or privilege boundary break.
- Population reach is narrower than CVSS suggests: Chrome auto-update and enterprise browser management rapidly collapse the vulnerable window, especially for stable-channel desktop releases.
- Threat intel is quiet: no KEV entry, no public PoC, and a very low EPSS score remove the main reasons to keep this in a higher bucket.
Why not higher?
A higher rating would require some amplifier that is missing here: public weaponization, active exploitation, a reliable drive-by path, or impact that crosses into RCE, sandbox escape, credential theft, or enterprise-wide compromise. We have none of those. This is a crafted-content browser bug with meaningful preconditions and limited published impact.
Why not lower?
It is still a real remotely triggerable client-side flaw in a massively deployed browser, and Chrome belongs on nearly every corporate endpoint. If a target is already on an old build and users browse untrusted content, there is still a viable path to user-level browser-state manipulation. That keeps it above IGNORE.
What to do — in priority order.
- Keep auto-update rings healthy — Verify Chrome stable-channel auto-update is functioning across managed endpoints and that version drift is visible in your endpoint inventory. For a LOW verdict there is no formal SLA; handle this as backlog hygiene and fold it into the next normal browser update cycle.
- Enforce web filtering — Reduce the chance that users ever load attacker-controlled pages by maintaining URL filtering, phishing protections, and safe-browsing policies. This breaks the only realistic initial access step and should already be standard control coverage.
- Use browser isolation for risky cohorts — Apply remote browser isolation or hardened browsing profiles for high-risk users and unmanaged browsing workflows. This is a good compensating control when patch latency exists, even though there is no mitigation SLA for a LOW verdict.
- Inventory lagging versions — Query EDR/UEM/package telemetry for Chrome versions below
149.0.7827.53/54and clean up long-tail exceptions. The real operational risk here is not exploit frenzy; it is unmanaged endpoints sitting outside your normal browser patch stream.
- A perimeter vulnerability scan will not help much; this is a client-side browser issue, not an internet-facing service with a detectable banner.
- MFA does nothing here because the attack path is a malicious page rendered in the browser, not an account-authentication event.
- Server-side WAF rules are unreliable as a primary defense because the exploit content can be hosted anywhere and may never transit your protected applications.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-inventory tooling. Invoke it with python3 check_chrome_cve_2026_11246.py (or py check_chrome_cve_2026_11246.py on Windows); no admin rights are required if the script can read Chrome version metadata from standard install paths.
#!/usr/bin/env python3
# Check Chrome patch status for CVE-2026-11246
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from pathlib import Path
def parse_version(s):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_ver(a, b):
return (a > b) - (a < b)
def get_windows_version():
try:
import winreg
except Exception:
winreg = None
# Registry first
if winreg:
keys = [
r'SOFTWARE\Google\Chrome\BLBeacon',
r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'
]
for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
for key in keys:
try:
with winreg.OpenKey(hive, key) as k:
value, _ = winreg.QueryValueEx(k, 'version')
v = parse_version(value)
if v:
return v, value, 'registry'
except Exception:
pass
# Executable fallback
paths = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
for p in paths:
if os.path.exists(p):
try:
out = subprocess.check_output([
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{p}').VersionInfo.ProductVersion"
], text=True, stderr=subprocess.DEVNULL).strip()
v = parse_version(out)
if v:
return v, out, p
except Exception:
pass
return None, None, None
def get_macos_version():
p = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(p):
try:
out = subprocess.check_output([
'/usr/bin/defaults', 'read',
'/Applications/Google Chrome.app/Contents/Info',
'CFBundleShortVersionString'
], text=True, stderr=subprocess.DEVNULL).strip()
v = parse_version(out)
if v:
return v, out, p
except Exception:
pass
return None, None, None
def get_linux_version():
cmds = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in cmds:
try:
out = subprocess.check_output(cmd, text=True, stderr=subprocess.DEVNULL).strip()
v = parse_version(out)
if v:
return v, out, ' '.join(cmd)
except Exception:
pass
paths = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium-browser',
'/usr/bin/chromium',
]
for p in paths:
if os.path.exists(p):
try:
out = subprocess.check_output([p, '--version'], text=True, stderr=subprocess.DEVNULL).strip()
v = parse_version(out)
if v:
return v, out, p
except Exception:
pass
return None, None, None
def main():
system = platform.system()
version = raw = source = None
if system == 'Windows':
version, raw, source = get_windows_version()
patched_min = (149, 0, 7827, 53) # Windows/Mac patched at 53/54
elif system == 'Darwin':
version, raw, source = get_macos_version()
patched_min = (149, 0, 7827, 53) # Windows/Mac patched at 53/54
elif system == 'Linux':
version, raw, source = get_linux_version()
patched_min = (149, 0, 7827, 53)
else:
print('UNKNOWN - unsupported OS')
sys.exit(2)
if not version:
print('UNKNOWN - Chrome version not found')
sys.exit(2)
if cmp_ver(version, patched_min) >= 0:
print(f'PATCHED - detected {raw} via {source}')
sys.exit(0)
else:
print(f'VULNERABLE - detected {raw} via {source}; needs >= {patched_min[0]}.{patched_min[1]}.{patched_min[2]}.{patched_min[3]}')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53/54, and roll those systems forward in the next normal endpoint/browser maintenance wave; for a LOW verdict there is no noisgate mitigation SLA and effectively no noisgate remediation SLA beyond treating it as backlog hygiene. If your estate has high-risk browsing populations, keep web filtering and browser isolation in place, but spend your urgent patching time on Chrome bugs with RCE, sandbox escape, KEV, or real exploitation evidence instead.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.