saku0512/cve-2026-84361-pocProof-of-Concept für CVE-2026-84361, das eine Befehlsinjektion im Perforce-Treiber von Composer über einen bösartigen P4PORT demonstriert, mit Docker-basierter Verifizierung und Hinweisen zur Schadensbegrenzung.
Mit Docker Compose können Sie die Validierung in einer isolierten Umgebung mit dem betroffenen Composer 2.10.2 und dem Perforce-p4-Client durchführen. Der Ausführungscontainer ist netzwerklos, schreibgeschützt und ohne Capabilities; beschreibbar sind nur die tmpfs-Verzeichnisse /tmp und /work.
# Image bauen (p4 wird von der offiziellen Quelle bezogen und per SHA-256 verifiziert)
docker compose build
# p4-rsh:-Verhalten direkt validieren (Standard)
docker compose run --rm poc
# Über den verwundbaren Composer validieren
docker compose run --rm poc /usr/local/bin/run-composer-poc.sh
Der letzte Befehl führt composer update --prefer-source in einem temporären Arbeitsbereich im Container aus. Da ein Marker-Befehl statt eines Perforce-Servers verwendet wird, kann Composer selbst fehlschlagen; wenn der Marker erstellt wird, wird angezeigt und der Prozess endet erfolgreich.
[+] VULNERABLEDies ist ein PoC zur lokalen Validierung von CVE-2026-84361 im Perforce-VCS-Treiber von Composer. Der betroffene Composer übergibt bei source.type des Pakets perforce die vom Angreifer kontrollierte source.url als P4PORT an den p4-Client.
p4 behandelt rsh:-/jsh:-P4PORT nicht als Netzwerkziel, sondern als lokalen Befehl. Daher führt die Installation einer Quelle aus nicht vertrauenswürdigen Paketmetadaten oder einer composer.lock Befehle mit den Rechten des Benutzers aus, der Composer ausführt, bzw. des CI-Kontos aus.
Die Payload dieses PoC erstellt lediglich eine leere Markierungsdatei im temporären Bereich.
Entdecker: saku0512 (GitHub)
Nur für Bildungszwecke und Sicherheitsvalidierung in ausdrücklich autorisierten Umgebungen verwenden. Nicht ohne Erlaubnis auf fremden Systemen oder CI-Umgebungen ausführen.
>= 1.0, < 2.2.30 und >= 2.3.0, < 2.10.3Für eine erfolgreiche Ausnutzung müssen alle folgenden Bedingungen erfüllt sein: p4 befindet sich im PATH, der Angreifer kann die Perforce-Quellmetadaten kontrollieren und das Zielpaket wird aus der Quelle installiert. Da Packagist.org keine Perforce-Quellmetadaten zulässt, sind reine Packagist-Nutzungen nicht betroffen.
p4-Clientphp -v
p4 -V
Standardmäßig wird p4 nicht gestartet; es werden nur der gefährliche P4PORT und der zur Ausführung vorgesehene Befehl angezeigt.
php poc.php
--execute übergibt rsh:-P4PORT an p4. Die Payload erstellt lediglich eine eindeutige Markierung unter sys_get_temp_dir() und räumt sie standardmäßig auf.
php poc.php --execute
Wenn [+] VULNERABLE erscheint, wurde bestätigt, dass ein lokaler Befehl über P4PORT ausgeführt wurde. Um die Markierung zu behalten, fügen Sie --keep-marker hinzu.
Die beiliegende composer.json ist ein minimales Beispiel für ein Inline-Paket-Repository, das ein Angreifer verteilt. Führen Sie Folgendes mit einem ungepatchten Composer und p4 in einer isolierten Umgebung aus:
composer update --prefer-source
Die gepatchte Version lehnt source.url als ungültigen Perforce-Port ab, bevor p4 gestartet wird.
Aktualisieren Sie Composer auf 2.2.30 oder 2.10.3 oder höher. Verwenden Sie nur vertrauenswürdige Repositories und Lock-Dateien und entfernen Sie p4 aus dem PATH in Umgebungen, die kein Perforce verwenden.