Kritische PHP-Sicherheitslücken: Ist Ihre Website betroffen – und was ist jetzt zu tun?

Am 21. Oktober 2026 hat das PHP Security Team Updates für zwei kritische Schwachstellen in PHP selbst veröffentlicht: CVE-2026-109618 und CVE-2026-109619. Beide sind nach CVSS v4.0 mit 9,2 bewertet und können es Angreifern ermöglichen, ohne Anmeldung Code auf dem Server auszuführen. Behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat eindringlich zum Handeln aufgerufen.

Läuft Ihre Website mit PHP – also etwa mit WordPress, TYPO3, Shopware, JTL-Shop oder Contao –, ist der erste Schritt einfach: Finden Sie heraus, welche PHP-Version im Einsatz ist, und lassen Sie sich bestätigen, dass sie diese Korrekturen enthält. Wie das geht, zeigt Ihnen dieser Leitfaden – für Shared Hosting ebenso wie für den eigenen Server.

Wenn Sie bei einer dieser Fragen „weiß nicht“ antworten, lesen Sie weiter. Jeder der folgenden Abschnitte schließt genau eine dieser Lücken.

Was steckt hinter CVE-2026-109618 und CVE-2026-109619?

Es handelt sich um zwei voneinander unabhängige Fehler in der Speicherverwaltung der PHP-Engine. Unter bestimmten Bedingungen können sie es einem nicht authentifizierten Angreifer erlauben, eigenen Code auf dem Server auszuführen. Das PHP Security Team kündigte die Updates am 20. Oktober an und veröffentlichte sie am 21. Oktober 2026 um 14:00 Uhr UTC (16:00 Uhr MESZ). In Fachmedien kursiert für die beiden Lücken auch der Name „PHP2Shell“.

Drei Begriffe zur Einordnung: Eine CVE ist die öffentliche Kennnummer einer bestimmten Schwachstelle. CVSS bewertet den Schweregrad von 0 bis 10; ab 9,0 gilt eine Lücke als kritisch. Remote Code Execution (RCE) bedeutet, dass ein Angreifer aus der Ferne eigenen Code auf Ihrem Server ausführen kann.

Wie gefährlich ist das für Ihre Website?

Gefährlich genug, um heute zu handeln. Laut PHP Security Team ist jede PHP-Installation betroffen, die Webanfragen verarbeitet – darunter PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei mod_php: Dort wurde ein Angriff demonstriert, bei dem eine einzige Anfrage ohne Anmeldung den Angriff auslöst, noch bevor der Anwendungscode überhaupt startet.

Gelingt ein Angriff, sind unter anderem folgende Folgen möglich:

• Ausführung von fremdem Code auf dem Server
• Manipulation von Website-Dateien oder Einschleusen schädlicher Inhalte
• Hintertüren (Backdoors) oder Schadsoftware für spätere Angriffe
• Zugriff auf Kunden-, Bestell- oder Kontaktdaten in Ihrer Datenbank
• Ausfälle, Performance-Probleme oder Warnhinweise in Suchmaschinen

Werden die Lücken bereits ausgenutzt?

Der Stand am 23. Oktober 2026: Das BSI hat eindringlich gewarnt und rechnet mit Angriffswellen auf Webserver; BSI-Vizepräsident Thomas Caspers sprach von „unverzüglichem Handlungsbedarf“. Inzwischen sind mehrere öffentliche Proof-of-Concept-Exploits verfügbar. Nach Analyse von Rapid7 funktioniert jeder davon allerdings nur mit einer bestimmten Kombination aus Betriebssystem, PHP-Version und Webserver. Rapid7 rechnet mit einer Ausnutzung „in freier Wildbahn“, kam in eigenen Tests bisher aber nur unter engen Laborbedingungen zu einem funktionierenden Exploit; das kanadische Cyber Centre hat noch keine aktive Ausnutzung festgestellt und betont, dass sich dies schnell ändern kann. Kurz gesagt: Warten Sie nicht auf Meldungen über Masseneinbrüche.

Das heißt nicht, dass jede PHP-Website bereits kompromittiert ist. Ob ein Angriff gelingt, hängt von PHP-Version, Serverkonfiguration und Patch-Stand ab.

Welche PHP-Versionen sind betroffen?

Alle vier offiziell unterstützten PHP-Zweige waren betroffen, und für jeden gibt es ein korrigiertes Release. Ihre Website sollte auf einer dieser Versionen laufen – oder auf einem Paket Ihres Hosters, das dieselben Korrekturen enthält.

PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine Updates mehr. Wegen der Schwere der Lücken hat das Security Team für PHP 7.4, 8.0 und 8.1 minimale Quellcode-Backports bereitgestellt – gedacht für alle, die PHP selbst kompilieren. Viele Linux-Distributionen und LTS-Anbieter liefern eigene gepatchte Pakete aus. Diese Patches schließen nur die beiden genannten Lücken; die alten Zweige werden dadurch nicht wieder offiziell unterstützt.

Achtung, Stolperfalle: Portiert eine Distribution den Fix zurück, bleibt die Versionsnummer häufig gleich. Ein Server kann also „8.3.x“ anzeigen und trotzdem gepatcht sein – oder eben nicht. Maßgeblich sind das Changelog des Pakets oder die Mitteilung Ihres Hosters.

Denken Sie auch an mitgeliefertes PHP: Docker-Images, Appliances und manche kommerziellen Produkte bringen ihre eigene PHP-Version mit. Ein Update des Host-Systems aktualisiert kein Container-Image – dieses muss auf Basis eines aktuellen Images neu gebaut und ausgerollt werden.

Nachtrag vom 23. Oktober: Session Upload Progress

Am 23. Oktober 2026 hat das PHP Security Team einen zusätzlichen Hinweis veröffentlicht: Bis zum nächsten regulären Bugfix-Release wird session.upload_progress.enabled=0 empfohlen. Die Einstellung war bereits als Gegenmaßnahme zu CVE-2026-109619 genannt; haben Sie sie damals gesetzt, lassen Sie sie einfach aktiv. Das neue Problem (CVE-2026-115560) tritt nur bei einer ungewöhnlichen Kombination aus Konfiguration und Anwendungscode auf und wird daher im regulären Release-Zyklus behoben.

WordPress, TYPO3, Shopware, JTL-Shop: Bin ich betroffen?

Nicht wegen eines Fehlers im CMS oder Shopsystem – wohl aber dann, wenn die PHP-Laufzeit darunter noch nicht gepatcht ist. Ein Update von WordPress, TYPO3-Extensions, Shopware-Plugins oder JTL-Shop schließt diese Lücke nicht.

Stellen Sie sich PHP als Fundament eines Hauses vor und Ihr CMS als alles, was darauf gebaut ist. Ein neuer Anstrich im Obergeschoss repariert keinen Riss im Fundament. Deshalb gibt es zwei getrennte Aufgabenlisten:

Gerade bei Shopsystemen wie Shopware oder JTL-Shop gilt: Prüfen Sie vor einem Zweigwechsel die vom Hersteller unterstützten PHP-Versionen. Ein Sicherheitsupdate innerhalb desselben Zweigs ist davon in der Regel nicht betroffen.

So prüfen Sie Ihre PHP-Version

Am schnellsten geht es über das Control Panel Ihres Hosters oder das Backend Ihres CMS. Menübezeichnungen können je nach Anbieter und Version leicht abweichen.

• cPanel: Im Bereich Software zeigt der MultiPHP Manager (oder Select PHP Version) den PHP-Zweig je Domain.
• Plesk: Unter Websites & Domains finden Sie bei der jeweiligen Domain die PHP-Einstellungen mit Version und PHP-Handler (FPM, CGI usw.).
• WordPress: Werkzeuge → Website-Zustand → Bericht → Server. Der Website-Zustand warnt zudem bei veralteten PHP-Versionen.
• TYPO3: Im Backend unter System → Umgebung (Environment) bzw. in der Systeminformation der Toolbar.
• Kommandozeile: php -v, für FPM php-fpm -v (je nach Distribution z. B. php-fpm8.3 -v). CLI und Webserver können unterschiedliche PHP-Binaries nutzen – prüfen Sie beide.

PHP-Version aktualisieren: Schritt für Schritt mit Abbildungen

Im Shared Hosting lässt sich die PHP-Version meist mit wenigen Klicks umstellen: in cPanel über den MultiPHP Manager, in Plesk über die PHP-Einstellungen der Domain. Vorher sollten Sie zwei Dinge auseinanderhalten, die oft verwechselt werden:

• Sicherheitsupdate innerhalb eines Zweigs (z. B. 8.3.35 → 8.3.36): Genau das schließt diese Lücken. Im Shared und Managed Hosting erledigt das der Hoster auf dem Server; Sie müssen dafür in der Regel nichts auswählen.
• Wechsel des Zweigs (z. B. 8.1 → 8.3): So verlassen Sie eine nicht mehr unterstützte Version. Den Zweig wählen Sie im Panel selbst; ein kurzer Kompatibilitätstest gehört dazu.

Welchen Zweig sollten Sie wählen? Den neuesten offiziell unterstützten, den Ihr Hoster anbietet. Stand 23. Oktober 2026 sind das 8.2, 8.3, 8.4 und 8.5. Da der Support für PHP 8.2 am 31. Dezember 2026 enden wird, verschafft Ihnen 8.3 oder höher mehr Zeit. Kommen Sie von 8.1 oder älter, müssen Sie nicht jeden Zwischenzweig einzeln durchlaufen – entscheidend ist, dass Plugins, Extensions und Theme die Zielversion unterstützen.

Vorbereitung: drei kurze Checks

1. Backup erstellen. Sichern Sie Dateien und Datenbank gemeinsam – über das Backup-Tool im Panel oder ein Backup-Plugin.
2. Kompatibilität prüfen. Achten Sie bei Plugins und Extensions auf die angegebene Mindest-PHP-Version und das Datum des letzten Updates. Seit Jahren nicht gepflegte Erweiterungen sind die häufigste Fehlerquelle.
3. Erst das CMS aktualisieren. Bringen Sie Core, Theme und Erweiterungen auf den neuesten Stand, bevor Sie den Zweig wechseln. Wenn möglich, testen Sie den Wechsel zuerst auf einer Staging-Kopie.

PHP-Version in cPanel ändern

1. Melden Sie sich bei cPanel an und öffnen Sie im Bereich Software den MultiPHP Manager.
2. Setzen Sie das Häkchen bei der Domain, die umgestellt werden soll (1).
3. Wählen Sie im Auswahlmenü die Zielversion, z. B. PHP 8.3 (2).
4. Klicken Sie auf Anwenden (3). Die Änderung ist meist nach wenigen Sekunden aktiv.

Auf manchen Servern finden Sie stattdessen Select PHP Version (den PHP Selector von CloudLinux). Das Prinzip ist dasselbe: Version wählen, speichern. Dort werden PHP-Erweiterungen pro Version verwaltet – prüfen Sie nach dem Wechsel also, ob die von Ihrer Website benötigten Extensions (etwa intl, imagick oder zip) auch in der neuen Version aktiv sind.

PHP-Version in Plesk ändern

1. Öffnen Sie Websites & Domains, suchen Sie Ihre Domain und klicken Sie auf PHP bzw. PHP-Einstellungen (1).
2. Wählen Sie unter PHP-Version das Ziel-Release (2). Den PHP-Handler (FPM, CGI usw.) ändern Sie nur, wenn es dafür einen konkreten Grund gibt.
3. Speichern Sie mit Anwenden bzw. OK (3).

Neue Version in WordPress bestätigen

Prüfen Sie, ob die Umstellung tatsächlich auf der Website angekommen ist. Nutzen Sie ein Caching-Plugin, leeren Sie zuerst den Cache.

1. Öffnen Sie im Dashboard Werkzeuge → Website-Zustand (1).
2. Wechseln Sie zum Reiter Bericht (2).
3. Klappen Sie Server auf und lesen Sie die Zeile PHP-Version ab (3). Im Zweig 8.3 enthält 8.3.36 oder höher den Fix vom 21. Oktober.

Für Betreiber eines eigenen VPS oder Servers

Auf dem eigenen Server aktualisieren Sie PHP über den Paketmanager des Betriebssystems. Die folgenden Befehle sind Beispiele; Paketnamen hängen von Distribution und verwendetem PHP-Repository ab.

# Aktuelle Version anzeigen (CLI)
php -v

# Debian / Ubuntu – Sicherheitsupdate innerhalb des Zweigs
sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade "php*"
sudo systemctl restart php-fpm

# Bei Apache mod_php zusätzlich den Webserver neu starten
sudo systemctl restart apache2   # auf RHEL-basierten Systemen: httpd

Lassen Sie den Neustart nicht aus: Laufen alte PHP-Worker im Speicher weiter, ist der Patch nicht aktiv. Ob Ihr Repository die Korrekturen vom 21. Oktober wirklich enthält, zeigt das Changelog des Pakets (unter Debian/Ubuntu z. B. apt changelog php8.3-fpm). Für einen Zweigwechsel installieren Sie den neuen Zweig parallel und stellen Webserver bzw. FPM-Pool darauf um; die Details unterscheiden sich je nach Distribution.

Wenn etwas schiefgeht: sauber wiederherstellen

Eine weiße Seite oder ein „500 Internal Server Error“ nach dem Update lässt sich beheben. Der erste Reflex sollte aber nicht sein, zur alten PHP-Version zurückzukehren: Ist diese nicht gegen die Lücken gepatcht, öffnen Sie die Tür wieder. Gehen Sie stattdessen so vor:

1. Ursache finden. Das PHP-Fehlerprotokoll oder die WordPress-Datei debug.log nennt meist schon in den ersten Zeilen das fehlerhafte Plugin oder Theme.
2. Verursacher deaktivieren. Kein Zugang zum Backend? Benennen Sie im Dateimanager den Ordner des Plugins um (z. B. plugin-name → plugin-name-aus) – WordPress lädt es dann nicht mehr.
3. Aktualisieren oder ersetzen. Installieren Sie die neueste Version des Herstellers oder wechseln Sie zu einer Alternative, die die neue PHP-Version unterstützt.
4. Bei größeren Schäden aus dem Backup zurückspielen. Stellen Sie das vor dem Update erstellte Backup wieder her – behalten Sie aber die neue PHP-Version und lösen Sie das Problem auf einer Staging-Kopie.

Ihr Maßnahmenplan: Website Schritt für Schritt absichern

Die einzige vollständige Lösung ist ein Update auf ein korrigiertes Release. Das PHP Security Team stellt klar, dass Übergangsmaßnahmen eine Installation nicht sicher machen. Diese Reihenfolge senkt das Risiko schnell, ohne Ihre Website unnötig zu gefährden:

1. PHP-Version ermitteln – Zweig und, wenn möglich, genaues Release.
2. Mitteilung des Hosters prüfen – Statusseite, E-Mail oder Support.
3. Fix bestätigen lassen – 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 oder höher bzw. schriftliche Bestätigung eines gepatchten Pakets.
4. Aktuelles Backup erstellen und Wiederherstellung testen.
5. Kurzen Kompatibilitätstest durchführen – beim Zweigwechsel Pflicht, beim Sicherheitsupdate im selben Zweig meist entbehrlich.
6. Update kontrolliert einspielen – zu einer ruhigen Uhrzeit, mit Neustart von PHP-FPM bzw. Webserver.
7. Website testen – mit der Checkliste unten.
8. Nach Spuren eines Angriffs suchen – kürzlich geänderte Dateien, neue Admin-Konten, auffällige Anfragen in den Zugriffsprotokollen, unerwartete ausgehende Verbindungen.

Ein Sicherheitsupdate innerhalb desselben Zweigs braucht keine wochenlangen Tests. Kompatibilitätsprüfungen dürfen kein Grund sein, einen kritischen Patch tagelang liegen zu lassen.

Übergangsmaßnahmen für Serveradministratoren

Wer einen eigenen Server betreibt und wirklich einige Stunden warten muss, findet beim PHP Security Team Maßnahmen, die bestimmte Angriffswege einschränken. Sie machen die Installation nicht sicher und ersetzen das Update nicht:

• Für CVE-2026-109619: session.upload_progress.enabled=0 an einer Stelle setzen, die Anwendungen nicht überschreiben können (php.ini, FPM-Pool oder Serverkonfiguration), und alle Worker neu starten. Auf ini_set() oder .user.ini ist kein Verlass. Unter PHP 8.5 blockiert zusätzlich fatal_error_backtraces=0 einen bestätigten Angriffsweg.
• Für CVE-2026-109618: post_max_size senken (8M ohne, 32M mit Datei-Uploads) und upload_max_filesize darunter halten. Limits für Anfragegröße, Feld- und Header-Anzahl am Webserver oder Proxy erzwingen.
• Fehler per display_errors oder @ zu verbergen, hilft nicht. Von außen auslösbare Fatal Errors und Timeouts müssen behoben werden.

Checkliste nach dem Update

Verdacht auf Kompromittierung: Was nun?

Ein Patch schließt die Tür – wer schon drin ist, bleibt aber drin. Stoßen Sie auf unbekannte Dateien, fremde Admin-Konten, Spam-Seiten oder Weiterleitungen, behandeln Sie das als Sicherheitsvorfall:

• Sichern Sie Logs und erstellen Sie einen Snapshot, bevor Sie etwas verändern – Sie brauchen diese Daten zur Aufklärung.
• Ändern Sie alle Passwörter (Hosting-Panel, Datenbank, CMS-Admins, SFTP) und tauschen Sie auf dem Server gespeicherte API-Schlüssel und Secrets aus.
• Spielen Sie ein sauberes Backup aus der Zeit vor dem Vorfall ein und patchen Sie PHP, bevor die Website wieder online geht.
• Könnten personenbezogene Daten betroffen sein, prüfen Sie Ihre Pflichten nach der DSGVO: Eine meldepflichtige Datenschutzverletzung ist nach Art. 33 grundsätzlich innerhalb von 72 Stunden an die zuständige Aufsichtsbehörde zu melden; bei hohem Risiko sind nach Art. 34 auch die Betroffenen zu informieren. Ziehen Sie im Zweifel Ihre Datenschutzbeauftragte bzw. Ihren Datenschutzbeauftragten hinzu.

Wer ist zuständig: Hoster oder Sie?

Kurz gesagt: Im Shared und Managed Hosting patcht in der Regel der Hoster PHP; beim nicht verwalteten VPS oder Dedicated Server liegt das bei Ihnen. CMS, Plugins und Inhalte bleiben in jedem Modell weitgehend Ihre Aufgabe.

Das ist die übliche Aufteilung; den genauen Umfang regeln Vertrag und Tarif. Im Zweifel fragen Sie Ihren Hoster:

• Enthält das PHP auf meinem Server die Sicherheitskorrekturen vom 21. Oktober 2026 – und seit wann?
• Wird mein PHP-Zweig noch offiziell unterstützt? Falls nicht: Bis wann und wie sollte ich wechseln?
• Wurden die PHP-Worker nach dem Update neu gestartet?
• Wie oft werden Backups erstellt, wie lange aufbewahrt, und wie beantrage ich eine Wiederherstellung?

Warum veraltete PHP-Versionen riskant sind

Eine PHP-Version am Ende ihres Lebenszyklus (End of Life) erhält keine offiziellen Korrekturen für neu entdeckte Lücken mehr. Selbst wenn heute einmalig nachgebessert wird, bleibt die nächste Schwachstelle womöglich offen.

Das Support-Modell von PHP ist klar: zwei Jahre aktiver Support, danach zwei Jahre nur kritische Sicherheitsupdates, dann ist Schluss. Der Support für PHP 8.2 wird am 31. Dezember 2026 enden. Mit 8.2.35 sind Sie gegen diese beiden Lücken geschützt, sollten den Wechsel auf 8.3 oder höher aber in den nächsten zwei Monaten einplanen.

Backports von Hostern oder Distributionen sind eine wertvolle Übergangslösung. Sie schließen jedoch nur bestimmte Lücken – nicht die übrigen bekannten Probleme, fehlende Performance-Verbesserungen oder die wachsende Inkompatibilität mit modernen Erweiterungen. Dauerhaft hilft nur ein unterstützter Zweig.

Woran Sie einen sicherheitsbewussten Hoster erkennen

Vorfälle wie dieser zeigen: Die Sicherheitsprozesse eines Hosters zählen ebenso viel wie Preis und Speicherplatz. Fragen Sie beim Vergleich:

So erfüllen die Hosting-Pakete von Atak Domain diese Kriterien

Diese Kriterien können Sie direkt an den Webhosting-Paketen von Atak Domain messen. Die folgenden Angaben stammen aus den auf der Produktseite aufgeführten Leistungen; sie sind keine Aussage zu diesem konkreten PHP-Vorfall.

Häufig gestellte Fragen

Ist meine Website von der PHP-Sicherheitslücke betroffen?

Wenn Ihre Website mit PHP läuft (WordPress, TYPO3, Shopware, JTL-Shop, Contao usw.) und das PHP auf dem Server die Korrekturen vom 21. Oktober 2026 noch nicht enthält, ja. Mit PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder einem gepatchten Paket Ihres Anbieters sind beide Lücken geschlossen. Betroffen heißt nicht, dass Ihre Website gehackt wurde.

Muss ich PHP sofort aktualisieren?

Ja. Das PHP Security Team und das BSI rufen zum sofortigen Update auf. Ein Sicherheitsupdate innerhalb desselben Zweigs (z. B. 8.3.35 auf 8.3.36) verursacht selten Kompatibilitätsprobleme. Im Shared Hosting spielt es der Hoster ein – Ihre Aufgabe ist es, das bestätigen zu lassen.

Ist PHP sicher, wenn WordPress aktuell ist?

Nein. Updates von WordPress, Themes und Plugins patchen nicht die PHP-Laufzeit. PHP muss auf dem Server separat aktualisiert werden. Das sind zwei verschiedene Ebenen mit eigenen Updates.

Patcht mein Hoster PHP automatisch?

Im Shared und Managed Hosting in der Regel ja – Zeitpunkt und Umfang unterscheiden sich aber je nach Anbieter. Beim nicht verwalteten VPS oder Dedicated Server sind Sie selbst zuständig. Am sichersten ist eine schriftliche Bestätigung Ihres Hosters.

Kann ein PHP-Wechsel meine Website lahmlegen?

Ein Sicherheitsupdate im selben Zweig selten. Ein Zweigwechsel (z. B. 8.1 auf 8.3) kann ältere Plugins oder Themes aus dem Tritt bringen. Erstellen Sie vorher ein Backup, testen Sie möglichst auf Staging und arbeiten Sie danach die Checkliste ab.

Ist PHP 8.2 noch sicher?

PHP 8.2.35 schließt diese beiden Lücken. Der Support für PHP 8.2 wird jedoch am 31. Dezember 2026 enden; danach werden neue Lücken nicht mehr behoben. Planen Sie den Wechsel auf 8.3 oder höher in den kommenden Wochen.

Schützt mich ein SSL-Zertifikat?

Nein. SSL verschlüsselt die Verbindung zwischen Browser und Server, behebt aber keinen Fehler im PHP auf diesem Server. Schädliche Anfragen kommen auch verschlüsselt an. Eine WAF oder ein Malware-Scanner senkt das Risiko, ersetzt das Update aber nicht.

Sollte ich meine Website vom Netz nehmen?

In der Regel nicht. Vorrang hat das PHP-Update samt Bestätigung. Betreiben Sie einen kritischen Server, den Sie noch nicht patchen können – vor allem mit mod_php –, kann eine Zugriffsbeschränkung bis zum Update sinnvoll sein. Das hängt von Ihrer eigenen Risikobewertung ab.

Was muss ich als VPS-Betreiber tun?

PHP aus dem Sicherheits-Repository Ihrer Distribution aktualisieren (oder das Release vom 21. Oktober selbst kompilieren), PHP-FPM und Webserver neu starten und mit php -v sowie dem Paket-Changelog prüfen. Laufen mehrere PHP-Versionen oder Container-Images, prüfen Sie jede einzeln.

Fazit: Erst aktualisieren, dann prüfen

CVE-2026-109618 und CVE-2026-109619 gehören zu den seltenen Lücken in PHP selbst, die bis zur Ausführung von Schadcode führen können. Die gute Nachricht: Für alle unterstützten Zweige liegen Korrekturen vor.

Drei Dinge sollten Sie heute erledigen: Ihre PHP-Version ermitteln, den installierten Fix bestätigen lassen und sicherstellen, dass ein aktuelles Backup existiert. Nutzen Sie noch PHP 8.1 oder älter, ist jetzt auch der richtige Zeitpunkt, den Wechsel auf einen unterstützten Zweig zu planen.

Sicherheit als laufende Pflege statt als einmaligen Notfall zu behandeln, ist auf Dauer der entspannteste Weg. Eine unterstützte PHP-Version, regelmäßige Backups und ein erreichbarer Support sind dafür die drei Grundpfeiler.

Quellen

• PHP: Security advisory – Critical remote code execution vulnerabilities (21.10.2026)
• PHP: Informational advisory – Session upload progress (23.10.2026)
• PHP: Supported Versions
• ingenieur.de: Kritische PHP-Lücken – BSI warnt vor Angriffen auf Webserver
• Rapid7: Analyse zu CVE-2026-109618 und CVE-2026-109619
• Canadian Centre for Cyber Security: Alert AL26-026