Kurz gesagt: composer audit gleicht die Pakete Ihres PHP-Projekts mit bekannten Sicherheitsmeldungen ab und zeigt betroffene Versionen. Führen Sie den Befehl bei jedem Build und regelmäßig auf dem Produktivstand aus. Wichtig nach PHP2Shell: Die Prüfung erfasst Bibliotheken, nicht den PHP-Interpreter selbst.
Warum Abhängigkeiten gerade jetzt Aufmerksamkeit brauchen
Moderne PHP-Anwendungen bestehen zum größten Teil aus fremdem Code. Ein Shop auf Basis von Symfony oder ein Portal mit Laravel bringt schnell mehrere Dutzend bis Hunderte Pakete mit, viele davon indirekt über andere Pakete. Jede dieser Bibliotheken kann eine Lücke enthalten. Die OWASP Top 10 führen veraltete und verwundbare Komponenten deshalb als eigene Risikokategorie.
Im Oktober 2026 hat PHP2Shell gezeigt, wie schnell eine kritische Lücke in die Breite geht. Die beiden Lücken CVE-2026-109618 und CVE-2026-109619 betreffen zwar PHP selbst und nicht Composer-Pakete. Viele Teams haben in diesen Tagen aber ihre gesamte Kette überprüft und dabei festgestellt, dass sie den Stand ihrer Abhängigkeiten gar nicht genau kennen.
Diese Lücke in der Übersicht lässt sich mit wenig Aufwand schließen. Composer bringt das passende Werkzeug in aktuellen Versionen bereits mit.
Was composer audit prüft und was nicht
Der Befehl liest die installierten Pakete oder die Lock-Datei und fragt bekannte Sicherheitsmeldungen zu diesen Paketen ab. Für jeden Treffer zeigt er Paket, betroffenen Versionsbereich, Schweregrad, Kennung der Meldung und einen Link zur Beschreibung.
| Ebene | Geprüft durch composer audit? | Wie stattdessen prüfen |
|---|---|---|
| Composer-Pakete im Projekt | ja | composer audit |
| PHP-Interpreter (z. B. PHP2Shell) | nein | Paketstand, Hoster-Bestätigung |
| PHP-Erweiterungen aus dem System | nein | Paketverwaltung der Distribution |
| JavaScript-Pakete im Frontend | nein | Werkzeug des jeweiligen Paketmanagers |
| Eigener Anwendungscode | nein | Code-Review, Sicherheitsaudit |
Der Befehl berücksichtigt auch indirekte Abhängigkeiten, also Pakete, die Sie nie selbst angefordert haben, die aber über andere Pakete mitkommen. Gerade dort liegen Lücken häufig unbemerkt, weil niemand im Team diese Pakete kennt. Neuere Composer-Versionen weisen außerdem auf Pakete hin, die von ihren Autoren als aufgegeben markiert wurden. Solche Pakete erhalten in der Regel keine Korrekturen mehr und sollten ersetzt werden.
Ein sauberes Ergebnis bedeutet also nur, dass für die installierten Paketversionen keine bekannte Meldung vorliegt. Unbekannte Lücken und Fehler im eigenen Code findet das Werkzeug nicht. Wie Sie den PHP-Stand selbst prüfen, beschreibt der Beitrag PHP-Version und Patchstand richtig prüfen.
composer audit ausführen und Ergebnisse lesen
Im Projektverzeichnis genügt ein Befehl. Die Varianten unterscheiden sich darin, was geprüft wird und wie das Ergebnis ausgegeben wird.
# Installierte Pakete prüfen
composer audit
# Nur die Lock-Datei prüfen, z. B. im Build ohne installierte Pakete
composer audit --locked
# Entwicklungsabhängigkeiten auslassen (Stand wie auf dem Server)
composer audit --no-dev
# Maschinenlesbare Ausgabe für Auswertung oder Ticketsystem
composer audit --format=json > audit-$(date +%F).json
Findet der Befehl Lücken, endet er mit einem Fehlercode. Das ist gewollt, denn so bricht ein automatisierter Build ab. Bewerten Sie jeden Treffer: Ist das Paket auf dem Server im Einsatz, wird die betroffene Funktion genutzt, gibt es eine behobene Version?
# Welche direkten Abhängigkeiten sind veraltet?
composer outdated --direct
# Warum ist ein bestimmtes Paket installiert?
composer why vendor/paket
# Gezielt aktualisieren, mit Abhängigkeiten
composer update vendor/paket --with-dependencies
Testen Sie jedes Update in einer Staging-Umgebung. Sicherheitsupdates innerhalb derselben Hauptversion sind meist unkritisch, eine neue Hauptversion kann dagegen Anpassungen am Code erfordern.
Die Prüfung automatisieren
Ein einmaliger Aufruf hilft wenig, denn neue Lücken werden laufend bekannt. Binden Sie composer audit deshalb an zwei Stellen ein: in die Build-Pipeline bei jeder Änderung und in eine regelmäßige Prüfung des Produktivstands, auch wenn sich am Code nichts ändert.
Ein einfaches Skript für einen täglichen Lauf auf dem Build- oder Prüfserver kann so aussehen:
#!/bin/sh
# Täglicher Audit des ausgelieferten Stands (Pfad anpassen)
cd /srv/build/meine-anwendung || exit 1
if ! composer audit --locked --no-dev --format=plain > /var/log/composer-audit.log 2>&1; then
logger -t composer-audit "Lücken in meine-anwendung gefunden, siehe /var/log/composer-audit.log"
fi
Leiten Sie die Meldung aus dem Systemprotokoll an Ihre Überwachung, Ihr internes Postfach oder Ihr Ticketsystem weiter. Wichtig ist, dass jemand verantwortlich ist, Meldungen zu bewerten. Ein Audit, dessen Warnungen niemand liest, schützt nicht.
Legen Sie in composer.json unter config.platform.php die PHP-Version fest, die auf dem Server läuft. Dann löst Composer nur Pakete auf, die zu diesem Stand passen, und composer check-platform-reqs zeigt Abweichungen.
Sauber ausliefern: Deployment ohne Nebenwirkungen
Auch der Weg auf den Server beeinflusst die Sicherheit. Bewährt haben sich einige Grundregeln:
composer.lockins Repository aufnehmen und auf dem Server nurcomposer installausführen, niecomposer update.- Mit
--no-devinstallieren, damit Test- und Debug-Werkzeuge nicht auf dem Produktivserver landen. - Den Ordner
vendor/außerhalb des Web-Wurzelverzeichnisses halten, sodass er nicht direkt über eine URL erreichbar ist. composer validateim Build ausführen, um fehlerhafte oder widersprüchliche Angaben früh zu erkennen.
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
Achten Sie außerdem auf die Unterstützung der PHP-Version selbst. Bibliotheken setzen zunehmend aktuelle PHP-Zweige voraus. Wer noch auf PHP 8.1 oder älter festhängt, bekommt für PHP selbst keine offiziellen Updates mehr und kann neuere Paketversionen mit Sicherheitskorrekturen oft nicht mehr installieren. Die Planung dazu beschreibt der Ratgeber PHP-End-of-Life: Risiken veralteter Versionen. Framework-spezifische Hinweise finden Sie unter Laravel-Anwendungen absichern.
Wie hilft PHP SOS konkret?
- Wir erfassen den Stand aller Abhängigkeiten und bewerten Treffer nach tatsächlicher Nutzung.
- Wir richten automatisierte Prüfungen in Build und Betrieb ein, mit klarer Zuständigkeit für Befunde.
- Wir planen und testen Updates, auch wenn neue Hauptversionen Anpassungen erfordern.
- Wir prüfen auf Wunsch auch eigenen Code und Konfiguration, wo kein automatisches Werkzeug hinsieht.
Eine Prüfung durch Dritte beschreibt die Leistung Sicherheitsaudit und Penetrationstest.
Häufige Fragen
Findet composer audit auch PHP2Shell?
Nein. composer audit prüft die Pakete in Ihrem Projekt, nicht den PHP-Interpreter auf dem Server. PHP2Shell steckt in PHP selbst und wird nur durch ein Update von PHP und einen Neustart aller PHP-Prozesse behoben.
Muss composer.lock ins Repository?
Bei Anwendungen ja. Die Lock-Datei hält fest, welche Versionen genau installiert sind. Nur so prüft composer audit den Stand, der tatsächlich auf dem Server läuft, und jedes Deployment installiert dieselben Versionen.
Was tun, wenn für ein betroffenes Paket kein Update existiert?
Prüfen Sie, ob Ihr Projekt die betroffene Funktion überhaupt nutzt, und dokumentieren Sie die Bewertung. Gibt es keinen Fix, kommen ein Ersatzpaket, ein eigener Patch oder eine vorübergehende Absicherung auf Server-Ebene infrage.
Wie oft sollte ich composer audit ausführen?
Bei jedem Build und zusätzlich regelmäßig, etwa täglich, auch ohne Codeänderung. Neue Lücken werden laufend gemeldet, und ein Stand, der gestern sauber war, kann heute betroffen sein.