Aktuelle Lage: PHP2Shell. Zwei kritische PHP-Lücken (CVSS 9.2) erlauben Schadcode ohne Anmeldung. Patches seit 21.10.2026.Was jetzt zu tun ist →

PHP-Frameworks im Überblick

Frameworks geben PHP-Anwendungen Struktur, Routing und Sicherheitsbausteine. Dieser Überblick zeigt die bekannten Frameworks, Auswahlkriterien und die Grenzen ihres Schutzes.

Stand 4 Min. LesezeitPHP-Wissen

Kurz gesagt: Ein PHP-Framework ist ein Grundgerüst aus wiederverwendbarem Code, das typische Aufgaben einer Webanwendung bereits löst: Anfragen an den richtigen Code weiterleiten, Daten aus Formularen verarbeiten, Datenbanken ansprechen, Ausgaben erzeugen. Bekannte PHP-Frameworks sind Laravel, Symfony, Laminas, CodeIgniter, Yii, CakePHP und Slim. Ein Framework bringt Sicherheitsbausteine mit, schützt aber nicht vor Lücken im PHP-Interpreter wie PHP2Shell.

Was ist ein PHP-Framework?

Ohne Framework schreibt jedes Team Routing, Formularprüfung, Sitzungen und Fehlerbehandlung neu. Ein Framework gibt dafür feste Bausteine und Konventionen vor. Das spart Zeit, macht Code für neue Entwickler lesbar und bündelt Sicherheitsfunktionen an einer Stelle, statt sie über Hunderte Dateien zu verteilen.

Für die Geschäftsführung ist vor allem eine Folge wichtig: Mit der Wahl eines Frameworks binden Sie sich für Jahre an dessen Release-Zyklus. Wenn das Framework eine PHP-Version nicht mehr unterstützt oder selbst nicht mehr gepflegt wird, wird jedes Update teurer.

Die meisten modernen Frameworks werden über Composer installiert und halten sich an Standards der PHP-FIG, etwa PSR-4 für das Autoloading oder PSR-7 für HTTP-Nachrichten.

Die bekannten PHP-Frameworks im Vergleich

Die folgende Übersicht nutzt die Selbstbeschreibungen der Projekte auf ihren Startseiten. Bewertungen nach Beliebtheit oder Marktanteil lassen wir bewusst weg, weil es dafür keine verlässliche gemeinsame Quelle gibt.

Framework Selbstbeschreibung (sinngemäß) Typischer Einsatz
Laravel Framework mit „Batterien inklusive“ für Webanwendungen Eigenentwicklungen, Portale, SaaS
Symfony leistungsfähiges Framework mit wiederverwendbaren Komponenten große, langlebige Anwendungen; Komponenten in anderen Projekten
Laminas gemeinschaftlich gepflegte Fortführung des Zend Framework Unternehmensanwendungen, Middleware
CodeIgniter kleines Framework mit starken Funktionen kleinere Anwendungen, geringe Einstiegshürde
Yii Framework für schnelle Entwicklung moderner Anwendungen Webanwendungen, Grundlage einzelner CMS
CakePHP Framework mit klaren MVC-Konventionen klassische Datenbankanwendungen
Slim Micro-Framework für Webanwendungen und APIs schlanke APIs, Middleware-Dienste

Symfony nennt auf seiner Startseite Drupal, Laravel, API Platform und Composer als Projekte, die Symfony-Komponenten nutzen. Ein Framework steckt also oft auch dort, wo man es nicht direkt sieht. Wie das bei CMS und Shops aussieht, zeigt die Seite CMS und Shopsysteme auf PHP.

Gemeinsame Bausteine fast aller Frameworks

Trotz unterschiedlicher Philosophie teilen die meisten Frameworks einen Aufbau. Alle Anfragen laufen über einen einzigen Einstiegspunkt, den Front-Controller, meist public/index.php. Der Webserver reicht dafür jede Adresse, zu der es keine echte Datei gibt, an diese Datei weiter.

# Beispiel: Nginx leitet unbekannte Pfade an den Front-Controller
root /var/www/app/public;

location / {
    try_files $uri /index.php$is_args$args;
}

Bei Apache übernimmt diese Aufgabe meist eine Umschreiberegel im öffentlichen Ordner, bei anderen Webservern eine vergleichbare Regel. Wichtig ist in allen Fällen, dass der Webserver auf den Ordner public zeigt und nicht auf das Hauptverzeichnis des Projekts. Ein falsch gesetztes Dokumentverzeichnis gehört zu den häufigsten Ursachen dafür, dass Konfigurationsdateien plötzlich öffentlich abrufbar sind.

Der Vorteil für die Sicherheit: Nur der Ordner public liegt im Webroot. Konfiguration, Quellcode und vendor liegen eine Ebene darüber und sind per URL nicht erreichbar. Danach übernimmt der Router die Zuordnung zu einem Controller, Middleware prüft Anmeldung oder CSRF-Token, und eine Template-Engine erzeugt die Ausgabe mit automatischer Maskierung.

Wie wählt man ein Framework aus?

Für eine Neuentwicklung oder die Übernahme eines Bestandsprojekts helfen diese Fragen:

  1. Pflege und Release-Zyklus: Wie lange werden Versionen mit Sicherheitsupdates versorgt, und gibt es Versionen mit verlängerter Unterstützung?
  2. PHP-Unterstützung: Läuft die eingesetzte Framework-Version auf einer PHP-Version, die selbst noch Sicherheitsupdates erhält? Das steht in den Anforderungen des Projekts.
  3. Team und Dienstleister: Kennt das Team das Framework, und finden Sie im Notfall Fachleute dafür?
  4. Ökosystem: Gibt es gepflegte Pakete für Ihre Anforderungen, oder müsste viel selbst gebaut werden?
  5. Standards: Hält sich das Framework an PSR-Schnittstellen, lassen sich Bausteine später leichter austauschen.

Für Laravel- und Symfony-Projekte haben wir eigene Seiten zur Absicherung: Laravel-Anwendungen absichern und Symfony-Anwendungen absichern.

Was ein Framework für die Sicherheit leistet und was nicht

Frameworks nehmen Entwicklern viele Fehlerquellen ab: vorbereitete Datenbankabfragen gegen SQL-Injection, automatische Maskierung gegen Cross-Site-Scripting, CSRF-Schutz für Formulare, sichere Passwort-Hashes. Das funktioniert aber nur, wenn das Team diese Bausteine nutzt und nicht umgeht.

Gegen PHP2Shell hilft das alles nicht. CVE-2026-109618 und CVE-2026-109619 liegen im PHP-Interpreter. Das PHP-Team stuft das Risiko bei mod_php am höchsten ein; dort wurde ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Das Framework kommt also gar nicht zum Zug. Abhilfe schafft nur das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und der Neustart aller PHP-Prozesse.

Wichtig

Ein Framework-Update und ein PHP-Update sind zwei getrennte Aufgaben. Beide gehören in die Wartung, aber nur das PHP-Update schließt PHP2Shell.

Bei älteren Projekten kommt ein weiteres Risiko hinzu: Hängt eine Anwendung an einer alten Framework-Version, hängt sie oft auch an einer alten PHP-Version. Für PHP 8.1 und älter gibt es vom PHP-Projekt keine offiziellen Updates mehr.

Wie hilft PHP SOS konkret?

  • Wir ermitteln Framework, Version und PHP-Anforderungen Ihrer Anwendung und stellen fest, ob beide noch Sicherheitsupdates erhalten.
  • Wir prüfen den Aufbau: Liegt nur public im Webroot, sind Konfiguration und vendor geschützt?
  • Wir planen Framework- und PHP-Updates getrennt, testen sie und spielen sie mit Neustart aller Worker ein.
  • Für Eigenentwicklungen bieten wir einen Sicherheitsaudit und Penetrationstest an, der die Nutzung der Framework-Schutzfunktionen gezielt prüft.

Häufige Fragen

Welches PHP-Framework ist das beste?

Das hängt vom Projekt ab. Entscheidend sind Größe und Lebensdauer der Anwendung, das Know-how im Team, die Pflege durch das Projekt und die Unterstützung aktueller PHP-Versionen. Ein gut gepflegtes, im Team bekanntes Framework ist meist die bessere Wahl als das gerade beliebteste.

Schützt ein Framework vor PHP2Shell?

Nein. PHP2Shell liegt im PHP-Interpreter, und laut PHP-Team wurde bei mod_php ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Kein Framework-Update ersetzt das Update der PHP-Laufzeit und den Neustart aller Worker.

Was ist ein Micro-Framework?

Ein Micro-Framework liefert nur den Kern, typischerweise Routing, Middleware und Anfrage-Antwort-Objekte. Datenbankzugriff, Templates oder Formulare wählt man selbst dazu. Slim bezeichnet sich zum Beispiel selbst als Micro-Framework für PHP.

Was bedeutet es, wenn ein CMS Symfony-Komponenten nutzt?

Es verwendet einzelne Bausteine von Symfony, etwa für HTTP-Verarbeitung oder Konsole, ohne das ganze Framework zu übernehmen. Sicherheitsmeldungen zu diesen Komponenten betreffen dann auch das CMS, was bei der Update-Planung zählt.

Quellen

Sofort-Kontakt

Jede Stunde zählt. Schreiben Sie uns jetzt.

Schildern Sie kurz System, PHP-Version und Beobachtung. Wir melden uns, klären die Lage und arbeiten remote, bis der Vorfall abgeschlossen und dokumentiert ist.

Sofort-Hilfe