Zusammenfassung

Die Schwachstelle

Composer kann Pakete aus verschiedenen Versionskontrollsystemen auflösen. Für Perforce wird das Repository durch eine p4://-URL identifiziert, die Host, Port und Benutzer/Stream kodiert. Wenn der Perforce-Treiber von Composer die zugrunde liegende p4-Befehlszeile aufbaut, werden Felder aus der vom Angreifer kontrollierten URL nicht ausreichend bereinigt, bevor sie an eine Shell übergeben werden.

Da der Autor des Manifests die Repository-URL vollständig kontrolliert, kann ein Angreifer, der ein Opfer dazu bringt, composer update/composer install gegen eine bösartige composer.json auszuführen (z. B. eine vergiftete Abhängigkeit, ein feindliches Repository oder einen CI-Job, der nicht vertrauenswürdige Projektdateien verarbeitet), aus dem vorgesehenen p4-Aufruf ausbrechen und beliebige Betriebssystembefehle mit den Rechten des Composer-Prozesses ausführen.

Dies gehört zur gleichen Familie wie historische Argument-Injektionsprobleme bei Composer-VCS-Treibern, bei denen URL-/Branch-/Stream-Werte unescaped in Shell-Befehle einfließen. Composer 2.9.6 härtet den Perforce-Treiber so, dass der injizierte Payload nicht mehr ausgeführt wird.

Die maßgebliche Beschreibung des hier demonstrierten Verhaltens ist der PoC-Quellcode selbst (CVE202640176Test.php); konsultieren Sie das offizielle Advisory und das Composer-Changelog für Details zum Upstream-Fix.

Wie der PoC funktioniert

Der PoC ist eine einzelne Klasse, CVE202640176Test, die ein kontrolliertes A/B-Experiment (differentiell) durchführt:

1. Vorprüfung — fragt --version bei beiden Composer-Binaries ab (betroffen: 2.9.5, korrigiert: 2.9.6) und bricht frühzeitig ab, wenn eines nicht aufgerufen werden kann.
2. Betroffener Lauf (2.9.5)
   • Erstellt ein isoliertes temporäres Verzeichnis unter dem System-Temp-Pfad.
   • Schreibt eine composer.json, deren repositories-Abschnitt einen perforce-Eintrag mit einer bösartigen p4://-URL enthält, die einen injizierten Shell-Payload trägt.
   • Führt composer update in diesem Verzeichnis aus.
   • Validiert das Ergebnis.
3. Korrigierter Lauf (2.9.6) — wiederholt exakt dieselben Schritte mit dem gepatchten Binary.
4. Wiederherstellung — ein finally-Block stellt immer die ursprüngliche composer.json im Projektverzeichnis wieder her.
5. Urteil — gibt PASS nur aus, wenn der betroffene Lauf den Nebeneffekt zeigt und der korrigierte Lauf ihn nicht zeigt.

Validierung (was als „ausgenutzt" gilt)

Für jeden Lauf prüft validateRun() drei Dinge:

Ein Lauf ist nur dann „OK", wenn alle drei Prüfungen bestehen. Der Gesamttest besteht, wenn der betroffene Lauf OK ist und der korrigierte Lauf nicht — die genaue Signatur einer echten Schwachstelle, die anschließend gepatcht wurde.

Der Injektions-Payload (erklärt)

Die bösartige Repository-URL wird in writeComposerJson() erstellt:

Aufgeschlüsselt:

• p4://127.0.0.1:1666:attacker_user — eine wohlgeformt aussehende Perforce-URL (Host, Port 1666, Benutzer).
• ;touch <marker> && echo '<runId>' > <marker> — die injizierten Shell-Befehle. Das führende ; beendet den vorgesehenen p4-Befehl; touch erstellt die Markierungsdatei und echo '<runId>' > <marker> schreibt die eindeutige Lauf-ID hinein, damit der PoC bestätigen kann, dass der Payload (und nicht ein anderer Prozess) die Datei erzeugt hat.
• :client_test — nachgestellter Text, um den Rest der URL-Interpretation plausibel zu halten.

Beim betroffenen Treiber werden die Shell-Metazeichen berücksichtigt und die Markierungsdatei erstellt. Beim korrigierten Treiber wird der Wert ordnungsgemäß escaped/in Anführungszeichen gesetzt, sodass dieselbe Zeichenkette als inerte Daten behandelt wird und keine Markierung erscheint.

Hinweis: Der PoC verwendet eine eindeutige, mit Zeitstempel versehene Lauf-ID und schreibt seine Markierung in ein isoliertes temporäres Verzeichnis, sodass der Payload harmlos und selbstreinigend statt destruktiv ist.

Voraussetzungen

• PHP 7.4+ (entwickelt/getestet gegen PHP 8.x CLI). Der PoC selbst verwendet nur Kernfunktionen — keine Composer-Pakete erforderlich, um das Harness auszuführen.
• Zwei Composer-Binaries als PHARs verfügbar:
  • Composer 2.9.5 (betroffen)
  • Composer 2.9.6 (korrigiert)
• Eine POSIX-artige Shell-Umgebung (exec() führt cd … && php … aus). Für Linux/macOS ausgelegt.
• Eine Basis-composer.json im Projektverzeichnis (wird beim Start gelesen, in jeden temporären Lauf kopiert und danach wiederhergestellt).

In der Regel benötigen Sie keinen laufenden Perforce-Server: Die Schwachstelle liegt darin, wie Composer die p4-Befehlszeile aufbaut, und der injizierte Payload läuft vor/um jede echte p4-Verbindung. Composer protokolliert möglicherweise einen Perforce-Verbindungsfehler — das ist erwartet und beeinträchtigt den Markierungsdatei-Beweis nicht.

Einrichtung

1. PoC klonen / ablegen in einem Arbeitsverzeichnis.

2. Eine composer.json bereitstellen im selben Verzeichnis wie der PoC. Eine minimale genügt:

   root@kitploit:~

   {
     "name": "research/cve-2026-40176-poc",
     "description": "Base manifest for the CVE-2026-40176 differential PoC",
     "require": {}
   }
   

3. Die beiden Composer-Binaries besorgen und dort ablegen, wo der PoC sie erwartet (Standardwerte gezeigt):

   root@kitploit:~

   /usr/local/bin/composer-2.9.5.phar   # affected
   /usr/local/bin/composer-2.9.6.phar   # fixed
   

   Sie können bestimmte Composer-Versionen aus dem offiziellen Archiv herunterladen, z. B.:

   root@kitploit:~

   curl -Lo /usr/local/bin/composer-2.9.5.phar https://getcomposer.org/download/2.9.5/composer.phar
   curl -Lo /usr/local/bin/composer-2.9.6.phar https://getcomposer.org/download/2.9.6/composer.phar
   

   Wenn Ihre Pfade abweichen, bearbeiten Sie die beiden Konstruktor-Argumente am Ende von CVE202640176Test.php.

Verwendung

Das Harness führt beide Composer-Versionen nacheinander aus und gibt ein endgültiges Urteil aus. Die ursprüngliche composer.json wird automatisch wiederhergestellt, auch wenn ein Lauf fehlschlägt (die Arbeit findet in Wegwerf-Temp-Verzeichnissen statt).

In Docker ausführen (empfohlen)

Das Repo enthält ein containerisiertes Labor, das die Umgebung exakt nachbildet: eine PHP-CLI-Laufzeit plus die beiden festgelegten Composer-Versionen an den vom PoC erwarteten Pfaden, zur Laufzeit vollständig netzwerkisoliert.

Dies erstellt cve-2026-40176-lab:latest (lädt Composer 2.9.5 und 2.9.6 herunter und verifiziert während des Builds jeweils --version) und führt den differentiellen Test in einem unprivilegierten Container ohne Zugriff nach außen aus.

Was das Labor garantiert:

• Echte Binaries. Beide Composer-Versionen werden aus dem offiziellen Archiv geholt und beim Build per Versionsprüfung verifiziert — der Build schlägt lautstark fehl, wenn eine festgelegte Version nicht verfügbar ist.
• Isolation. Der poc-Dienst läuft auf einem internal-Bridge-Netzwerk (kein Host-/Internet-Egress), mit cap_drop: ALL und no-new-privileges. Der Injektions-Payload bleibt eingedämmt.
• Keine Host-Einrichtung. Keine Notwendigkeit, PHARs auf dem Host zu platzieren oder Pfade manuell zu bearbeiten.

Die Versionen neu festlegen (muss mit den beiden Konstruktor-Pfaden im PoC synchron bleiben) über Build-Argumente:

Optional — Live-Perforce-Server. Ein p4d-Dienst ist unter dem full-lab-Profil verfügbar (docker compose --profile full-lab up). Der markierungsbasierte Beweis benötigt ihn nicht; er existiert für Forscher, die einen echten p4://-Endpunkt wünschen. Beachten Sie, dass der PoC-Payload auf 127.0.0.1:1666 zielt, sodass ein Routing über einen separaten p4d-Container erfordert, die PoC-URL auf den Host p4d zu richten.

Reproduktionsstatus (beobachtet)

Ehrliches Ergebnis: Gegen die echten, veröffentlichten Composer-Versionen 2.9.5 und 2.9.6 löst der PoC derzeit nicht aus, und das Labor meldet INCONCLUSIVE / FAIL.

Die Ausführung des betroffenen Composer (2.9.5) gegen das bösartige Manifest des PoC wirft innerhalb von Composer bevor irgendein p4-/Shell-Befehl aufgebaut wird:

PerforceDriver::initialize() liest zuerst $this->repoConfig['depot'], aber der Repository-Eintrag des PoC liefert nur type und url (keinen depot-Schlüssel). Der Treiber bricht an dieser Stelle ab, sodass der injizierte ;touch <marker>-Payload in der URL nie erreicht wird und keine Markierung erstellt wird. Netzwerkisolation ist nicht die Ursache — derselbe Fehler tritt mit vollem Egress auf.

Was das bedeutet:

• Das Docker-Labor selbst ist korrekt und führt das differentielle Harness treu gegen die echten betroffenen/korrigierten Binaries aus. Das INCONCLUSIVE-Ergebnis ist eine Eigenschaft des PoC-Payloads, nicht der Umgebung.
• Um den tatsächlichen Pfad der Perforce-Befehls-Konstruktion zu durchlaufen, müsste die Repository-Konfiguration des PoC mindestens einen depot-Schlüssel enthalten (und realistischerweise einen echten p4d-Endpunkt unter dem full-lab-Profil). Den Payload bis zu diesem Punkt zu verfeinern ist Exploit-Entwicklung jenseits von „das Labor aufsetzen" und hier bewusst außerhalb des Rahmens gelassen.

Die unten stehende „Erwartete Ausgabe" ist das beabsichtigte/idealisierte Ergebnis des PoC, zur Referenz beibehalten; es ist nicht das, was der aktuelle Payload gegen den echten Treiber produziert.

Erwartete Ausgabe

Eine erfolgreiche Demonstration sieht ungefähr so aus (Pfade und IDs variieren):

Ein Exit-Code ungleich Null von Composer ist normal — composer update schlägt letztlich beim Abrufen des (fiktiven) Pakets fehl. Der Beweis ist die Markierungsdatei, nicht der Exit-Status von Composer.

Interpretation des Ergebnisses

Häufige Ursachen für ein nicht schlüssiges Ergebnis:

• Der Treiber bricht bei PerforceDriver.php:40 mit Undefined array key "depot" ab — der Repository-Konfiguration fehlt ein depot-Schlüssel, sodass Composer den Pfad zur p4-Befehls-Konstruktion nie erreicht. Genau das passiert mit dem aktuellen Payload des PoC gegen die echten 2.9.5/2.9.6 (siehe Reproduktionsstatus).
• Die Composer-Binary-Pfade sind falsch oder die PHARs sind nicht wirklich 2.9.5 / 2.9.6.
• Die Host-Shell oder PHP exec() ist in einer Sandbox/deaktiviert.
• Die Composer-Ausgabe enthält nicht die wörtliche Zeichenkette p4 (Treiberpfad nicht erreicht).

Projektstruktur

Der gesamte PoC ist eine Datei:

• __construct() — speichert die beiden Binary-Pfade, erzeugt eine mit Zeitstempel versehene Lauf-ID, macht eine Momentaufnahme der ursprünglichen composer.json.
• run() — orchestriert Vorprüfung, betroffenen Lauf, korrigierten Lauf, Wiederherstellung und Urteil.
• prepareTempDir() — erstellt pro Lauf ein isoliertes Arbeitsverzeichnis.
• writeComposerJson() — erstellt das bösartige Manifest mit der injizierten p4://-URL.
• runComposer() — führt composer update aus (Argumente mit escapeshellarg() escaped) und erfasst Ausgabe + Exit-Code.
• validateRun() — prüft Version, Markierungsdatei und Perforce-Treiber-Aktivität.
• preflightVersion() — liest --version eines angegebenen Binaries.

Design-Hinweise

• Isolation & Bereinigung. Jeder Lauf nutzt ein eigenes Temp-Verzeichnis; die ursprüngliche composer.json wird unabhängig vom Ergebnis in einem finally-Block wiederhergestellt.
• Harness vs. Payload-Escaping. Das Harness escapet seine eigenen Shell-Argumente mit escapeshellarg() (damit der PoC nicht versehentlich in seine eigenen exec()-Aufrufe injiziert). Die Schwachstelle liegt eine Ebene tiefer — darin, wie Composer selbst den p4-Befehl aufbaut — genau das ist das Ziel des Payloads.
• Differentieller Beweis. Das Ausführen sowohl des verwundbaren als auch des gepatchten Binaries in einem Durchlauf beseitigt Mehrdeutigkeit: Dieselbe Eingabe erzeugt divergentes Verhalten, was ein weitaus stärkerer Beleg ist als eine einzelne positive Beobachtung.
• Harmloser Payload. Die injizierten Befehle führen nur touch/echo in ein eindeutiges Temp-Marker aus, wodurch der PoC wiederholt ohne Nebenwirkungen auf den Host sicher ausgeführt werden kann.

Einschränkungen & bekannte Probleme

• Hartkodierte Binary-Pfade. Die beiden PHAR-Pfade werden inline am Ende der Datei übergeben. Passen Sie sie für Ihre Umgebung an (oder refaktorieren Sie sie, um sie aus CLI-Argumenten / Umgebungsvariablen zu lesen).
• POSIX-Annahme. Das exec("cd … && php …")-Muster und der ;/&&-Payload setzen eine Unix-ähnliche Shell voraus; Windows wird nicht wie vorgesehen unterstützt.
• mkdir-Race / Berechtigungen. Temp-Verzeichnisse werden mit Modus 0777 erstellt; verschärfen Sie dies, wenn Sie in einer gemeinsamen Umgebung arbeiten.
• Versionserkennung ist regex-basiert. Sie parst Composer X.Y.Z aus der Ausgabe; ungewöhnliche Composer-Banner könnten den Abgleich verhindern.

Verantwortungsvolle Nutzung

Dieses Repository existiert, um CVE-2026-40176 zu verstehen und sich dagegen zu verteidigen.

• Führen Sie es nur gegen Systeme und Composer-Installationen aus, die Sie besitzen oder für die Sie ausdrücklich autorisiert sind.
• Die Kernbotschaft für Verteidiger: Upgraden Sie Composer auf 2.9.6 oder neuer und führen Sie composer install/update niemals auf nicht vertrauenswürdigen composer.json-Dateien aus (z. B. in CI-Pipelines, die Projektquellen Dritter verarbeiten) ohne Isolation.
• Verwenden Sie die Injektionstechnik nicht gegen Systeme, die Sie nicht kontrollieren. Unautorisierte Ausnutzung ist illegal und unethisch.

Referenzen

• Composer — offizielles Projekt
• Composer-Release-Archiv (zum Abrufen bestimmter 2.9.5- / 2.9.6-PHARs)
• Offizielles CVE-2026-40176-Advisory und das Composer-2.9.6-Changelog (konsultieren Sie den Sicherheits-Tracker Ihrer Distribution / die GitHub Advisory Database für die maßgeblichen Fix-Details)
• Hintergrund zur Argument-Injektion bei Composer-VCS-Treibern (dieselbe Schwachstellenklasse), z. B. CVE-2021-29472

Autor: Ikarolaborda · PoC datiert 2026-06-10.