CVE-2026-25160: 
NixOS vulnerability analysis and mitigation

CVE-2026-25160 is an improper certificate validation vulnerability in Alist, a multi-storage file list program built on Gin and Solidjs. The application hardcodes TlsInsecureSkipVerify: true as the default configuration, disabling TLS certificate verification for all outgoing storage driver communications and exposing the system to Man-in-the-Middle (MitM) attacks. All Alist deployments running versions prior to 3.57.0 are affected. The vulnerability was discovered by the XlabAI Team of Tencent Xuanwu Lab using their Atuin automated vulnerability discovery engine, disclosed and patched on February 4, 2026. It carries a CVSS v3.1 base score of 9.1 (Critical) per the GitHub Advisory, though NVD records a score of 7.4 (High) (Github Advisory, Feedly).

The root cause is CWE-295 (Improper Certificate Validation): the DefaultConfig() function in internal/conf/config.go sets TlsInsecureSkipVerify: true, which propagates to all storage driver HTTP transports via tls.Config{InsecureSkipVerify: true}, including WebDAV and LDAP login connections (Github Advisory). Because certificate validation is globally skipped, an attacker positioned on the network path between the Alist server and its storage backends can present any self-signed or fraudulent TLS certificate and the server will accept it without warning. Exploitation requires network-level access to intercept traffic — achievable via ARP spoofing, rogue Wi-Fi access points, DNS hijacking, or compromised network equipment — with no authentication or user interaction required (Github Advisory, Patch Commit). A public PoC demonstrates the attack by redirecting storage provider traffic (e.g., www.weiyun.com) to a malicious Apache HTTPS server and capturing authentication cookies from Alist's outbound requests.

Successful exploitation allows an attacker to fully decrypt, intercept, and manipulate all data transmitted between the Alist server and its configured storage backends, including authentication cookies and credentials for third-party storage providers. Both confidentiality and integrity are severely compromised — attackers can steal sensitive files, exfiltrate authentication tokens for lateral movement to connected storage services, and inject malicious data into storage responses. Availability is not directly impacted, but credential theft could enable persistent unauthorized access to all storage accounts linked to the Alist instance (Github Advisory).

A public proof-of-concept exploit is available in the GitHub security advisory, demonstrating cookie theft via DNS hijacking and a rogue TLS server (Github Advisory). There is no current evidence of in-the-wild exploitation or threat actor attribution. The EPSS score is approximately 0.014% (2nd percentile), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires network adjacency or the ability to intercept traffic (e.g., via ARP spoofing or DNS hijacking), raising the practical attack complexity despite the low CVSS attack complexity rating.

1. Reconnaissance: Identify Alist instances (versions < 3.57.0) exposed on the network, particularly those configured with cloud storage backends (e.g., Weiyun, WebDAV, OneDrive).
2. Network Positioning: Gain a man-in-the-middle position on the network path between the Alist server and its storage backends using ARP spoofing (arpspoof), a rogue Wi-Fi access point, or DNS hijacking (e.g., modifying /etc/hosts or poisoning a DNS resolver).
3. Set Up Rogue TLS Server: Deploy a malicious HTTPS server with a self-signed certificate using Apache with mod_ssl or a similar tool. Configure it to log all incoming request headers, including cookies:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt
docker run -dit --name my-https-server httpd-ssl

4. Redirect Storage Traffic: Redirect the target storage provider's domain (e.g., www.weiyun.com) to the attacker's server IP via DNS manipulation or hosts file modification.
5. Intercept Credentials: When Alist initiates a storage operation, it connects to the attacker's server without validating the certificate. The rogue server logs all request headers, capturing authentication cookies and credentials:

Cookie: WhatEverSecret=<stolen_token>

6. Exploit Captured Credentials: Use the stolen authentication cookies or tokens to access the victim's storage accounts directly, exfiltrate data, or inject malicious content into storage responses (Github Advisory, Patch Commit).

• Network: Unexpected TLS connections from the Alist server to unfamiliar IP addresses on port 443 that resolve to known storage provider domains; ARP spoofing activity on the local network segment hosting the Alist server; anomalous DNS responses for storage provider domains (e.g., www.weiyun.com, WebDAV endpoints) resolving to unexpected IPs.
• Logs: Alist startup logs (prior to v3.57.0) lacking any TLS warning messages — post-patch versions emit SECURITY WARNING: TLS certificate verification is disabled if the insecure setting remains enabled; storage driver connection errors or unexpected HTTP 404 responses from storage backends.
• File System: Presence of modified /etc/hosts entries on the Alist host redirecting storage provider domains to non-canonical IPs (if the attacker has host-level access).
• Application Behavior: Authentication failures or unexpected session invalidations on linked storage accounts (Weiyun, OneDrive, WebDAV) that may indicate credential theft and reuse by an attacker (Github Advisory).

Upgrade Alist to version 3.57.0 or later, which changes the TlsInsecureSkipVerify default from true to false in internal/conf/config.go and also fixes the LDAP TLS connection in server/handles/ldap_login.go (Patch Commit, Github Advisory). As an interim workaround for deployments that cannot immediately upgrade, manually set TlsInsecureSkipVerify: false in the Alist configuration file and restart the service. Additionally, implement network segmentation to restrict access between the Alist server and its storage backends, and monitor for ARP spoofing or DNS anomalies on the network segment. After upgrading, verify that the startup logs do not emit the TLS insecure warning, which would indicate the setting was explicitly re-enabled.

The vulnerability was discovered by the XlabAI Team of Tencent Xuanwu Lab using their Atuin automated vulnerability discovery engine, and credited researchers can be contacted at xlabai@tencent.com (Github Advisory). The CISA vulnerability bulletin for the week of February 2, 2026 included CVE-2026-25160 in its summary. Coverage appeared on The Hacker Wire and was tracked by INCIBE-CERT and the GitLab advisory database shortly after disclosure.