AssistoPlus - Dein virtueller Helfer
Zurück zum BlogRatgeber

PHP2Shell: Ist meine Firmenwebseite betroffen?

Zwei kritische PHP-Lücken (CVE-2026-109618/-109619): So prüfen Sie in zwei Minuten, ob Ihre Seite betroffen ist, und was Sie Ihren Hoster fragen.

AssistoPlus Team22. Oktober 20265 Min. Lesezeit
PHP2Shell: Ist meine Firmenwebseite betroffen?

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen. In den Medien heißen sie „PHP2Shell“. Über diese Lücken kann ein Angreifer aus der Ferne Programme auf einem Webserver ausführen, ohne sich anzumelden. In Österreich haben Universitäten, Konzerne und Kammern ihre Seiten deshalb vorsorglich vom Netz genommen.

Wir schreiben darüber, weil wir es gerade selbst durchgemacht haben. Für Sie als Unternehmer zählen zwei Fragen: Bin ich betroffen? Und was mache ich jetzt?

Was passiert ist

Das PHP-Team hat am 21.10.2026 eine Sicherheitswarnung veröffentlicht. Es geht um zwei Lücken:

  • CVE-2026-109618: Wenn PHP während einer Anfrage der Speicher ausgeht, kann es mit halb fertigen Daten weiterarbeiten.
  • CVE-2026-109619: Interne Daten einer Anfrage können übrig bleiben, nachdem ihr Speicher schon freigegeben ist. Eine spätere Anfrage an denselben Server-Prozess kann diese Reste dann benutzen.
Das PHP-Team bewertet beide Lücken mit 9,2 von 10 Punkten (CVSS 4.0). Betroffen ist nach Angabe des PHP-Teams jede PHP-Installation, die Webanfragen beantwortet, also etwa PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Behoben sind die Lücken in diesen PHP-Fassungen:

  • 8.5.12
  • 8.4.27
  • 8.3.36
  • 8.2.35
Laut Medienberichten (oe24 und MeinBezirk, zusammengefasst von Trending Topics) waren in Österreich unter anderem diese Einrichtungen vorsorglich offline: die Universität Wien (Moodle, Webmail, u:cloud), die WU, die TU Wien, die BOKU, die MedUni Wien, die JKU Linz, voestalpine, Novomatic und der ÖAMTC. Der Kärntner Hoster Anexia hat laut demselben Bericht alle verwalteten PHP-Dienste um 15:45 Uhr abgeschaltet, also eine Viertelstunde, bevor das Update erschien.

Bin ich betroffen?

Entscheidend ist eine Frage: Läuft auf dem Server hinter Ihrer Webseite PHP?

Wahrscheinlich ja, wenn Ihre Seite mit einem dieser Systeme gebaut ist:

  • WordPress
  • Joomla
  • TYPO3
  • Drupal
  • Shopware oder ein anderer Onlineshop, der auf PHP läuft
  • ein Baukasten oder eine Agentur-Lösung, die auf PHP aufbaut
Nein, wenn Ihre Seite statisch ist. Eine statische Seite besteht aus fertigen Dateien, die der Server nur ausliefert. Kein Programm baut die Seite bei jedem Aufruf neu zusammen, also läuft dort auch kein PHP, das man angreifen könnte.

Prüfen in zwei Minuten

  1. Wissen Sie, womit Ihre Seite gebaut ist? Wenn Sie sich unter `ihre-seite.at/wp-admin` anmelden, ist es WordPress. Bei Joomla heißt die Anmeldeseite meist `/administrator`, bei TYPO3 `/typo3`.
  2. Schauen Sie auf die Adressen Ihrer Unterseiten. Endet eine Adresse auf `.php` oder steht `wp-content` im Quelltext der Seite (Rechtsklick → „Seitenquelltext anzeigen“), läuft PHP.
  3. Fragen Sie im Zweifel nach. Ein Satz an Ihre Webagentur oder Ihren Hoster genügt: „Läuft auf dem Server meiner Webseite PHP?“ Auf diese Antwort können Sie sich verlassen.

Schneller: unser kostenloser Sofort-Check

Diese beiden Punkte können Sie sich sparen — wir sehen von außen nach. Geben Sie Ihre Adresse auf unserer kostenlosen Seiten-Prüfung ein, und Sie bekommen in etwa zehn Sekunden eine Antwort. Ohne Anmeldung, ohne Kosten.

Was der Check kann: Er erkennt, ob auf Ihrem Server PHP läuft und mit welchem System Ihre Seite gebaut ist. Dazu sieht er sich an, ob Ihre Seite verschlüsselt ausgeliefert wird, ob sie bei Google und in KI-Antworten auffindbar ist und ob sie am Handy taugt.

Was er nicht kann: Er sieht nicht, ob die Lücke bei Ihnen offen steht. Das steht von außen nirgends geschrieben — dazu muss jemand auf den Server. Zeigt der Check PHP an, ist das also kein Alarm. Es heißt: Jetzt lohnt sich die Frage aus Schritt 3, und zwar heute.

Wenn Sie bei Punkt 1 und 2 nichts finden, ist das noch kein Beweis. Erst die Antwort aus Punkt 3 gibt Ihnen Gewissheit.

Nicht nur die Webseite

Denken Sie auch an andere Programme, die Ihr Betrieb im Browser benutzt und die auf einem eigenen oder gemieteten Server laufen: Webmail, Kundenportal, Buchungssystem, Rechnungsprogramm, CRM, eine eigene Cloud wie Nextcloud oder eine Lernplattform wie Moodle. Viele davon laufen auf PHP. Bei uns waren es genau solche Programme, nicht die Webseiten.

Was mache ich jetzt?

Die Reihenfolge ist wichtig.

1. Fragen Sie Ihren Hoster, ob er das Update eingespielt hat. Am besten schriftlich und mit den Nummern, dann gibt es keine Missverständnisse:

> „Ist PHP auf unserem Server gegen CVE-2026-109618 und CVE-2026-109619 abgesichert? Seit wann?“

Lassen Sie sich die Antwort mit Datum geben. Wer eine Agentur hat, die die Seite betreut, fragt die Agentur. Sie kennt den Server.

2. Lassen Sie sich nicht von der Versionsnummer täuschen. Viele Hoster betreiben Linux-Server und bekommen PHP über die Pakete der Linux-Distribution. Distributionen wie Ubuntu bauen die Korrektur in ihre eigene Fassung ein, ohne dass sich die angezeigte PHP-Nummer ändert. Bei Ubuntu steht das Update in der Sicherheitsmeldung USN-8948-1. Unser eigener Server zeigt nach dem Update weiterhin „PHP 8.3.6“ an und ist trotzdem abgesichert. Ob er geschützt ist, erkennt man nur an der Paketfassung, nicht an der Zahl 8.3.6. Deshalb ist die Frage an den Hoster aus Schritt 1 verlässlicher als ein Blick auf die Versionsnummer.

3. Fragen Sie bei sehr alten PHP-Fassungen besonders nach. Für PHP 8.1 und ältere Fassungen liefert das PHP-Projekt keine regulären Updates mehr. Ob Ihr Hoster die Korrektur trotzdem eingebaut hat oder ob ein Umstieg nötig ist, kann nur er beantworten.

4. Doktern Sie nicht selbst herum. Das PHP-Team nennt zwar Einstellungen, die einzelne Angriffswege erschweren. Es schreibt aber selbst, dass sie eine Installation nicht sicher machen und nur das Update das Problem löst. Wer ohne Erfahrung an der Server-Einstellung dreht, legt im schlimmsten Fall seine eigene Seite lahm. Das ist Arbeit für den Hoster.

5. Ein WordPress-Update allein genügt nicht. Die Lücken stecken in PHP selbst, nicht in WordPress, Joomla oder einem Plugin. Plugins aktuell zu halten bleibt richtig, dieses Problem löst es aber nicht.

6. Haken Sie die anderen Programme ab. Stellen Sie dieselbe Frage für jedes Programm aus der Liste oben, das auf einem Server läuft. Bei Programmen, die Sie als Dienst im Netz mieten, ist der Anbieter zuständig. Dort können Sie nichts selbst einspielen. Ein Blick auf seine Statusseite oder eine kurze Nachfrage genügt.

Wie es bei uns war

Wir haben unsere eigenen Systeme am 22.10.2026 nachgemessen:

  • Unser Server lief mit dem Ubuntu-Paket PHP 8.3.6-0ubuntu0.24.04.12. Die abgesicherte Fassung ist .13 aus USN-8948-1. Wir haben sie am Vormittag des 22.10. eingespielt.
  • Zwei Programme laufen bei uns in eigenen Containern mit eigenem PHP. Sie stehen jetzt auf PHP 8.4.27 und 8.2.35, also auf den abgesicherten Fassungen.
  • Die Webseiten unserer Kunden waren nicht betroffen. Sie sind alle statisch, und auf ihren Servern läuft kein PHP.
Für unsere Hosting-Kunden haben wir das erledigt. Wenn Ihre Seite woanders liegt, hilft Ihnen die Frage aus Schritt 1 weiter.

Wir sehen für Sie nach

Sie müssen das nicht allein herausfinden. Zwei Wege:

  1. Selbst prüfen, sofort: Kostenlose Seiten-Prüfung — Adresse eingeben, zehn Sekunden warten.
  2. Wir klären es für Sie: Tragen Sie dort unten Ihre Daten ein. Ein Mitarbeiter von uns sieht sich Ihre Seite an und sagt Ihnen, woran Sie sind. Das kostet Sie nichts, auch wenn Sie kein Kunde bei uns sind.
Finden wir etwas, das in Ordnung gebracht gehört, sagen wir Ihnen, was es wäre und was es kostet. Sie entscheiden dann.
Tags:#PHP2Shell#CVE-2026-109618#CVE-2026-109619#WordPressSicherheitslücke#Webseitebetroffen#PHPSicherheitslücke#AssistoPlusTeam

Bereit für Ihren persönlichen KI-Assistenten?

Starten Sie ab 9,90 €/Monat mit dem Assistenten Ihrer Wahl — monatlich kündbar, mit 30 Tage Geld-zurück-Garantie.

Zu den Tarifen