software-wartung24.de
· 5 Min. Lesezeit· Sandor Farkas

PHP 5.6 läuft noch – Warum das kein Grund zur Entspannung ist

PHPSicherheitEnd of Life

PHP 5.6 noch in Betrieb: Das ist für viele Unternehmen keine bewusste Entscheidung. Es ist eine unterbliebene Entscheidung. Die Software lief, also wurde nichts geändert. Und sie läuft noch.

Das Problem ist klar. PHP 5.6 hat am 31. Dezember 2018 seinen offiziellen Support verloren. Das sind über sechs Jahre ohne Sicherheits-Updates, ohne Patches, ohne offizielle Unterstützung. Was sich in dieser Zeit an Risiken angesammelt hat, ist erheblich.

Dieser Artikel erklärt, was das konkret bedeutet, warum das Risiko mit jedem Monat wächst, und welche Optionen Sie haben.

Was "End of Life" bei PHP konkret bedeutet

PHP ist die Programmiersprache hinter Millionen von Websites. Viele Webanwendungen aus den 2000er und frühen 2010er Jahren laufen auf PHP-Basis. Joomla, WordPress und zahlreiche individuell entwickelte Anwendungen nutzen PHP im Kern.

Jede PHP-Version durchläuft drei Phasen: aktive Entwicklung, Sicherheitswartung und End of Life. In der letzten Phase gibt es nichts mehr. Kein Team schließt Lücken. Keine Organisation reagiert auf neue Angriffsmethoden.

Für PHP 5.6 ist diese Phase am 31. Dezember 2018 eingetreten.

Das bedeutet: Alle Sicherheitslücken, die seitdem entdeckt wurden, bleiben für PHP 5.6 dauerhaft offen. Sie werden dokumentiert. Behoben werden sie nicht.

PHP 5.6 noch in Betrieb: Wie gefährlich ist das wirklich?

Das kommt auf die Perspektive an.

Aus Ihrer Perspektive als Betreiber: Die Website läuft. Kein Alarm, kein Ausfall, kein sichtbares Problem.

Aus der Perspektive eines Angreifers: Ein System mit bekannten, öffentlich dokumentierten und nie gepatchten Sicherheitslücken. Ein bekanntes Ziel mit bekannten Schwachstellen.

Angreifer suchen nicht gezielt Ihr Unternehmen. Sie scannen automatisiert Millionen von Systemen auf bekannte Schwachstellen. Wer PHP 5.6 noch in Produktion betreibt, taucht in diesen Scans auf. Die Lücken sind bekannt. Die Werkzeuge dafür existieren seit Jahren.

CVEs seit 2018 ohne Patches

CVE steht für "Common Vulnerabilities and Exposures". Das ist eine öffentliche Datenbank für bekannte Sicherheitslücken. Für jede Lücke gibt es eine Nummer, eine Beschreibung und oft fertige Angriffswerkzeuge.

Seit Ende 2018 wurden für PHP 5.x zahlreiche CVEs veröffentlicht. Für aktuelle PHP-Versionen wurden diese Lücken behoben. Für PHP 5.6 nicht.

Das ist kein theoretisches Risiko. Es sind dokumentierte, offene Einfallstore, die in öffentlichen Datenbanken für jeden abrufbar sind.

Veraltete Abhängigkeiten multiplizieren das Problem

PHP selbst ist nur ein Teil des Systems. Dazu kommen Bibliotheken, Frameworks und externe Komponenten. Wer PHP 5.6 noch in Betrieb hat, betreibt in der Regel auch Abhängigkeiten, die ebenfalls seit Jahren keinen Support mehr erhalten.

Das sind technische Schulden in mehreren Schichten. Jede veraltete Abhängigkeit ist ein weiterer potenzieller Angriffsvektor. Das Risiko ist nicht additiv. Es ist multiplikativ.

DSGVO verlangt "Stand der Technik"

Die Datenschutz-Grundverordnung (DSGVO) verpflichtet Unternehmen dazu, personenbezogene Daten technisch angemessen zu schützen. "Angemessen" bedeutet in der Praxis: Stand der Technik.

PHP 5.6 ist nicht Stand der Technik. Das war sie schon 2019 nicht mehr.

Wer nach einem Datenschutzvorfall erklären muss, warum das System auf einer seit über sechs Jahren nicht mehr unterstützten PHP-Version lief, hat keine überzeugende Antwort. Bußgelder können erheblich sein, auch für kleine und mittlere Unternehmen. Das Risiko ist real und gut dokumentiert.

Kompatibilität wird zum Engpass

Aktuelle Plugins, neue Bibliotheken und moderne Dienste setzen PHP 7 oder PHP 8 voraus. Wer PHP 5.6 noch in Produktion hat, kann diese Komponenten nicht einsetzen.

Das schränkt die Weiterentwicklung systematisch ein. Jede neue Anforderung, jede Integration stößt früher oder später auf diese Grenze. Das System wird mit der Zeit schwerer zu betreiben, nicht leichter.

Was jetzt konkret zu tun ist

Wer PHP 5.6 noch in Betrieb hat, hat im Wesentlichen zwei Wege.

Schritt für Schritt auf PHP 8 upgraden

Von PHP 5.6 direkt auf PHP 8 zu springen ist selten sinnvoll. Zu viele Dinge haben sich in den Zwischenversionen geändert. Ein strukturierter Weg über PHP 7.4 als Zwischenschritt ist für die meisten Anwendungen realistischer.

Der erste Schritt ist immer eine Bestandsaufnahme: Welche PHP-Funktionen werden genutzt? Welche sind in neueren Versionen weggefallen? Welche externen Abhängigkeiten müssen ebenfalls aktualisiert werden?

Das kostet Zeit und Geld. Aber es ist planbar. Und es ist beherrschbar, wenn man früh anfängt.

Eine Testumgebung aufbauen, bevor etwas geändert wird

Kein Upgrade direkt in der Produktion. Eine identische Testumgebung wird zuerst aufgesetzt. Das Upgrade findet dort statt. Erst wenn alles stabil läuft, folgt der Wechsel in der Produktion.

Dieser Schritt klingt aufwändig. Er verhindert aber Ausfälle und ermöglicht eine geordnete Fehlersuche ohne Zeitdruck.

Ablösung wenn Upgrade wirtschaftlich keinen Sinn ergibt

Manche Anwendungen sind so alt und so undokumentiert, dass ein Upgrade mehr kostet als eine strukturierte Ablösung. In diesen Fällen ist ein neues System die bessere Wahl.

Das ist keine Niederlage. Alten Code zu verstehen, zu respektieren und ihn geordnet abzulösen ist Handwerk, das Erfahrung braucht. Den Unterschied zu erkennen, wann Upgrade sinnvoll ist und wann nicht, ist oft der schwierigste Schritt.

Mehr dazu, wie wir an solche Entscheidungen herangehen, finden Sie in unserem Überblick zur Software-Wartung.

Warum jeder weitere Monat das Risiko erhöht

Es gibt keine Schonfrist mehr für PHP 5.6. Die Lücken sind bekannt. Angreifer wissen, wo sie suchen müssen. Mit jeder neuen Lücke, die für PHP 8 gepatcht wird, aber für PHP 5.6 offen bleibt, wächst der Abstand.

"Es ist bisher nichts passiert" ist kein Beweis dafür, dass nichts passiert ist. Angriffe werden oft erst Wochen oder Monate nach dem Einbruch bemerkt. Manchmal gar nicht.

Das ist kein Grund zur Panik. Es ist ein Grund zur Entscheidung.

Fazit: PHP 5.6 noch in Betrieb ist lösbar

PHP 5.6 in Produktion zu betreiben ist kein technisches Detail. Es ist ein Geschäftsrisiko, das jeden Monat größer wird.

Die gute Nachricht: Es lässt sich lösen. Die meisten Systeme lassen sich upgraden, wenn man es strukturiert angeht. Und selbst wenn nicht: Es gibt Wege, die Risiken zu begrenzen und einen geordneten Übergang zu planen.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr System an, sagen Ihnen ehrlich was Sache ist, und zeigen Ihnen einen realistischen nächsten Schritt.

Weitere Artikel

· 6 Min. Lesezeit

Was passiert wenn der letzte Legacy-Entwickler das Unternehmen verlässt?

Entwickler gekündigt, Software läuft noch - aber wie lange? Wenn der einzige Mensch, der das System wirklich kennt, geht, beginnt eine stille Uhr zu ticken. Dieser Artikel zeigt, was Sie sofort tun können und wie Sie sich künftig absichern.

Team & EntwicklerLegacy GrundlagenWissenstransfer
· 7 Min. Lesezeit

Software modernisieren oder neu entwickeln? Eine ehrliche Entscheidungshilfe

Software modernisieren oder neu entwickeln: Viele Unternehmen stehen vor dieser Frage. Die Antwort hängt vom konkreten System ab, nicht von einer Faustregel. Dieser Artikel liefert einen strukturierten Entscheidungsrahmen ohne Verkaufsdruck.

ModernisierungLegacy GrundlagenKosten & Planung
· 7 Min. Lesezeit

Von PHP 5 auf PHP 8: Ein realistischer Upgrade-Fahrplan

PHP upgrade Kosten und Aufwand hängen stark vom Zustand Ihrer Anwendung ab. Dieser Artikel erklärt die typischen Schritte eines PHP-Upgrades, was den Aufwand bestimmt und was Sie realistisch einplanen sollten.

PHPPHP-UpgradeKosten & Planung

Bereit, Ihre Software in gute Hände zu geben?

Das Erstgespräch ist kostenlos und unverbindlich. Wir schauen uns an, was Sie haben, und sagen Ihnen ehrlich, was möglich ist.

Kostenlose Erstberatung anfragen →