PHP-Sicherheit 2026: Die häufigsten Schwachstellen in Legacy-PHP-Projekten
PHP läuft auf einem großen Teil aller Websites weltweit. Shops, Portale, Intranets, Buchungssysteme. Viele davon sind zehn Jahre alt oder älter. Und genau dort liegt das Problem: PHP Sicherheit 2026 ist selten eine Frage neuer Angriffstechniken. Die meisten Einbrüche gelingen über Fehler, die seit 2005 bekannt sind.
Wenn Sie ein älteres PHP-Projekt betreiben, kennen Sie vermutlich die Situation. Die Anwendung läuft. Der Entwickler von damals ist nicht mehr da. Niemand hat den Code seit Jahren angefasst. Und niemand weiß genau, welche Lücken darin stecken.
Dieser Artikel zeigt die vier Schwachstellen, die wir in Legacy-PHP-Projekten am häufigsten finden. Er erklärt, wie sie entstehen und wie Sie sie schließen.
Warum alte PHP-Projekte so oft angegriffen werden
Angreifer suchen sich selten ein bestimmtes Unternehmen aus. Sie lassen Programme laufen, die das Internet nach bekannten Mustern absuchen. Eine alte PHP-Version, ein bestimmtes Plugin, eine typische URL-Struktur. Trifft ein Muster, folgt der automatisierte Angriff.
Alte PHP-Projekte sind dafür ein dankbares Ziel. Sie nutzen oft Sprachversionen ohne Support, etwa PHP 5.6 oder PHP 7. Sie enthalten Bibliotheken, deren Lücken öffentlich dokumentiert sind. Und sie wurden zu einer Zeit geschrieben, als viele heutige Schutzmechanismen noch nicht üblich waren.
Das ist kein Vorwurf an die damaligen Entwickler. Der Code war für seine Zeit oft solide. Die Angreifer haben sich weiterentwickelt, der Code nicht. Warum das ein generelles Problem ist, beschreibt unser Beitrag zum Sicherheitsrisiko alter Software.
Schwachstelle 1: SQL Injection
SQL Injection ist der Klassiker. Und er ist 2026 immer noch die Nummer eins in älteren PHP-Anwendungen.
Das Prinzip ist einfach. Ihre Anwendung baut eine Datenbankabfrage aus Text zusammen. Ein Teil dieses Textes kommt vom Benutzer, etwa aus einem Suchfeld. Prüft der Code diese Eingabe nicht, kann ein Angreifer eigene Datenbankbefehle einschleusen. Er liest dann Kundendaten aus, ändert Preise oder löscht Tabellen.
In Legacy-Code sieht das häufig so aus: Die alte Funktion mysql_query mit direkt eingefügten Variablen. Diese Funktion wurde mit PHP 7 entfernt. Viele Projekte haben sie aber nur durch mysqli ersetzt und den Rest gleich gelassen. Die Lücke ist damit nicht weg.
Der Schutz heißt Prepared Statements. Dabei trennt die Datenbank strikt zwischen Befehl und Daten. Eine Eingabe kann dann keinen Befehl mehr auslösen. In PHP geht das mit PDO oder mysqli. Der Umbau ist Fleißarbeit, aber keine Raketenwissenschaft. Wer die Abfragen einmal sauber durchgeht, hat das Thema erledigt.
Schwachstelle 2: File Inclusion
File Inclusion klingt harmlos. In der Praxis ist es oft der direkte Weg zur Übernahme des Servers.
PHP kann andere Dateien einbinden, etwa mit include oder require. Ältere Anwendungen bauen daraus manchmal ihre Navigation. Die URL enthält ?page=kontakt, der Code lädt kontakt.php. Kommt der Dateiname ungeprüft aus der URL, kann der Angreifer beliebige Dateien laden. Konfigurationsdateien mit Datenbankpasswörtern zum Beispiel. Oder eigene Skripte, die er vorher hochgeladen hat.
Wir sehen dieses Muster regelmäßig in Anwendungen aus den Jahren 2005 bis 2012. Damals war es eine verbreitete Technik. Heute gehört es zu den Lücken, die automatische Scanner als Erstes testen.
Die Lösung: Eine feste Liste erlaubter Seiten. Der Code prüft die Eingabe gegen diese Liste und lädt nur, was darin steht. Alles andere wird abgewiesen. Zusätzlich sollte die Einstellung allow_url_include in der PHP-Konfiguration ausgeschaltet sein. Bei aktuellen PHP-Versionen ist das der Standard, bei alten Servern oft nicht.
Schwachstelle 3: Unsichere Deserialisierung
Diese Lücke ist weniger bekannt, aber besonders gefährlich.
Serialisierung bedeutet: PHP wandelt ein Objekt in Text um. So lässt es sich in einer Session oder einem Cookie speichern. Deserialisierung ist der Rückweg. Die Funktion unserialize macht aus dem Text wieder ein Objekt.
Das Problem entsteht, wenn dieser Text vom Benutzer kommt. Ein Angreifer kann dann ein manipuliertes Objekt einschleusen. Beim Zurückverwandeln führt PHP automatisch bestimmte Methoden aus. Mit den richtigen Klassen im Projekt reicht das, um beliebigen Code auf dem Server zu starten. Sicherheitsforscher nennen die dafür nötigen Klassenketten "Gadget Chains". Für verbreitete Frameworks und Bibliotheken gibt es davon fertige Sammlungen.
Betroffen sind vor allem Anwendungen, die Objekte in Cookies ablegen. Ebenso solche, die Formulardaten mit unserialize verarbeiten. Auch ältere Versionen bekannter Bibliotheken enthielten solche Lücken.
Die Lösung ist konsequent: unserialize nie auf Daten anwenden, die von außen kommen. Für den Datenaustausch eignet sich JSON. Wo unserialize unvermeidbar ist, begrenzt der Parameter allowed_classes den Schaden.
Schwachstelle 4: Veraltete Bibliotheken und PHP-Versionen
Die vierte Schwachstelle steckt nicht im eigenen Code, sondern in dem, was man mitbenutzt.
Ein typisches PHP-Projekt zieht dutzende Bibliotheken mit sich. Ein PDF-Generator, eine Mail-Komponente, ein Bildbearbeitungs-Modul, ein Framework. Jede dieser Bibliotheken hat eigene Sicherheitslücken. Diese werden in der CVE-Datenbank veröffentlicht. CVE steht für "Common Vulnerabilities and Exposures", ein öffentliches Verzeichnis bekannter Schwachstellen.
Das Muster ist immer gleich. Die Lücke wird bekannt, der Hersteller liefert ein Update. Wer das Update einspielt, ist geschützt. Wer es nicht tut, betreibt ab diesem Tag eine dokumentierte Lücke. Angreifer lesen die CVE-Datenbank genauso wie Sicherheitsteams.
Bei Legacy-Projekten fehlt meistens ein Prozess dafür. Niemand prüft, ob die eingesetzten Bibliotheken noch gepflegt werden. Oft fehlt sogar eine Liste, welche Bibliotheken überhaupt im Einsatz sind. Dasselbe gilt für PHP selbst. Welche PHP-Lücken 2026 bekannt geworden sind, haben wir separat zusammengestellt. Für Versionen ohne Support kommen dafür keine Patches mehr.
Die Lösung besteht aus zwei Teilen. Erstens eine Inventur: Welche Bibliotheken laufen in welcher Version? Composer, das Paketwerkzeug für PHP, listet das auf. Zweitens ein laufendes CVE-Monitoring, das bei neuen Lücken Alarm schlägt. Der Befehl composer audit ist ein guter Anfang.
Was passiert, wenn Sie nichts tun
Meistens passiert lange nichts. Genau das macht es tückisch.
Ein gehacktes System meldet sich nicht. Angreifer, die Kundendaten abziehen, haben kein Interesse daran, aufzufallen. Viele Einbrüche werden erst Monate später entdeckt. Dann durch Dritte: Kunden, die seltsame Mails bekommen. Ein Zahlungsdienstleister, der Auffälligkeiten meldet. Oder ein Erpresserschreiben.
Dazu kommt die rechtliche Seite. Die DSGVO verlangt Schutz nach dem Stand der Technik. Ein PHP 5.6 mit bekannter SQL-Injection-Lücke ist das nicht. Nach einem Vorfall müssen Sie die Aufsichtsbehörde informieren und erklären, warum das System so lief. Diese Erklärung fällt schwer.
Und dann sind da die Kosten. Ein Vorfall kostet fast immer mehr als die Prüfung davor. Forensik, Wiederherstellung, Anwälte, Kundenkommunikation, Ausfallzeit. Das sind Schulden, die sich über Jahre angesammelt haben und auf einmal fällig werden.
Wie Sie Ihr PHP-Projekt jetzt absichern
Sie müssen nicht alles auf einmal erledigen. Für PHP Sicherheit 2026 hilft eine sinnvolle Reihenfolge.
Schritt 1: Bestandsaufnahme
Welche PHP-Version läuft? Welche Bibliotheken sind im Einsatz? Welche Bereiche der Anwendung nehmen Benutzereingaben entgegen? Diese Fragen beantwortet eine Analyse in wenigen Tagen. Ohne diese Grundlage arbeiten Sie im Blindflug.
Schritt 2: Die offensichtlichen Lücken schließen
Datenbankabfragen auf Prepared Statements umstellen. Datei-Einbindungen gegen eine feste Liste prüfen. Alle Stellen mit unserialize durchgehen. Das beseitigt schon einen großen Teil des Risikos. Meist ohne die Anwendung grundlegend umzubauen.
Schritt 3: Aktualisieren
Bibliotheken auf gepflegte Versionen heben. Dann die PHP-Version. Ein PHP-Upgrade auf eine unterstützte Version bringt Patches und strengere Standardeinstellungen mit. Viele alte Angriffsmuster laufen auf PHP 8 ins Leere.
Schritt 4: Dranbleiben
Einmal aufräumen reicht nicht. Neue Lücken werden wöchentlich bekannt. Ein fester Prozess für Updates und ein automatisches CVE-Monitoring halten das System auf Stand. Genau das ist der Kern einer laufenden Software-Wartung.
Fazit: Alte Fehler, bekannte Lösungen
PHP Sicherheit 2026 heißt für die meisten Unternehmen: vier bekannte Schwachstellen finden und schließen. SQL Injection, File Inclusion, unsichere Deserialisierung und veraltete Bibliotheken. Für alle vier gibt es erprobte Lösungen, die seit Jahren funktionieren.
Der schwierige Teil ist der Anfang. Jemand muss sich den alten Code ansehen und ehrlich aufschreiben, was drin steckt.
Wir machen das regelmäßig. Ohne Spott über alten Code und mit einer klaren Liste, was zuerst dran ist. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
