Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessPublish malicious extension or catalog entry
-
DeliveryVictim installs or adds extension
-
ExploitDownload command resolves hostname to internal IP
-
ExecutionSSRF reaches loopback/metadata endpoint
-
ImpactInternal response written to extension directory
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the victim to install or add an attacker-controlled extension or catalog entry (UI:P) whose download command specifies a hostname that DNS-resolves to a loopback (127.0.0.0/8), private (RFC1918), or cloud metadata (169.254.169.254) address; the vulnerable path is the extension download command handling in src-tauri/src/extensions/security.rs where validate_remote_url() checks the URL but not the resolved IP. Exploitation is LIMITED by: (1) the need for the user to trust/install a malicious extension or poisoned catalog entry - the app is not vulnerable to a purely unsolicited remote request; (2) confidentiality-only, Low-rated impact, since data is exfiltrated indirectly as files written to the extension directory rather than streamed back to the attacker; (3) affected versions are Sigma File Manager through 2.2.0 only. Value is highest when the app runs on a cloud instance exposing an instance-metadata endpoint. |
| Impact | This is a moderate, conditionally-exploitable SSRF (CWE-918) rather than a drop-everything priority. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N) scores 5.3 and is internally consistent with the description: network attack surface, no attacker authentication, but passive user interaction (UI:P) is required because the attack vehicle is a 'malicious extension or catalog entry' that a victim must add or trust. The real limiting factor is that initiative, not the network vector - an attacker cannot reach the vulnerable validate_remote_url() path without the user introducing an attacker-controlled extension/catalog entry. Impact is confidentiality-only and rated Low (VC:L) because the attacker reads internal/metadata responses indirectly via files written to the extension directory, with no integrity or availability effect and no confirmed scope change. No EPSS score, KEV listing, SSVC decision, or public POC was provided in the input, so exploitation probability cannot be quantified; the only exploitation signal is a VulnCheck advisory and a confirmed vendor patch, which indicate a credible, researcher-validated issue but not active exploitation. Net: a legitimate issue worth patching, especially in environments running in cloud instances where 169.254.169.254 metadata exposure matters, but the required malicious-extension precondition keeps real-world mass-exploitation risk low. |
| Exploit ScenarioDerived | An attacker publishes or seeds a malicious Sigma File Manager extension (or a poisoned catalog entry) whose download command references a hostname that resolves to a loopback, private-range, or cloud metadata IP such as 169.254.169.254. When a victim installs or processes that extension, the application's extension download logic calls validate_remote_url(), which never validates the resolved IP, so the request is sent to the internal target and the response is written into the extension directory where it can be read. No public exploit code is identified at time of analysis, though the flaw is documented in a VulnCheck advisory and the source (security.rs) is publicly referenced. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Server-side request forgery in Sigma File Manager through 2.2.0 allows a malicious extension or poisoned catalog entry to point extension download commands at loopback, RFC1918, or cloud metadata endpoints, with the fetched response materializing as a file inside the extension directory rather than being streamed back to the attacker. The Tauri/Rust backend's validate_remote_url() in src-tauri/src/extensions/security.rs inspects the URL string but never checks the IP addresses the hostname resolves to, so a name resolving to 127.0.0.1 or 169.254.169.254 passes validation. Exploitation is conditional on the user installing or adding the attacker-supplied extension (CVSS 3.1 AV:N/AC:L/PR:N/UI:R, C:L only); no public exploit code identified at time of analysis and the issue is not in CISA KEV. Risk is highest when the app runs on a cloud instance exposing an instance-metadata endpoint.
RemediationAI
Upgrade to a Sigma File Manager build that contains upstream commit 45cedf892f800c6b140b0e3cd6e55fdbcf2cf479 (https://github.com/aleksey-hoffman/sigma-file-manager/commit/45cedf892f800c6b140b0e3cd6e55fdbcf2cf479); the vendor reports a patch is available, but a tagged release number above 2.2.0 embedding the fix is not independently confirmed, so verify the shipped version against the commit before relying on it, and track issue #552 and the VulnCheck advisory for the release announcement. Where upgrading must wait, treat extension installation as a privileged action: restrict extension and catalog sources to a vetted allowlist, review catalog entries before import, and note that the client-side filter is absent so any name resolving internally still succeeds. Operationally, block outbound traffic from the desktop host to loopback, RFC1918, and 169.254.0.0/16 destinations at the host firewall or an egress proxy - this contains the SSRF but will also break any legitimate extension downloads served from internal mirrors or localhost dev servers. On cloud hosts, enforce IMDSv2 with a hop limit of 1 (or disable instance metadata entirely) so that even a successful request to 169.254.169.254 yields no usable credentials; side effect is that other legacy tooling relying on IMDSv1 stops working. Restricting the app's network namespace or running it in a sandbox without metadata-route access provides equivalent coverage with the trade-off of reduced download functionality.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Sigma File Manager is a desktop file manager built on Tauri, with its extension subsystem implemented in Rust under src-tauri/src/extensions/. Download flows for extension binaries, manifests, and GitHub-sourced text all funneled through a shared reqwest client built by build_http_client(), and URL validation was delegated to validate_remote_url() in security.rs. That function enforced scheme/host string policy but performed no DNS resolution, so any hostname whose A/AAAA records pointed at 127.0.0.0/8, RFC1918 space, link-local addresses, or the 169.254.169.254 metadata endpoint was accepted, and the request was made by the privileged desktop process. This is classic CWE-918; the response body was not returned to the extension but written to disk by filesystem.rs, which converts a would-be SSRF read primitive into an indirect file-based disclosure requiring the attacker to retrieve the artifact afterwards. The upstream fix (commit 45cedf8) adds a PublicOnlyResolver implementing reqwest::dns::Resolve so the connector can only reach addresses that were just checked, applies it via a new build_remote_http_client() for every extension-, manifest-, and registry-sourced URL, keeps the unfiltered client for fixed app-chosen hosts, and adds a custom redirect policy capping hops at 10, rejecting redirects to blocked targets, and bounding DNS resolution with a 10-second timeout.
Know when Sigma File Manager gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Attacker needs no authentication (PR:N) but the victim must install/add a malicious extension (UI:R); impact is confidentiality-only and partial (C:L) since responses leak via extension-directory files, no I/A effect.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Sigma File Manager through 2.2.0 contains a server-side request forgery vulnerability because validate_remote_url() in security.rs never checks resolved IP addresses for extension download commands. A malicious extension or catalog entry can use hostnames resolving to loopback, private, or cloud metadata addresses to read internal responses via files written to the extension directory.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
EUVD-2026-104315
GHSA-37hh-79v8-v8vr
NVD
CVE.org
EPSS
Exploit-DB