CVE-2026-25060: 
NixOS vulnerability analysis and mitigation

CVE-2026-25060 is an insecure TLS default configuration vulnerability in OpenList (formerly AList), a self-hosted file listing application. Prior to version 4.1.10, the TlsInsecureSkipVerify setting defaults to true in the DefaultConfig() function within internal/conf/config.go, disabling TLS certificate verification for all outgoing storage driver communications. This makes every default deployment susceptible to Man-in-the-Middle (MitM) attacks. The vulnerability was discovered by the XlabAI Team of Tencent Xuanwu Lab, published on January 31, 2026, and patched in version 4.1.10. It carries a CVSS v3.1 base score of 8.1 (High) (Github Advisory).

The root cause is classified as CWE-599 (Missing Validation of OpenSSL Certificate): the DefaultConfig() function in internal/conf/config.go hardcodes TlsInsecureSkipVerify: true, meaning all TLS connections made by storage drivers bypass certificate validation entirely. An attacker positioned on the network path (e.g., via ARP spoofing, rogue Wi-Fi access point, or compromised network equipment) can redirect storage driver traffic to an attacker-controlled TLS server. Because the OpenList server accepts any certificate without validation, it will silently establish an encrypted session with the malicious endpoint, exposing all transmitted data including authentication cookies and storage credentials. A proof-of-concept was included in the advisory, demonstrating DNS hijacking to redirect www.weiyun.com to a self-signed Apache HTTPS server, successfully capturing authentication cookies from the OpenList container (Github Advisory, OpenList Security Advisory).

Successful exploitation allows an attacker to fully decrypt, intercept, and manipulate all data transmitted during storage operations — including authentication cookies, credentials, and file contents — without triggering any security warnings on the OpenList server. The impact spans high confidentiality loss (credential and data theft), high integrity loss (manipulation of storage operations), and high availability impact. All OpenList deployments running versions prior to 4.1.10 with default configuration are affected, which encompasses the entire default install base (Github Advisory).

A proof-of-concept is publicly documented in the GitHub Security Advisory, demonstrating the attack via DNS hijacking and a self-signed TLS server to capture authentication cookies. No evidence of in-the-wild exploitation has been reported as of the time of disclosure. The EPSS score is approximately 0.008% (0.000080), indicating a low current probability of exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been identified (Github Advisory, Feedly).

1. Reconnaissance: Identify OpenList instances (default ports 5244/5245) on the target network using network scanning tools such as Nmap or Shodan. Confirm the version is prior to 4.1.10 to ensure TlsInsecureSkipVerify defaults to true.
2. Network Positioning: Gain a man-in-the-middle position on the network path between the OpenList server and its configured storage backends. This can be achieved via ARP spoofing (e.g., using arpspoof or ettercap), deploying a rogue Wi-Fi access point, or exploiting compromised network equipment.
3. DNS/Traffic Redirection: Redirect DNS resolution for storage provider domains (e.g., www.weiyun.com) to an attacker-controlled server. In a containerized environment, this can be simulated by modifying /etc/hosts inside the OpenList container.
4. Deploy Malicious TLS Server: Stand up a TLS-enabled HTTPS server with a self-signed certificate (e.g., using Apache httpd with mod_ssl and a self-generated RSA certificate via openssl req -x509). Configure it to log all incoming request headers, including cookies.
5. Trigger Storage Communication: Wait for or trigger the OpenList server to communicate with the storage backend (e.g., by adding or refreshing a storage driver such as Weiyun in the OpenList frontend). The OpenList server will connect to the attacker's server without validating the certificate.
6. Harvest Credentials: Inspect the attacker server's access logs to extract authentication cookies and other sensitive headers transmitted by OpenList, enabling impersonation of the victim to the legitimate storage provider (Github Advisory, OpenList Security Advisory).

• Network: Unexpected TLS connections from the OpenList server (ports 5244/5245 source) to unfamiliar IP addresses on port 443; ARP spoofing activity detected on the local network segment (duplicate ARP replies for gateway MAC addresses); DNS responses for storage provider domains (e.g., www.weiyun.com) resolving to unexpected IP addresses.
• Logs: OpenList application logs showing successful HTTPS connections to storage backends that subsequently return unexpected HTTP status codes (e.g., 404 from a rogue server); TLS handshake completions with certificates issued by unknown or self-signed CAs in network traffic captures.
• File System: Unexpected modifications to /etc/hosts inside the OpenList container redirecting storage provider hostnames to internal or external IPs.
• Configuration: The tls_insecure_skip_verify field set to true in the OpenList configuration file (typically /opt/openlist/data/config.json or equivalent), indicating the vulnerable default is active (Github Advisory).

Upgrade OpenList to version 4.1.10 or later, which changes the TlsInsecureSkipVerify default to false in DefaultConfig() and includes a migration patch (ResetSkipTlsVerify) that automatically resets the setting to false for existing deployments on upgrade (OpenList Release, Patch Commit). For deployments that cannot be immediately upgraded, manually set tls_insecure_skip_verify to false in the OpenList configuration file and restart the service. Additionally, implement network segmentation to restrict OpenList storage driver communications to trusted network paths, deploy intrusion detection/prevention systems to identify ARP spoofing or rogue TLS endpoints, and monitor DNS resolution for storage provider domains.

The vulnerability was discovered and reported by the XlabAI Team of Tencent Xuanwu Lab using their Atuin Automated Vulnerability Discovery Engine, following the standard 90+30 day disclosure policy. The advisory was published by the OpenList maintainer (jyxjjj) on January 31, 2026, and the fix was merged promptly. Social media activity was limited, with a brief mention on Bluesky by The Hacker Wire. Coverage was primarily through automated vulnerability tracking platforms such as Vulners, CVEFeed, and INCIBE-CERT (Github Advisory).