← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-2322 · CWE-451 · Disclosed 2026-02-11

Inappropriate implementation in File input in Google Chrome prior to 145

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

This is a fake badge at the lobby desk, not a master key to the building

CVE-2026-2322 is a *UI spoofing* bug in Chrome's file input handling. A malicious page can make browser UI around file selection look misleading, but only on Chrome versions before 145.0.7632.45 and only if the victim is driven into specific UI gestures on the crafted page. Upstream Chrome fixed it in the February 10, 2026 stable release; downstream Chromium packages show distro-specific fixed builds such as 145.0.7632.75-1~deb12u1 on Debian 12.

Google's own description tags this as Chromium security severity: Low, while CISA ADP scored it 5.4 / Medium. In enterprise reality, Google's framing is closer: this is not code execution, not sandbox escape, not data exfil by itself, and not an edge-service bug. The real risk is that it can *improve a phishing or social-engineering flow* on a massively deployed browser, which keeps it above IGNORE but below anything that should displace RCEs, auth bypasses, or KEV-listed browser bugs.

"This is phishing glue, not a beachhead: user-gesture-heavy UI spoofing in a client app with no exploit signal."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Stage a lure page with custom file input behavior

The attacker hosts a crafted HTML/JavaScript page that abuses Chrome's file input UI behavior to create a misleading interaction. There is no public exploit framework tied to this CVE in the sources reviewed; assume a bespoke phishing page rather than commodity tooling.
Conditions required:
  • Attacker can get a user to open a malicious webpage
  • Target is running Chrome earlier than 145.0.7632.45
Where this breaks in practice:
  • This is a client-side browser flaw, so there is no direct Internet-facing service to mass-scan and auto-exploit
  • Browser auto-update materially shrinks the vulnerable population over time
Detection/coverage: Version-based scanners can identify outdated Chrome/Chromium. They generally will not detect a live exploit attempt unless URL filtering or browser telemetry catches the lure page.
STEP 02

Drive the victim into the required gestures

Exploitation requires *user interaction* beyond just page render. The victim has to perform the specific clicks or dialog interactions that let the spoofed file-input flow become convincing.
Conditions required:
  • Victim interacts with the malicious page
  • The social-engineering pretext is believable enough to trigger the right gestures
Where this breaks in practice:
  • User interaction is mandatory and non-trivial
  • Modern secure browsing controls, email gateways, and URL filtering can break delivery before the user ever sees the lure
Detection/coverage: No reliable network signature for the CVE itself. Detection is mostly indirect: phishing telemetry, browser protection events, or web proxy logs.
STEP 03

Spoof the file-selection experience

If the interaction chain succeeds, the attacker can misrepresent critical UI around the file-input workflow. That can trick a user into believing they are performing one action while actually performing another, or into trusting a page they should distrust.
Conditions required:
  • Chrome UI state reaches the vulnerable code path
  • The user cannot distinguish the spoof from legitimate browser behavior
Where this breaks in practice:
  • Impact is limited to UI deception, not arbitrary code execution
  • Security-aware users, hardened browsers, or site isolation policies do not directly fix the bug but can reduce successful follow-on abuse
Detection/coverage: EDR usually sees only normal browser activity. SOC visibility depends on downstream abuse, not on the spoof itself.
STEP 04

Convert deception into a second-stage action

The practical attacker goal is follow-on fraud: convince the user to upload a sensitive file, trust a malicious prompt, or proceed deeper into a phishing chain. The CVE is therefore an *amplifier* for credential theft or file disclosure campaigns, not a standalone compromise primitive.
Conditions required:
  • Attacker has a second-stage objective such as theft, deception, or malicious file handling
  • Victim follows through after the spoofed interaction
Where this breaks in practice:
  • The blast radius is limited to users who both visit the lure and act on it
  • DLP, CASB, attachment controls, and MFA can still blunt the downstream objective
Detection/coverage: You may only see this in hindsight via suspicious uploads, SaaS audit logs, or phishing reports. The CVE itself has poor standalone exploit telemetry.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the reviewed primary sources. CISA KEV does not list CVE-2026-2322, and OpenCVE shows CISA SSVC options of Exploitation: none and Automatable: no.
Proof-of-concept availabilityNo public PoC located in the sources reviewed. The referenced Chromium issue is permission-restricted, which is typical while patches propagate, so absence of a public PoC is an informed observation rather than proof no private exploit exists.
EPSS0.00025 from your intel block, which is effectively de minimis. Snyk's package view also shows a very low EPSS neighborhood (0.03%, 7th percentile) for the Debian-tracked package view, reinforcing the low exploit-likelihood picture.
KEV statusNot listed in the CISA KEV catalog. No KEV-added date applies.
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L means remote reachability with required user interaction, no privileges, and only low integrity/availability impact. That is already a big tell: this is *deception* and nuisance potential, not a clean system-compromise primitive.
Affected versionsUpstream Chrome: all versions before 145.0.7632.45. NVD also models the affected product as google:chrome below that version across Windows, macOS, and Linux.
Fixed versionsUpstream fix landed in Chrome 145.0.7632.45 on Linux and 145.0.7632.45/46 on Windows/macOS. Example distro backport: Debian 12 chromium fixed in 145.0.7632.75-1~deb12u1; Ubuntu marks current supported releases Not affected because of packaging/snap delivery.
Scanning and exposure dataShodan/Censys/FOFA/GreyNoise are poor fit here because this is a *client-side browser bug*, not an Internet-exposed service with a banner to fingerprint. In practice, exposure measurement comes from endpoint inventory and browser version telemetry, not edge scan counts.
Disclosure timelineChrome stable fix released 2026-02-10; CVE published 2026-02-11; NVD last modified 2026-02-13.
Reporter / research creditNot publicly named in the accessible sources reviewed for this specific CVE. The linked Chromium issue exists, but reporter details are not exposed without permissions.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.3/10)

The decisive factor is the attack chain friction: exploitation requires a user to visit a malicious page *and* perform specific gestures, and the resulting impact is UI spoofing rather than code execution or privilege gain. That makes this a social-engineering amplifier on a ubiquitous platform, not a true initial-access breakthrough by itself.

HIGH Affected upstream version boundary and fixed release
HIGH No KEV listing / no public exploitation signal in reviewed sources
MEDIUM No-public-PoC assessment, because the Chromium issue is access-restricted

Why this verdict

  • Requires deliberate user interaction: this is not zero-click and not drive-by in the strict sense; the victim must perform specific UI gestures.
  • Impact is narrow: the bug enables UI spoofing, not memory corruption, sandbox escape, or arbitrary code execution. That sharply limits blast radius per successful hit.
  • No active exploitation signal: not KEV-listed, EPSS is extremely low, and reviewed sources do not show public weaponization.
  • Client-side only: there is no Internet-facing service population to sweep and exploit at scale, so real-world attacker efficiency is much lower than the raw AV:N label suggests.
  • Still not IGNORE because Chrome is everywhere: a browser deception bug can materially help phishing and file-theft workflows across a large user base.

Why not higher?

If this were an RCE, sandbox escape, or a browser bug with confirmed exploitation, the ubiquity of Chrome would push it much higher. But the chain collapses under friction: user interaction is mandatory, the exploit outcome is deception rather than direct compromise, and there is no current evidence of operational attacker demand.

Why not lower?

Calling it IGNORE would understate the risk of *assistive phishing* on a massively deployed browser. Even low-grade UI spoofing in a trusted endpoint application can improve success rates for credential theft or sensitive-file lures, so it still belongs in normal browser hygiene and version compliance.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update health — Verify Chrome enterprise update policies, relaunch behavior, and version drift reporting so vulnerable clients naturally age out. For a LOW verdict there is no SLA (treat as backlog hygiene), so do this in the next routine endpoint compliance cycle rather than as emergency work.
  2. Tighten phishing and URL filtering — Because the exploit starts with delivery to a crafted page, keep Safe Browsing, secure web gateway filtering, and email URL detonation tuned to break the lure chain before user interaction. Again, no SLA (treat as backlog hygiene) applies here; fold it into standing anti-phish hardening.
  3. Monitor browser version inventory — Use EDR, MDM, SCCM/Intune, or package inventory to identify endpoints below 145.0.7632.45 or distro-equivalent fixed versions. For LOW, there is no mitigation SLA; use this to clean up laggards during the normal browser maintenance wave.
  4. Harden follow-on abuse paths — Use DLP, SaaS upload restrictions, and MFA to reduce damage if a spoofed file-selection flow is used inside a phishing sequence. This matters because the CVE's practical harm comes from second-stage deception, not from the browser flaw alone.
What doesn't work
  • Perimeter IPS signatures alone: there is no stable, high-fidelity network pattern for a generic malicious HTML page abusing a browser UI quirk.
  • EDR alone: endpoint agents usually see normal browser execution, not a distinct memory-corruption or exploit chain worth alerting on.
  • WAF rules: this is a client-side browser issue, so a WAF only helps if it happens to block the malicious site upstream; it does not neutralize the vulnerable browser logic.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software inventory/remote execution platform. Invoke it as python3 check_chrome_cve_2026_2322.py with standard user rights; admin is not required unless your fleet tooling blocks access to install paths or registry hives.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_2322.py
# Detect Chrome version exposure for CVE-2026-2322.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

THRESHOLD = (145, 0, 7632, 45)


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 cmp_version(a, b):
    return (a > b) - (a < b)


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 windows_version():
    candidates = [
        ["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"],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v, 'registry'

    exe_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 path in exe_paths:
        if path and os.path.exists(path):
            out = run_cmd([path, "--version"])
            v = parse_version(out)
            if v:
                return v, path
    return None, None


def mac_version():
    path = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
    if os.path.exists(path):
        out = run_cmd([path, "--version"])
        v = parse_version(out)
        if v:
            return v, path
    return None, None


def linux_version():
    cmds = [
        ["google-chrome", "--version"],
        ["google-chrome-stable", "--version"],
        ["chromium", "--version"],
        ["chromium-browser", "--version"],
    ]
    for cmd in cmds:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v, ' '.join(cmd)
    return None, None


def main():
    system = platform.system().lower()
    if 'windows' in system:
        version, source = windows_version()
    elif 'darwin' in system:
        version, source = mac_version()
    elif 'linux' in system:
        version, source = linux_version()
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

    if not version:
        print('UNKNOWN: Chrome/Chromium version not found')
        sys.exit(2)

    version_str = '.'.join(map(str, version))

    # Note: distro Chromium builds can carry backported fixes under different point versions.
    # For upstream Google Chrome, versions >= 145.0.7632.45 are patched for CVE-2026-2322.
    if cmp_version(version, THRESHOLD) >= 0:
        print(f'PATCHED: detected version {version_str} from {source}')
        sys.exit(0)
    else:
        print(f'VULNERABLE: detected version {version_str} from {source}')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning: do not let this jump the queue ahead of browser RCEs, edge bugs, or anything with KEV/exploitation evidence. Validate that Chrome auto-update is healthy, identify endpoints still below 145.0.7632.45 (or distro-equivalent fixed builds), and let your normal browser maintenance wave close the gap; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond treating this as backlog hygiene, so document the rationale and clear it in the next routine browser release cycle rather than burning emergency patch capacity.

Sources

  1. NVD entry for CVE-2026-2322
  2. Chrome stable desktop release 145.0.7632.45
  3. Chromium issue tracker reference
  4. OpenCVE record with CISA ADP enrichment
  5. Ubuntu CVE page
  6. Snyk Debian 12 chromium fixed version view
  7. Tenable plugin for Chrome < 145.0.7632.45
  8. CISA Known Exploited Vulnerabilities catalog
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.