Wenn ein composer install zur Code-Ausführung wird: CVE-2026-40176 und CVE-2026-40261 in der Composer-Lieferkette

TL;DR — die 90-Sekunden-Zusammenfassung

CVE-2026-40176 (CVSS 7.8)

Unzureichendes Escaping in Composer-Repository-Metadaten — präparierte composer.json führt zu Code-Ausführung im Build-User-Kontext

CVE-2026-40261 (CVSS 8.8)

Identische Klasse über jedes Composer-Repository inklusive Packagist auslösbar, keine Perforce-Installation nötig

Sofort-Patch

Composer 2.9.6 oder 2.2.27 LTS — plus Packagist hat Perforce-Source-Metadaten deaktiviert

Eigentliche Gefahr

Build-User hat SSH-Keys, Registry-Tokens, Cloud-Credentials — RCE im Build ist Lateral Movement

Vier Leitplanken

Lockfile-Builds, eingefrorenes Composer-Bin in CI-Image, Renovate mit Karenzzeit, read-only Composer-Mirror

Wer ist gefordert

jeder Mittelstand mit PHP-Stack — TYPO3, Sylius, Symfony, Laravel sind gleich exponiert

 

Was ist das Problem?

Am 10. April 2026 hat das Composer-Maintainer-Team zwei Schwachstellen veröffentlicht und gleichzeitig Patches geliefert: CVE-2026-40176 (CVSS 7.8) und CVE-2026-40261 (CVSS 8.8). Beide Lücken liegen im Pfad, in dem Composer Repository-Metadaten verarbeitet. Eine präparierte composer.json oder eine manipulierte Source-Reference, die Shell-Metazeichen enthält, wird unzureichend escaped und an einen Subprozess weitergegeben. Resultat: beliebige Code-Ausführung im Kontext des Build-Users.

Die schwerwiegendere Variante lässt sich über jedes Composer-Repository auslösen, also auch über Packagist, und benötigt keine Perforce-Installation auf dem Zielsystem. Als Sofortmaßnahme hat Packagist.org am 10. April die Veröffentlichung von Perforce-Source-Metadaten deaktiviert.

Wir sind in unseren Pipelines nicht getroffen worden. Das ist keine Glanzleistung, sondern das Ergebnis derselben Disziplin, mit der wir auch andere Werkzeuge in unserer Build-Chain führen. In diesem Beitrag ordnen wir den Vorfall ein und beschreiben, welche strukturellen Entscheidungen den Unterschied machen — unabhängig davon, ob das nächste Composer-CVE oder die nächste npm-Welle kommt.

Auswirkungen: warum ein Build-RCE kein Build-Problem ist

Composer-Lücken treffen nicht das Produkt, sondern den Weg dorthin. Der eigentliche Code in Ihrem Repository ist sauber, die Anwendung läuft, der Build wäre erfolgreich — und genau in diesem Moment hat ein Subprozess auf Ihrem CI-Runner einen fremden Befehl ausgeführt. Drei Effekte machen das Risikoprofil so unangenehm.

Builds laufen oft mit höheren Rechten als die spätere Anwendung

SSH-Keys, Container-Registry-Tokens, Cloud-Credentials, Deployment-Tokens — alles liegt im Build-Kontext bereit. Code-Ausführung im Build ist deshalb fast nie nur ein Build-Problem, sondern der Schritt zu Lateral Movement. Dasselbe Muster wie bei der CI/CD-Verdichtung, die wir an anderer Stelle ausführlich beschrieben haben.

Composer in CI-Images wird selten aktualisiert

In den Pipeline-Reviews der letzten Wochen war Composer in vielen Fundstücken in einem fest eingefrorenen Image-Tag, ohne automatischen Update-Pfad. Eine 2.9.4 oder 2.8.x in der CI ist solange unsichtbar, bis ein Vorfall sie sichtbar macht. Anwendungs-Dependencies bekommen Renovate-PRs, die Toolchain bekommt keine.

Composer-Pakete sind transitiv

Selbst wer die eigene composer.json sauber führt, ist auf das Verhalten von Tools angewiesen, die im CI-Container vorinstalliert sind, sowie auf Plugins, die andere Pakete laden. Genau diese Klasse von Plugins hat im April 2026 — sichtbar am bekannten Intercom-Composer-Plugin-Vorfall — zur Verteilung der Mini-Shai-Hulud-Welle in den Packagist-Bereich beigetragen.

Wer ist betroffen?

Selbst ein vergleichsweise schlanker PHP-Stack hat in der Regel eine deutliche Anzahl direkter und transitiver Composer-Abhängigkeiten. Eine TYPO3-, Sylius- oder Symfony-basierte Plattform unterscheidet sich da nicht von einem größeren Konzern-Stack. Wer in der CI keinen klaren Regelkreis dafür hat, welche Pakete überhaupt akzeptiert werden, hat kein „kleineres“ Risiko, sondern nur ein weniger sichtbares.

Drei Konstellationen sind besonders exponiert:

• CI-Runner ohne Mirror-Disziplin — alles, was über Packagist hereinkommt, kommt ungefiltert.
• Produktivsysteme mit direktem composer install — Updates direkt am Live-Server bedeuten kompromittierte Server-Credentials und potenziell persistente Hintertüren in der Anwendung bei erfolgreicher Ausnutzung.
• Stacks mit großer Plugin-Oberfläche — TYPO3-Extensions, Sylius-Plugins, Symfony-Bundles: jedes zusätzlich nachgeladene Paket erweitert die Angriffsfläche im Build-Kontext.

Mitigation und Sofortmaßnahmen — die vier Leitplanken

Quick-Start in der Reihenfolge, in der wir Pipelines aktuell durchziehen — jede Zeile schlägt eine bestimmte Klasse von Vorfällen ab.

composer self-update 2.9.6   # oder 2.2.27 (LTS-Linie)
composer diagnose            # Repository-Liste prüfen
composer config --global --unset repositories.perforce-*
composer audit               # known vulns gegen lock prüfen

1. Reproduzierbare Installationen über composer install gegen ein committetes composer.lock

Unsere Builds aktualisieren keine Pakete, sie installieren genau die, die per Lockfile festgeschrieben sind. Eine geänderte Source-Reference kommt damit nur über einen expliziten Lockfile-Commit in den Build, nicht spontan im Hintergrund. composer update hat im CI nichts verloren.

2. Ein definierter Composer-Pfad lokal und in CI

Wir nutzen ein eingefrorenes Composer-Binärprogramm in einer klar versionierten Variante. Composer wird nicht spontan über composer self-update auf dem Runner aktualisiert; CI-Images werden gebaut, signiert, freigegeben. Der Versionssprung auf Composer 2.9.6 oder 2.2.27 LTS ist damit ein bewusster Schritt, kein Hintergrundgeschehen.

3. Updates über Renovate mit Karenzzeit

Neue Composer-Versionen werden nicht aus der Shell aktualisiert, sondern als Pull Request vorgeschlagen und nach Karenzzeit (typisch 72–168 Stunden) gemerged. Die Karenzzeit gibt der Community Zeit, einen Bug oder eine Sicherheitslücke zu entdecken. Ausnahme bleibt der bekannte, aktiv ausgenutzte CVE in der laufenden Version.

4. Read-only Composer-Mirror für produktive Builds

Wo immer möglich, läuft das CI gegen einen internen Mirror, der nur freigegebene Versionen weitergibt. Das ist Aufwand, gibt aber ein verlässliches Audit-Log darüber, welche Pakete jemals in den Build-Kontext kamen — und filtert Pakete heraus, die in einer Stunde Lebenszeit kompromittiert auf einer öffentlichen Registry stehen. Dasselbe Muster wie der npm-Mirror, den wir nach dem EVM/DeFi-Cluster vom 6. Mai dokumentiert haben.

Detection und Prüfung

Fünf Kernfragen, die in einer halben Stunde Klarheit bringen — ob Sie heute getroffen sein könnten und wo der größte Hebel liegt.

• Welche Composer-Versionen laufen heute auf Ihren CI-Runnern? Ein composer --version in jedem Image, das aktiv baut.
• Welche Composer-Versionen laufen auf Produktivservern, auf denen direkt composer install ausgeführt wird? Wenn Sie das nicht beantworten können, ist das die Antwort.
• Gibt es in Ihrer composer.json oder in transitiven Lockfiles Einträge mit "type": "perforce" oder verdächtigen Source-Referenzen?
• Welche CI-Builds zwischen 5. und 10. April 2026 sind über Packagist gegen ein nicht-aktualisiertes Composer-Binär gelaufen? Diese Builds gehören in eine Re-Run-Liste mit gepatchter Toolchain.
• Welche Secrets standen im Build-Kontext bereit — SSH-Keys, Container-Registry-Tokens, AWS-Credentials? Für alle diese Token gilt: nach einem unklaren Build-Vorfall rotieren, nicht hoffen.

Quick-Check-Snippets, die wir in der ersten Stunde fahren:

# Composer-Bins in allen erreichbaren Images
for img in $(docker images --format '{{.Repository}}:{{.Tag}}'); do
  docker run --rm "$img" composer --version 2>/dev/null \
    | grep -i composer
done

# Perforce-Repositories in den Lockfiles
git grep -nE '"type":\s*"perforce"' -- 'composer.lock' '**/composer.lock'

Betreiberempfehlung

Was für welchen PHP-Stack jetzt operativ sitzen sollte — in Bullet-Form, weil die Entscheidungen meist nicht zwischen „richtig“ und „falsch“ liegen, sondern zwischen „Rest-Risiko ist akzeptiert“ und „Rest-Risiko ist Zufall“.

• Wenn Ihre CI Composer aus dem Distro-Paket oder über self-update auf dem Runner installiert — dann einfrieren auf 2.9.6 in einem dedizierten Build-Image-Layer als nächster Sprint-Schritt. Vorher keine weiteren Build-Optimierungen.
• Wenn Sie heute keinen Composer-Mirror haben — dann Mini-Mirror per Satis oder Packagist-Proxy im internen Artifactory als Read-Only-Cache, gefüllt aus dem Lockfile. Kein großes Repo-Setup, eine Mittagspause.
• Wenn Renovate noch nicht läuft — dann ist es für die Composer-Versionen genauso wichtig wie für Anwendungs-Pakete. Toolchain-Updates gehören in dieselbe PR-Disziplin wie Library-Updates.
• Wenn Sie direkt auf Produktivservern composer install fahren — dann ist die nächste Pipeline-Iteration die Verlagerung auf vorgebaute Artefakte (Tarball, OCI-Image), die nur noch deployed werden. composer install in Produktion ist ein RCE-Multiplikator.
• Wenn Sie eine TYPO3-, Sylius- oder Symfony-Plattform mit großer Extension-/Plugin-Oberfläche betreiben — dann SBOM-Inventur der direkten und transitiven Composer-Abhängigkeiten als Pflicht-Element des Audit-Logs, idealerweise CycloneDX.

Cross-Referenzen: der npm-EVM-Cluster-Beitrag für Mirror-Topologien, der CI/CD-Verdichtungs-Beitrag für die strukturelle Argumentation, und der KI-Security-Audits-Beitrag für die Einbettung in eine Release-Disziplin.

Fazit

Die meisten PHP-Pipelines, die wir im Review sehen, haben einzelne dieser Bausteine. Selten alle. Entweder es gibt ein Lockfile, aber Composer wird im CI per self-update auf das jeweils aktuellste verfügbare Binärprogramm gezogen. Oder Renovate schlägt brav PRs vor, aber ohne Karenzzeit, sodass eine soeben kompromittierte Version am Folgetag im Build steht. Oder die Produktivserver bauen anders als die CI, und niemand kann nach einem Vorfall eindeutig sagen, welche Composer-Version dort gerade läuft.

Die Frage lautet nicht, ob Composer 2.9.6 in Ihren Images ist. Sie lautet, ob Ihre Pipeline den nächsten Vorfall überhaupt bemerken würde — und ob Sie nach dem Bemerken in derselben Stunde wissen, welche Builds in den Tagen davor mit der kompromittierten Version gelaufen sind.

Eine längere Aufarbeitung mit Beispielen unserer GitLab-CI-Components, der Renovate-Konfiguration und unserer Mirror-Topologie findet sich unter ole-hartwig.eu.