Malcolm: RCE über unbeschränkten .php-Upload in der File-Upload-Komponente

Ein authentifizierter Nutzer lädt eine .php-Datei in die File-Upload-Komponente hoch und ruft sie auf, um beliebigen Code als www-data im Container auszuführen.

Advisory-ID: TP-2026-022
Produkt: Malcolm (Suite zur Analyse von Netzwerkverkehr auf Basis von Zeek, Arkime und OpenSearch)
Schwachstellentyp: Unbeschränkter Upload gefährlicher Dateitypen (CWE-434)
CVE: CVE-2026-55676
CVSS 3.1: 8.8 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Betroffene Versionen: <= v26.06.0
Behoben in: v26.06.1
Hersteller-Advisory: GHSA-8cvp-m7pg-qrp7
Gemeldet: 13. Juni 2026

Zusammenfassung

Malcolm ist eine Suite zur Analyse von Netzwerkverkehr, die unter anderem das Hochladen von PCAP- und Log-Dateien zur Auswertung erlaubt. Das FilePond-PHP-Backend der File-Upload-Komponente prüft den Dateityp gegen eine standardmäßig leere Allowlist, wodurch die Typprüfung wirkungslos wird und jede Endung akzeptiert. Der Dateinamen-Sanitizer behält die Endung .php bei, und die komponenteneigene nginx-Konfiguration leitet jede URL mit Endung .php an php-fpm im selben Container weiter. Ein authentifizierter Nutzer lädt damit eine .php-Datei hoch und ruft sie anschließend auf, was beliebigen Code als www-data ausführt. turingpoint hat den Ablauf verifiziert und verantwortungsvoll gemeldet; der Hersteller hat ihn in v26.06.1 behoben.

Ursache

Das Backend akzeptiert Uploads an POST /server/php/submit.php ohne Typ-Allowlist, da ALLOWED_FILE_FORMATS standardmäßig ein leeres Array ist und die Typprüfung damit zu einem No-Op wird (file-upload/php/config.php:16). Der Dateinamen-Sanitizer bereinigt Basisname und Endung getrennt und fügt sie wieder zusammen, sodass shell.php als shell.php bestehen bleibt (FilePond.class.php:43). Committete Dateien landen in /var/www/upload/server/php/files (config.php:7), das die komponenteneigene nginx für jede auf .php endende URL an php-fpm weiterreicht (file-upload/nginx/sites-available/default:13), während die Malcolm-Eingangs-nginx /server/php hinter genau einer Authentifizierungsprüfung dorthin proxyt (nginx/nginx.conf:155). Im RBAC-Modus (NGINX_AUTH_MODE=keycloak plus ROLE_BASED_ACCESS=true, nicht Standard) ist der Endpunkt bereits durch die niedrig privilegierte Rolle ROLE_UPLOAD erreichbar (nginx/lua/nginx_auth_helpers.lua:71), sodass ein reines Upload-Konto Codeausführung jenseits seiner vorgesehenen Berechtigung erlangt. Ein authentifizierter GET /server/php/files/<name>.php führt die hochgeladene Datei dann als www-data aus.

Proof of Concept

Als authentifizierter Nutzer:

POST /server/php/submit.php  (multipart/form-data, filename="shell.php")
-> 200, Datei wird unter files/shell.php abgelegt

GET /server/php/files/shell.php?c=id
-> uid=1000(www-data) gid=1000(www-data)

Die leere Allowlist lässt die .php-Datei passieren, der Sanitizer erhält die Endung, und die komponenteneigene nginx leitet den anschließenden GET an php-fpm, das die Datei als www-data ausführt.

Auswirkung

  • Ausführung beliebigen Codes als www-data im File-Upload-Container.
  • Privilegienerhöhung von einer reinen Upload-Rolle (ROLE_UPLOAD) zur Codeausführung im RBAC-Modus.
  • Lesezugriff auf hochgeladene Capture-Daten und den Admin-Passwort-Hash (MALCOLM_PASSWORD, offline knackbar).
  • Schreibzugriff auf die host-gemounteten Verzeichnisse, die in die Analyse-Pipeline einfließen.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen