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.
4 steps from start to impact.
Stage a lure page with custom file input behavior
- Attacker can get a user to open a malicious webpage
- Target is running Chrome earlier than 145.0.7632.45
- 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
Drive the victim into the required gestures
- Victim interacts with the malicious page
- The social-engineering pretext is believable enough to trigger the right gestures
- 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
Spoof the file-selection experience
- Chrome UI state reaches the vulnerable code path
- The user cannot distinguish the spoof from legitimate browser behavior
- 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
Convert deception into a second-stage action
- Attacker has a second-stage objective such as theft, deception, or malicious file handling
- Victim follows through after the spoofed interaction
- 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
The supporting signals.
| In-the-wild status | No 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 availability | No 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. |
| EPSS | 0.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 status | Not listed in the CISA KEV catalog. No KEV-added date applies. |
| CVSS vector readout | CVSS: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 versions | Upstream 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 versions | Upstream 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 data | Shodan/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 timeline | Chrome stable fix released 2026-02-10; CVE published 2026-02-11; NVD last modified 2026-02-13. |
| Reporter / research credit | Not publicly named in the accessible sources reviewed for this specific CVE. The linked Chromium issue exists, but reporter details are not exposed without permissions. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- Monitor browser version inventory — Use EDR, MDM, SCCM/Intune, or package inventory to identify endpoints below
145.0.7632.45or distro-equivalent fixed versions. For LOW, there is no mitigation SLA; use this to clean up laggards during the normal browser maintenance wave. - 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.
- 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.
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.
#!/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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.