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

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

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

This is a bad lock on an interior office door, not an unlocked front entrance

CVE-2026-11286 is an input-validation flaw in Chrome's Wallet component affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. Based on the supplied description and the surrounding Chrome advisory patterns for this release, the meaningful attack path is not direct internet-to-host compromise: the attacker first needs a renderer-process foothold and then abuses Wallet handling to tamper with browser behavior, with impact closer to *integrity manipulation* than code execution.

Reality is lower than the generic CVSS framing suggests. The decisive friction is the prerequisite: renderer compromise first means this bug is a second-stage helper inside an already-successful browser exploit chain, and there is no evidence here of KEV listing, in-the-wild exploitation, or public weaponized PoC. Chrome's own June 2, 2026 release notes classify this one as Low, which fits enterprise patch priority better than the user-provided 4.3 baseline.

"This is a post-compromise Chrome bug, not an initial-access fire drill."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land code in the renderer first

The attacker needs a separate browser bug or exploit chain to compromise a Chrome renderer process. That means a malicious page, extension, or content path must already cross the normal browser boundary before CVE-2026-11286 matters. *Weaponized tool:* custom renderer exploit chain, not publicly documented for this CVE.
Conditions required:
  • Target is running vulnerable Chrome before 149.0.7827.53
  • Attacker can get the user to load attacker-controlled content
  • A separate renderer-compromise bug is available and successful
Where this breaks in practice:
  • This is not a standalone remote exploit
  • Modern Chrome exploit chains are expensive and rare compared with commodity phishing
  • Browser sandboxing, site isolation, exploit mitigations, and rapid auto-update all work against this step
Detection/coverage: Standard vuln scanners will usually only see version exposure, not whether a renderer exploit exists. EDR/browser telemetry may catch the precursor exploit, but there is no signature-rich standalone indicator for CVE-2026-11286 itself.
STEP 02

Drive malformed input into Wallet

With renderer control, the attacker feeds crafted untrusted input into the Wallet component and attempts to push it into an unsafe state. The published metadata points to input validation failure rather than memory corruption, so the likely abuse is state manipulation, spoofing, or policy-adjacent integrity impact instead of reliable host compromise. *Weaponized tool:* crafted HTML / browser interaction sequence as described in Chrome advisories for adjacent bugs.
Conditions required:
  • Renderer process is already compromised
  • Wallet-related code path is reachable in the victim's browsing session
Where this breaks in practice:
  • Wallet is a narrower feature surface than core HTML/JS rendering
  • Enterprises with limited wallet/payment feature use reduce reachable population
  • Impact appears limited to low-integrity browser-side effects
Detection/coverage: Little direct scanner coverage beyond version checks. Browser debug logs and crash telemetry may help during focused hunting, but broad network detection is weak.
STEP 03

Convert browser-side tampering into user harm

The attacker still has to turn the Wallet-side flaw into something useful: misleading UI, transaction manipulation, or abuse of trust in payment flows. That usually implies user interaction or very specific browsing context, which sharply limits blast radius in managed enterprise fleets. *Weaponized tool:* social-engineering or transaction-lure workflow layered on top of the browser foothold.
Conditions required:
  • Victim uses the relevant Wallet flow
  • Attacker can align timing with a wallet or payment interaction
  • User follows through on the manipulated action
Where this breaks in practice:
  • Many enterprise users never touch browser wallet functions
  • Managed browser policies can restrict payments, sync, and extensions
  • MFA, payment controls, and user friction reduce successful abuse
Detection/coverage: Detection shifts from vuln management to fraud monitoring and browser policy telemetry. Internet scanners like Shodan/Censys are poor visibility tools because this is endpoint software, not an exposed service.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence found of active exploitation specific to CVE-2026-11286, and it is not in CISA KEV.
Proof-of-concept availabilityNo public PoC repo or write-up found for this CVE. The Chromium issue exists at issues.chromium.org but is access-restricted, which is common for fresh Chrome bugs.
EPSSUser-supplied EPSS is 0.00022, which is effectively floor-level exploit likelihood for broad internet activity.
KEV statusNot KEV-listed as of the CISA catalog checked today; no CISA due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N maps to *user interaction required* and only *low integrity* impact. That already caps urgency unless exploitation evidence shows otherwise.
Affected versionsGoogle's June 2, 2026 stable-channel advisory says Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS is affected.
Fixed versionsPatch level is Chrome 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS. openSUSE also lists this fix in its Chromium 149 update: patchinfo.
Scanning / exposure realityShodan/Censys/FOFA are poor signals here because Chrome is a client-side browser flaw, not an internet-listening service. Real exposure is endpoint population, and Chrome still held about 65.14% US desktop browser share in StatCounter's May 2026 data, so fleet prevalence is high even though internet discoverability is low.
Disclosure timelineThere is a date mismatch worth noting: the user supplied 2026-06-05, but Google's public stable-channel bulletin for the fixed build is dated June 2, 2026.
Reporter / sourceGoogle's advisory attributes this CVE to Google and lists the report date as 2026-04-13.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.7/10)

The single biggest severity reducer is that this bug only matters after a renderer compromise already exists, which makes it post-initial-access and sharply narrows the real attacker population. In a 10,000-host fleet, that means this CVE is not your front-door problem; it is a low-value link in a much harder browser exploit chain.

HIGH Attack-path friction is materially higher than a standalone remote browser bug
MEDIUM Exact exploit effect inside Wallet is partly inferred because the Chromium issue is not public

Why this verdict

  • Major downward pressure: requires prior compromise. A renderer foothold implies the attacker has already beaten Chrome's primary content-execution boundary with a separate bug or chain.
  • Reachability is narrow. This sits in Wallet, not a ubiquitous parser like V8, Image, or PDFium, so only a subset of browsing sessions ever exercises the interesting code path.
  • No field evidence. No KEV listing, no public PoC, and the supplied EPSS is near-zero, which is exactly what low-priority browser follow-on bugs tend to look like.

Why not higher?

There is no credible case for HIGH or CRITICAL without evidence that CVE-2026-11286 is independently exploitable from the web. The need for a prior renderer compromise compounds with likely user-context requirements around wallet/payment flows, cutting both attacker reach and operational blast radius.

Why not lower?

It is still a real security bug in a massively deployed browser, and Chrome's footprint means even low-probability edge cases can exist somewhere in a large estate. Also, Wallet-adjacent integrity flaws can amplify fraud or spoofing after compromise, so this should stay on the patch backlog rather than be ignored.

05 · Compensating Control

What to do — in priority order.

  1. Enforce evergreen browser updates — Make sure managed Chrome channels auto-update and that version drift is visible in your endpoint tooling. For a LOW verdict there is no mitigation deadline; treat this as backlog hygiene and close it in your normal browser maintenance cycle.
  2. Reduce renderer-to-wallet reach — Use enterprise browser policy to limit unneeded payment, wallet, and extension features where business use is low. This cuts reachable attack surface while the normal patch wave finishes; for LOW, there is no mitigation SLA, so do this as policy hardening rather than emergency response.
  3. Hunt for unmanaged Chrome variants — The practical risk is stale side-loaded Chrome/Chromium builds on developer and BYOD-adjacent systems, not your centrally managed stable channel. Fold detection into routine hygiene and remove or update stragglers during the normal backlog window.
What doesn't work
  • A perimeter firewall or WAF does not meaningfully help; this is a client-side browser flaw, not a server-side web app issue.
  • Relying on EDR alone is weak because EDR may catch the *precursor exploit chain* but usually will not tell you that this specific Wallet validation bug was reachable.
  • Internet exposure scans are misleading here; Shodan/Censys can tell you nothing useful about whether endpoints run vulnerable Chrome versions.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your RMM/EDR live-response shell. Invoke it as python3 verify_cve_2026_11286.py on Linux/macOS or py verify_cve_2026_11286.py on Windows; it needs only normal read access to common install paths and registry keys.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# verify_cve_2026_11286.py
# Checks local Google Chrome / Chromium version against fixed build for CVE-2026-11286.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def version_to_str(v):
    return '.'.join(str(x) for x in v)


def compare(v1, v2):
    return (v1 > v2) - (v1 < v2)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        if p.returncode == 0:
            return (p.stdout or p.stderr).strip()
    except Exception:
        pass
    return None


def find_windows_version():
    commands = [
        ['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
        ['reg', 'query', r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon', '/v', 'version'],
        ['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
        ['powershell', '-NoProfile', '-Command', r"(Get-ItemProperty 'HKLM:\Software\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
        ['powershell', '-NoProfile', '-Command', r"(Get-ItemProperty 'HKLM:\Software\WOW6432Node\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
        ['powershell', '-NoProfile', '-Command', r"(Get-ItemProperty 'HKCU:\Software\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
    ]
    for cmd in commands:
        out = run_cmd(cmd)
        v = parse_version(out or '')
        if v:
            return ('Google Chrome', v)

    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'),
        os.path.expandvars(r'%ProgramFiles%\Chromium\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Chromium\Application\chrome.exe'),
    ]
    for p in paths:
        if p and os.path.exists(p):
            out = run_cmd([p, '--version'])
            v = parse_version(out or '')
            if v:
                name = 'Chromium' if 'Chromium' in (out or '') else 'Google Chrome'
                return (name, v)
    return None


def find_macos_version():
    paths = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
    ]
    for p in paths:
        if os.path.exists(p):
            out = run_cmd([p, '--version'])
            v = parse_version(out or '')
            if v:
                name = 'Chromium' if 'Chromium' in (out or '') else 'Google Chrome'
                return (name, v)
    return None


def find_linux_version():
    commands = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium', '--version'],
        ['chromium-browser', '--version'],
    ]
    for cmd in commands:
        out = run_cmd(cmd)
        v = parse_version(out or '')
        if v:
            name = 'Chromium' if 'Chromium' in (out or '') else 'Google Chrome'
            return (name, v)
    return None


def main():
    system = platform.system().lower()
    result = None

    if 'windows' in system:
        result = find_windows_version()
    elif 'darwin' in system:
        result = find_macos_version()
    else:
        result = find_linux_version()

    if not result:
        print('UNKNOWN: Chrome/Chromium version could not be determined on this host')
        sys.exit(2)

    name, version = result
    if compare(version, FIXED) < 0:
        print(f'VULNERABLE: {name} {version_to_str(version)} < fixed {version_to_str(FIXED)}')
        sys.exit(1)
    else:
        print(f'PATCHED: {name} {version_to_str(version)} >= fixed {version_to_str(FIXED)}')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not burn emergency patch time on this one unless it is bundled into your normal Chrome update wave anyway. This is a LOW reassessment: there is no noisgate mitigation SLA and no noisgate remediation SLA for LOW findings, so treat CVE-2026-11286 as backlog hygiene, verify that auto-update is working across the fleet, and let your next routine browser maintenance ring absorb any remaining pre-149.0.7827.53 stragglers while you spend urgent effort on first-stage browser RCEs and KEV-listed flaws instead.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue tracker entry 502110170
  3. Chromium Security page
  4. openSUSE Chromium 149 patchinfo
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS data and stats
  7. StatCounter US desktop browser market share
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.