php2shell: Was Ihr Unternehmen jetzt tun muss

Seit Mittwoch sind zwei kritische Sicherheitslücken in PHP offiziell bekannt – und die Lage ist ernst. Wie heise Security berichtet, sind sämtliche PHP-Versionen der letzten 20 Jahre betroffen. Die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619 (jeweils CVSS 9.2, kritisch) erlauben es Angreifern, aus der Ferne Code auf Servern auszuführen. Wer eine Website oder Webanwendung mit PHP betreibt – etwa auf WordPress-Basis –, muss jetzt prüfen lassen, ob die Updates eingespielt sind. Andernfalls droht die komplette Übernahme des Servers.

Warum diese Lücke kein Routinefall ist

Drei Punkte machen php2shell brisant:

Erstens die Verbreitung. PHP läuft seit zwei Jahrzehnten auf Webservern, und alle Versionen dieses Zeitraums sind verwundbar. Das betrifft nicht nur die Firmenwebsite, sondern auch Webanwendungen, NAS-Geräte mit Weboberfläche, Docker-Container und womöglich Mini-Server, die irgendwo im Netzwerk laufen.

Zweitens die niedrige Angriffshürde. Die Entdecker von Calif haben gezeigt, dass schon mit zehntausenden HTTP-Anfragen in 38 Sekunden Code auf dem angegriffenen Server ausführbar war – eine Anmeldung war dafür nicht nötig. Angreifer brauchen also keine Zugangsdaten und keine Vorarbeit im System.

Drittens die aktive Ausnutzung. Derzeit sind viele Exploit-Versuche zu beobachten; laut Reuters spricht Cloudflare von Millionen Angriffsversuchen. Viele Dienste haben ihre Webseiten deshalb vorübergehend vom Netz genommen und auf die Patches gewartet.

Für ein Unternehmen mit 10 bis 100 Mitarbeitern heißt das: Die Wahrscheinlichkeit, dass irgendwo in Ihrer Infrastruktur PHP läuft, ist hoch – und die Wahrscheinlichkeit, dass ungepatchte, aus dem Internet erreichbare Systeme bereits angegangen werden, ebenfalls.

Was ein erfolgreicher Angriff bedeutet

Wer aus der Ferne Code auf Ihrem Server ausführen kann, kontrolliert faktisch diesen Server. Die Meldung geht nicht im Detail darauf ein, was Angreifer im Einzelfall damit anstellen. Klar ist aber: Alles, was auf diesem System liegt oder darüber läuft – Website-Inhalte, Anwendungsdaten, dort gespeicherte Zugangsdaten –, ist dann nicht mehr unter Ihrer Kontrolle. Bei einem Webserver, der Kundenanfragen, Formulardaten oder Bestellungen verarbeitet, ist das kein abstraktes Risiko.

Was Sie jetzt konkret tun müssen

Die zentrale Botschaft der Meldung ist unmissverständlich: „Updates einzuspielen ist das einzig wirksame Mittel.“ Eine andere Möglichkeit, um umfänglich sicher vor den Angriffen zu sein, gibt es nicht. Je nachdem, wie Ihre Systeme betrieben werden, sieht das Vorgehen unterschiedlich aus:

Eigener Linux-Server (apt-basiert, z. B. Debian oder Ubuntu): Auf der Kommandozeile zuerst die Version prüfen und dann aktualisieren:

php -v
sudo apt update
sudo apt upgrade

Anschließend müssen sämtliche PHP-Dienste neu gestartet werden – ohne Neustart läuft der verwundbare Code weiter. Die gepatchten Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Aktualisierte Pakete liefern mittlerweile alle großen Distributionen aus, darunter Debian, Ubuntu, Fedora, Red Hat, SUSE, Gentoo und Slackware.

Windows und macOS: Die aktualisierten PHP-Versionen stehen direkt bei php.net zum Download bereit.

Gemanagte Dienste und Hosting: Hier sollte der Anbieter die Updates im Griff haben. Die Meldung empfiehlt ausdrücklich, trotzdem nachzufragen, um auf Nummer sicher zu gehen. Das gilt auch für Ihre Website-Agentur oder Ihren Hoster: Warten Sie nicht darauf, dass sich jemand meldet – fragen Sie aktiv, ob und wann gepatcht wurde.

Docker-Container: Anwendungen in Containern mit veralteten PHP-Versionen brauchen aktualisierte Images, etwa per:

docker compose pull && docker compose up -d

Wichtig: Ein Update des Host-Systems allein reicht hier nicht, wenn im Container selbst ein altes PHP steckt.

NAS-Geräte: Wer ein NAS von Anbietern wie QNAP oder Synology betreibt, kann über die Softwareverwaltung nach Updates suchen. Gerade NAS-Systeme werden oft vergessen, weil sie still vor sich hin laufen – sie haben aber eine webbasierte Oberfläche und gehören ausdrücklich zu den Geräten, auf denen die Updates eingespielt werden müssen.

Mini-Server und Raspberry Pi: Auch hier gilt laut Meldung: prüfen, ob die Geräte nicht doch irgendwo PHP benutzen. In kleinen Unternehmen laufen solche Systeme häufig für interne Werkzeuge oder Anzeigetafeln, ohne dass sie jemand auf dem Schirm hat.

Die Fragen, die die Meldung offenlässt

An zwei Stellen sollten Sie genau hinsehen, weil die verfügbaren Informationen dort nicht vollständig sind:

Was ist mit PHP-Versionen älter als 8.2? Betroffen sind alle Versionen der letzten 20 Jahre – aufgelistet werden als gefixte Versionen aber nur 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ob und wann für ältere Zweige wie PHP 7.x oder 8.0/8.1 ebenfalls Sicherheitsupdates erscheinen, geht aus der Meldung nicht hervor. Für Unternehmen, deren Anwendungen noch auf solchen Versionen laufen, ist das die entscheidende offene Frage. Hier sollten Sie mit Ihrem Dienstleister klären, ob ein Versionswechsel nötig wird – und was in der Zwischenzeit mit dem System passiert.

Woran erkennen Sie, ob Ihr Server bereits kompromittiert wurde? Die Lücken sind seit Mittwoch öffentlich, die Angriffe laufen nachweislich. Die Meldung enthält jedoch keine Hinweise zur Erkennung eines bereits erfolgten Einbruchs. Das heißt nicht, dass Sie nichts tun können – aber es heißt, dass das Einspielen des Patches allein nicht die Frage beantwortet, ob vorher schon jemand im System war. Auch das ist ein Punkt für die Rücksprache mit Ihrem IT-Dienstleister oder Hoster.

Wer ist bei Ihnen zuständig? In Unternehmen dieser Größe ist die Website oft bei einer Agentur, der Server bei einem Hoster, das NAS im eigenen Haus und die Fachanwendung beim Softwareanbieter. Die Meldung macht deutlich, dass alle diese Stellen betroffen sein können. Eine kurze Bestandsaufnahme – wo läuft bei uns überhaupt PHP? – ist der erste Schritt, bevor überhaupt gepatcht werden kann.

Einordnung: Jetzt zählt Geschwindigkeit, nicht Perfektion

Zwei Dinge sollten Sie aus dieser Meldung mitnehmen. Erstens: Es gibt keinen Workaround. Wer nicht patchen kann, hat nach dem Stand der Berichterstattung nur die Option, das System vom Netz zu nehmen – genau das haben zahlreiche Dienste auch getan. Zweitens: Die Reihenfolge zählt. Alles, was aus dem Internet erreichbar ist, hat Vorrang. Interne Systeme folgen danach, aber sie folgen.

Für Geschäftsführer, die selbst keine Server administrieren, lässt sich die Aufgabe auf einen Satz bringen: Stellen Sie heute sicher, dass jemand – intern oder extern – für jedes System mit PHP-Oberfläche bestätigt, dass die aktuelle Version installiert ist. Und lassen Sie sich die Antwort schriftlich geben. Bei einer Lücke, die ohne Anmeldung ausgenutzt werden kann und bereits millionenfach angegangen wird, ist „das wird schon jemand machen“ keine Strategie.

Dieser Artikel wurde KI-unterstützt auf Basis einer Fachmeldung erstellt und vor der Veröffentlichung geprüft.