Description

Malcolm is a network traffic analysis tool suite. The file-upload component (FilePond PHP backend) accepts uploads at `POST /server/php/submit.php` and stores them in a directory served by the same nginx and php-fpm instance. The allow-list that should restrict accepted file types is an empty array by default (`file-upload/php/config.php:16`), so the type check is a no-op and every extension is accepted. The filename sanitizer keeps the `.php` extension intact. Committed files land in `/var/www/upload/server/php/files` (`file-upload/php/config.php:7`), and the component's nginx routes any URL ending in `.php` to php-fpm. An authenticated `GET /server/php/files/<name>.php` then executes the uploaded code as `www-data`. Prior to version 26.06.1, in RBAC mode, the upload endpoint is reachable by the granular `ROLE_UPLOAD` role (`nginx/lua/nginx_auth_helpers.lua:71`), a role intended only for submitting capture files. As a result, a user holding the upload-only role runs arbitrary PHP as `www-data` inside the file-upload container. Version 26.06.1 fixes the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-11T21:17:37.560Z",
  "pubdate": "2026-08-11T21:17:37.560Z",
  "executiveSummary": "Malcolm contains an arbitrary file upload leading to remote code execution within its FilePond PHP backend component prior to version 26.06.1.\nThe vulnerability arises from an unconstrained file type allow-list and improper filename sanitization, allowing authenticated users with limited privileges to upload and execute arbitrary PHP code.\nAn attacker possessing the restricted ROLE_UPLOAD role can abuse the upload endpoint to submit malicious PHP scripts, which are subsequently stored in a web-accessible directory and executed by the php-fpm instance under the www-data user context.\nThe risk implication is severe, as it enables unauthorized system access, potential container breakout vectors, and complete compromise of the affected file-upload service.\nSuccessful exploitation requires authentication and access to the granular ROLE_UPLOAD role, which was previously permitted to access the upload endpoint.\nMalcolm version 26.06.1 addresses this issue by correcting the access controls and mitigating the execution of untrusted scripts.",
  "technicalDetails": "The vulnerability resides in the FilePond PHP backend component of Malcolm, specifically interacting with the POST /server/php/submit.php endpoint and configuration settings defined in file-upload/php/config.php.\nThe root cause of the vulnerability is a combination of an empty default allow-list array at file-upload/php/config.php:16 and a filename sanitizer that preserves the .php extension.\nBecause the allow-list is unconfigured by default, the type check mechanism acts as a no-op, accepting all file extensions submitted through the upload interface.\nCommitted files are stored within the web-accessible directory path located at /var/www/upload/server/php/files as specified in file-upload/php/config.php:7.\nThe component's nginx configuration is configured to route any incoming URL request ending in the .php extension directly to the php-fpm processor.\nPrior to version 26.06.1, RBAC mode implementation in nginx/lua/nginx_auth_helpers.lua:71 allowed users holding the granular ROLE_UPLOAD role—a role specifically intended only for submitting capture files—to successfully reach the POST /server/php/submit.php endpoint.\nThe attack flow proceeds as follows: First, an authenticated user with the ROLE_UPLOAD role crafts a malicious request containing a payload with a .php extension. Second, the user submits the payload via POST /server/php/submit.php. Third, the backend accepts the file due to the empty allow-list and preserves the .php extension during sanitization, writing the file to /var/www/upload/server/php/files/<name>.php. Finally, the attacker issues an authenticated GET /server/php/files/<name>.php request, forcing the nginx and php-fpm stack to execute the uploaded script.\nThe execution of the payload occurs in the context of the www-data user, granting the attacker arbitrary code execution capabilities within the isolated file-upload container environment."
}