Kurz gesagt: Symfony-Sicherheit nach PHP2Shell heißt: PHP patchen, alle Prozesse einschließlich Messenger-Worker neu starten und danach Secrets, Cache und Profiler prüfen. Die Lücke liegt in PHP, nicht in Symfony; ein Symfony-Update allein schließt sie nicht.
Warum PHP2Shell jedes Symfony-Projekt betrifft
Symfony ist Grundlage vieler Unternehmensanwendungen, APIs und Portale und steckt außerdem in Systemen wie Shopware 6 und Contao. Die PHP-Lücken CVE-2026-109618 und CVE-2026-109619 erlauben laut PHP-Team das Ausführen von Schadcode ohne Anmeldung. Ob die Anwendung sauber programmiert ist, spielt dafür keine Rolle.
Das PHP-Team stuft das Risiko bei mod_php am höchsten ein, betroffen sind aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Symfony-Projekte, die über Symfony Runtime mit FrankenPHP oder anderen dauerhaft laufenden Servern betrieben werden, brauchen nach dem Update einen vollständigen Neustart oder ein neues Image.
Symfony-Sicherheit: PHP-Version und Prozesse prüfen
php bin/console about zeigt Symfony-Version, Umgebung, Debug-Modus und die PHP-Version der Kommandozeile. Die Web-Anfragen laufen aber über PHP-FPM oder einen Anwendungsserver, und das kann eine andere Version sein. Prüfen Sie beide Wege oder lassen Sie sie vom Betreiber bestätigen.
Behobene Upstream-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35; Backports der Distributionen tragen oft ältere Nummern. Welche PHP-Versionen Ihre Symfony-Version unterstützt, prüfen Sie laut Systemanforderungen in der Dokumentation auf symfony.com.
# Umgebung, Debug-Modus und PHP-Version anzeigen
php bin/console about
# Messenger-Worker nach der aktuellen Nachricht beenden lassen
php bin/console messenger:stop-workers
# Bekannte Lücken in Abhängigkeiten
composer audit
Laufen mehrere Instanzen hinter einem Load Balancer oder in Containern, muss jede einzelne gepatcht und neu gestartet sein. Eine vergessene Instanz bedient weiter einen Teil der Anfragen mit altem PHP.
Messenger-Worker, Cron-Befehle und andere Hintergrundprozesse laden PHP einmal beim Start. Bis sie neu gestartet werden, laufen sie mit dem alten PHP im Speicher. Ein Prozessmanager muss sie nach dem Stopp wieder hochfahren.
Wo Symfony-Anwendungen angreifbar sind
| Ort | Inhalt | Prüfpunkt |
|---|---|---|
.env, .env.local, .env.local.php |
Umgebungsvariablen, oft Datenbank und API-Schlüssel | nicht im Webroot abrufbar, Werte nach Verdacht erneuern |
config/secrets/prod/ |
verschlüsselte Secrets | der private Entschlüsselungsschlüssel gehört nicht ins Repository |
public/ |
Dokumentwurzel mit index.php |
zusätzliche PHP-Dateien |
var/cache/prod/ |
erzeugter Container und Templates als PHP | nach Verdacht löschen und neu erzeugen |
var/log/ |
Protokolle | sichern |
config/packages/security.yaml |
Firewalls, Rollen, Zugriffsregeln | unerwartete Änderungen |
Der Cache ist ein unterschätztes Versteck. Symfony erzeugt dort PHP-Dateien, die bei jeder Anfrage geladen werden. Eine Änderung an diesen Dateien fällt im Repository nicht auf, weil der Cache nicht versioniert ist.
In Produktion gehören APP_ENV=prod und APP_DEBUG=0, und das WebProfilerBundle darf dort nicht aktiv sein. Ein öffentlich erreichbarer Profiler unter /_profiler gibt Konfiguration und Anfragedaten preis.
Admin-Bereiche, Bundles und Abhängigkeiten
Symfony-Projekte haben je nach Aufbau eigene Admin-Bereiche, oft mit Bundles wie EasyAdmin oder Sonata. Prüfen Sie in security.yaml, welche Pfade welche Rollen verlangen, und in der Datenbank, wer diese Rollen hat. Admin-Pfade, die nur intern gebraucht werden, sollten auf Webserver-Ebene auf bekannte Netze beschränkt sein.
Bundles und Composer-Pakete sind fremder Code mit eigenen Lücken. composer audit zeigt bekannte Probleme; ausführlicher geht es unter Composer-Abhängigkeiten auf Lücken prüfen. Veraltete Pakete sind außerdem der häufigste Grund, warum ein PHP-Upgrade in Symfony-Projekten länger dauert als geplant.
Was ein Symfony-Update leistet und was nicht
Ein Update von Symfony-Komponenten schließt Fehler im Framework. Es patcht nicht PHP, startet keine Worker neu, erneuert keine abgeflossenen Secrets und entfernt keinen manipulierten Cache. Ob es Anzeichen eines Angriffs gibt, beschreibt Bin ich schon kompromittiert?. Da es keine bestätigten Indicators of Compromise gibt, hilft vor allem die Beobachtung ungewöhnlichen Verhaltens, etwa unerwarteter Prozesse oder ausgehender Verbindungen.
Wird das Projekt als Container ausgeliefert, gehört das neue PHP ins Basis-Image. Bauen Sie das Image neu, auch wenn sich am Code nichts geändert hat, und rollen Sie es auf allen Umgebungen aus. Ein Blick ins Dockerfile zeigt, welches Basis-Image verwendet wird; ein fest gesetzter alter Tag verhindert sonst, dass der Neubau das gepatchte PHP überhaupt erhält. Einzelheiten stehen unter PHP in Docker-Containern patchen.
Wie hilft PHP SOS konkret?
- Wir stellen fest, welches PHP Web, CLI und Worker Ihres Symfony-Projekts nutzen, und begleiten den geordneten Neustart.
- Wir sichern Logs ab dem 20.10.2026 und gleichen den Code auf dem Server mit Ihrem Repository ab.
- Wir prüfen Umgebungsdateien, Secrets, Cache, Profiler-Einstellungen und Admin-Rollen.
- Für die laufende Beobachtung von Prozessen und Verbindungen bieten wir Security-Monitoring an.
Häufige Fragen
Ist Symfony von PHP2Shell betroffen?
Symfony selbst hat keine neue Lücke. PHP2Shell steckt in PHP, also in der Laufzeitumgebung jeder Symfony-Anwendung. Geschlossen wird die Lücke durch ein PHP-Update oder einen bestätigten Backport und den Neustart aller PHP-Prozesse.
Wie stoppe ich Messenger-Worker nach einem PHP-Update?
Mit php bin/console messenger:stop-workers werden laufende Worker angewiesen, sich nach der aktuellen Nachricht zu beenden. Ein Prozessmanager wie Supervisor oder systemd startet sie dann mit dem neuen PHP neu.
Warum ist der Symfony-Profiler in Produktion gefährlich?
Der Profiler zeigt Anfragen, Konfiguration und oft Umgebungsvariablen. Ist er auf einem öffentlichen Server aktiv, kann jeder diese Informationen abrufen. Er gehört nur in die Entwicklungsumgebung.
Was passiert mit dem Cache nach einem Angriff?
Der Cache unter var/cache enthält erzeugten PHP-Code. Ein Angreifer kann dort Code hinterlegen, der bei jeder Anfrage mitläuft. Nach einem Verdacht sollte der Cache gelöscht und aus dem geprüften Quellcode neu erzeugt werden.