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

Insufficient validation of untrusted input in IndexedDB in Google Chrome prior to 149

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

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.

"This is a browser booby trap, not a fleet-fire: user interaction, high complexity, and no exploitation evidence keep it low."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a malicious page

The attacker needs the user to load attacker-controlled web content, typically via phishing, malvertising, or a compromised site. The practical weaponized tool here is just 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.
Conditions required:
  • Unauthenticated remote attacker can host or inject web content
  • Target user must browse to attacker-controlled content
  • Affected Chrome version is still deployed
Where this breaks in practice:
  • 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
Detection/coverage: Network scanners will not see this; detection is mainly via browser-version inventory, URL filtering telemetry, and web proxy logs.
STEP 02

Trigger malformed IndexedDB handling

The page must drive a specific IndexedDB code path with inputs that hit the validation weakness. With public bug details still restricted, that usually means attacker research or rediscovery rather than copy-paste exploitation. Weaponized tool: IndexedDB API abuse in JavaScript, with the exploit logic embedded in the page.
Conditions required:
  • Victim browser exposes the vulnerable IndexedDB behavior
  • Attacker can reliably reproduce the bug across channel/build variants
Where this breaks in practice:
  • Vendor CVSS marks this AC:H, which usually means brittle timing, state, or crafted sequencing requirements
  • Lack of public PoC materially slows mass weaponization
Detection/coverage: EDR generally won't flag the bug itself; browser crash/console telemetry and suspicious repeated IndexedDB operations may offer weak hunting signals.
STEP 03

Land limited integrity impact

The published impact is *integrity only* (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.
Conditions required:
  • Bug must produce a controllable integrity effect after trigger
  • Victim remains in the affected browsing session/context
Where this breaks in practice:
  • 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
Detection/coverage: Version-based vulnerability assessment is strong; exploit-attempt detection is weak unless paired with web telemetry and user-reported browser anomalies.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found, and *CISA KEV does not list this CVE*.
Proof-of-concept availabilityNo credible public PoC or GitHub exploit surfaced in targeted searches. Chromium bug details remain restricted, which is normal early in Chrome disclosures.
EPSS0.00027 from the user-supplied intel — extremely low predicted near-term exploitation probability.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog.
CVSS vectorCVSS: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 versionsDesktop 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 versionsPatch 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 dataThis 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 datePublicly 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*.
ReporterGoogle's Chrome release notes attribute this issue to *Google* and list the internal issue reference 497660733.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.8/10)

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.

HIGH Affected/fixed version boundaries from Google and Canadian Cyber Centre advisories
MEDIUM Real-world exploitability assessment given restricted Chromium bug details
HIGH No KEV listing and no public exploitation evidence at time of review

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:H means 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. Inventory lagging versions — Query EDR/UEM/package telemetry for Chrome versions below 149.0.7827.53/54 and 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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning: do not yank people into an emergency browser patch campaign for this one. Validate that Chrome auto-update is healthy, identify the small tail still below 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

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chrome Releases 2026 archive showing CVE-2026-11246 entry
  3. Canadian Centre for Cyber Security AV26-544
  4. Chromium Security overview
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. FIRST EPSS data and statistics
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.