Dein Passwort kann 40 Zeichen lang sein. Diese PHP-Lücken fragen nicht danach.
Unter dem Namen PHP2Shell werden zwei kritische Schwachstellen in PHP zusammengefasst: CVE-2026-109618 und CVE-2026-109619. Unter bestimmten Voraussetzungen ermöglichen sie Angreifern, ohne vorherige Anmeldung fremden Code auf einem betroffenen Server auszuführen. Beide wurden mit 9,2 von 10 Punkten nach CVSS v4.0 bewertet. Sicherheitsupdates wurden am 21. Oktober 2026 veröffentlicht.
Dabei geht es um deutlich mehr als Unternehmenswebsites. Auch Portale, Geschäftsanwendungen und Produkte mit eingebauter PHP-Laufzeit können betroffen sein. PHP muss für den Anwender nicht einmal sichtbar sein.
Die entscheidende Frage lautet deshalb nicht: „Funktioniert unsere Website noch?“ Sondern: „Welche unserer Systeme verwenden PHP – und ist dort die Sicherheitskorrektur tatsächlich aktiv?“
Dieser Leitfaden hilft dir, die Betroffenheit einzugrenzen, die richtigen Fragen an deinen Dienstleister zu stellen und Updates nachvollziehbar zu prüfen. Für Administratoren gibt es zusätzlich konkrete Hinweise zu Plesk. Berücksichtigt ist auch der ergänzende PHP-Hinweis vom 23. Oktober 2026.
Was ist PHP2Shell – und warum schützt ein Login nicht zuverlässig?
PHP2Shell betrifft Fehler in der PHP-Laufzeit selbst. Das ist die Software, die PHP-Anwendungen auf dem Server ausführt. Die Schwachstellen liegen damit unterhalb der eigentlichen Anwendungslogik. Für Apache mit mod_php beschreibt das PHP-Team einen demonstrierten Angriff, der bereits vor der Ausführung des Anwendungscodes greift. Eine dort programmierte Anmeldung kann diesen Angriff deshalb nicht verhindern.
CVE-2026-109618: Fehler bei Speichermangel
Wenn PHP eine Anfrage wegen Speichermangels abbricht, können interne Daten unvollständig initialisiert zurückbleiben. Beim anschließenden Aufräumen können diese ungültigen Daten weiterverarbeitet werden. Unter geeigneten Bedingungen lässt sich daraus eine Ausführung fremden Codes erreichen.
CVE-2026-109619: Verweise auf bereits freigegebenen Speicher
Bei der zweiten Schwachstelle können interne Zustände einer Anfrage erhalten bleiben, obwohl der zugehörige Speicher bereits freigegeben wurde. Verarbeitet derselbe PHP-Prozess später eine weitere Anfrage, können solche veralteten Verweise erneut verwendet werden. Auch daraus kann eine Codeausführung entstehen.
Der Fachbegriff dafür lautet Remote Code Execution, kurz RCE. Gemeint ist: Ein Angreifer kann aus der Ferne Code ausführen lassen, den der Betreiber nicht vorgesehen hat.
Wichtig ist die Einordnung: Das bedeutet nicht automatisch volle Administrator- oder Root-Rechte auf jedem Server. Die Codeausführung erfolgt zunächst mit den Rechten des betroffenen Dienstkontos. Welche Daten und weiteren Systeme erreichbar wären, hängt unter anderem von Berechtigungen und Trennung der Anwendungen ab. Trotzdem können bereits diese Rechte erhebliche Schäden ermöglichen.
Welche Systeme können betroffen sein? Viel mehr als Websites
ENISA empfiehlt ausdrücklich, auch kommerzielle Software und Open-Source-Produkte zu prüfen, die PHP im Hintergrund einsetzen. Das niederländische NCSC nennt außerdem Appliances, Netzwerkgeräte und Verwaltungsoberflächen mit eingebetteter PHP-Laufzeit.
Für deine Bestandsaufnahme lohnt sich deshalb folgende Prüfliste. Gemeint sind jeweils Lösungen, die tatsächlich PHP verwenden – nicht pauschal jedes Produkt dieser Kategorie.
| Bereich | Was du in die Prüfung aufnehmen solltest |
|---|---|
| Websites und Content-Management-Systeme | Hauptauftritte, Formulare, Kampagnenseiten und ältere Installationen |
| Shops und Buchungssysteme | Verkaufsplattformen, Reservierungen und zugehörige Verwaltungsbereiche |
| Kunden- und Mitarbeiterportale | Geschützte Bereiche, Dateiübertragungen und individuelle Webanwendungen |
| Geschäftsanwendungen und Schnittstellen | PHP-basierte Verwaltungslösungen, APIs und interne Werkzeuge |
| Zusammenarbeit und Administration | Selbst gehostete Dienste, Webmail, Datenbank- und Serveroberflächen |
| Geräte, Container und Zusatzprodukte | Separat ausgelieferte PHP-Laufzeiten und herstellerseitig gebündelte Komponenten |
Vergiss dabei nicht Testumgebungen und Subdomains. Für deine Prüfliste zählen nicht nur die Systeme, die täglich genutzt werden, sondern alle noch erreichbaren Installationen.
Betrifft PHP2Shell hauptsächlich Plesk?
Nein, diese Einschränkung wäre nicht sachgerecht. Die offiziellen Hinweise nennen unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Plesk ist eine mögliche Verwaltungsumgebung, aber nicht die Ursache der PHP-Schwachstellen. Das PHP-Team bewertet mod_php als besonders risikoreich. Daraus folgt jedoch keine Entwarnung für PHP-FPM oder andere Betriebsarten.
Genauso wenig handelt es sich um ein Problem eines einzelnen CMS. Ein Anwendungsupdate ersetzt die Korrektur der darunterliegenden PHP-Laufzeit nicht, sofern es diese Laufzeit nicht selbst mit aktualisiert.
Werden die Schwachstellen bereits angegriffen?
Amazon Threat Intelligence berichtet von einem Ausnutzungsversuch gegen sein MadPot-Honeypot-System am 17. Oktober 2026 – vier Tage vor der Veröffentlichung der Updates. Weitere Versuche wurden am 21. Oktober beobachtet. Amazon betont zugleich, dass bei den untersuchten Versuchen nicht abschließend feststand, ob sie gegen reale Produktivsysteme erfolgreich gewesen wären.
Diese Unterscheidung ist wichtig: Ein beobachteter Angriffsversuch ist kein Beweis dafür, dass dein System kompromittiert wurde. Er ist aber ein guter Grund, die Prüfung nicht auf den nächsten regulären Wartungstermin zu verschieben.
Welche PHP-Versionen enthalten die Sicherheitskorrekturen?
Für die beiden ursprünglichen PHP2Shell-Schwachstellen wurden folgende korrigierte Upstream-Versionen veröffentlicht:
| PHP-Zweig | Erste korrigierte Version für beide ursprünglichen CVEs |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Maßgeblich ist jeweils die Version innerhalb ihres Zweiges. Eine ungepatchte PHP-8.5-Version ist nicht deshalb geschützt, weil ihre Nummer größer aussieht als 8.4.27. Die genannten Releases enthalten die Korrekturen für CVE-2026-109618 und CVE-2026-109619. Sie sind keine pauschale Garantie gegen sämtliche PHP-Sicherheitsprobleme.
Für Updates solltest du die aktuell vom zuständigen Anbieter freigegebene, kompatible Sicherheitsversion verwenden. Die Tabelle nennt Mindeststände für diese beiden CVEs, keine Aufforderung, eine inzwischen neuere Version zurückzustufen.
Warum eine ältere Versionsnummer trotzdem gepatcht sein kann
Linux-Distributoren und andere Anbieter können Sicherheitskorrekturen in ältere Paketstände übernehmen. Das nennt sich Backport. Dabei bleibt die sichtbare PHP-Basisversion teilweise unverändert, während die Paketrevision steigt. Deshalb kann ein Vergleich der bloßen Versionsnummer Fehlalarme liefern.
Für einen belastbaren Nachweis gehören daher Paketquelle, vollständige Paketversion und die zugehörige Herstellerbestätigung zusammen. „Der Anbieter patcht normalerweise“ reicht dafür nicht. Lass dir ausdrücklich bestätigen, welches installierte Paket beide CVEs behebt.
Was gilt für PHP 8.1 und ältere Versionen?
PHP 8.1 und ältere Zweige erhalten keine regulären Sicherheitsreleases mehr vom PHP-Projekt. Für diesen Vorfall wurden jedoch minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 bereitgestellt; zusätzlich können Distributionen und Langzeitsupport-Anbieter korrigierte Pakete liefern.
Ein solcher Sonderpatch ist eine Übergangslösung, kein Neustart des regulären Supports. Plane deshalb trotzdem die Migration auf einen unterstützten Zweig. Beachte dabei: Auch der reguläre Sicherheits-Support für PHP 8.2 endet bereits am 31. Dezember 2026. Bei einer ohnehin notwendigen Migration sollte die verbleibende Supportdauer in die Entscheidung einfließen.
Ergänzung vom 23. Oktober: Session-Upload-Progress prüfen
Am 23. Oktober veröffentlichte PHP einen ergänzenden Hinweis zu CVE-2026-115560. Diese weitere RCE-Möglichkeit betrifft eine ungewöhnliche Kombination: Die Anwendung verwendet zunächst php_binary oder php_serialize als Session-Serialisierung, wechselt zur Laufzeit per ini_set() auf php und ruft anschließend session_start() auf. Gleichzeitig ist Session-Upload-Progress aktiviert.
PHP empfiehlt bis zum nächsten regulären Bugfix-Release vorsorglich:
session.upload_progress.enabled = 0
Anwendungen, die den Serialisierungsmechanismus nicht zur Laufzeit ändern, dürfen die Funktion laut PHP aktiviert lassen. Die Empfehlung bedeutet also nicht, dass jede bereits aktualisierte Installation gleich stark gefährdet ist.
Die Einstellung muss administrativ wirksam werden, bevor PHP Anfragen verarbeitet. Für die Session-bezogenen Schutzmaßnahmen sind alle betroffenen PHP-Worker neu zu starten; auf ein spätes ini_set() oder eine FPM-.user.ini sollte man sich dafür nicht verlassen.
Deaktiviert wird die PHP-Funktion zur Erfassung des Upload-Fortschritts, nicht grundsätzlich das Hochladen von Dateien. Anwendungen, die diese Fortschrittsfunktion nutzen, sollten anschließend getestet werden.
PHP2Shell absichern: Ein Vorgehen, das sich überprüfen lässt
1. Alle PHP-Laufzeiten erfassen
Beginne nicht mit dem Update-Button, sondern mit einer Liste. Unsere Empfehlung: Erfasse für jede Anwendung den Namen, die Adresse oder den internen Zugang, den Server, den technischen Ansprechpartner und den festgestellten Patchstand.
Prüfe separat verwaltete Laufzeiten: Ein Update auf dem Host aktualisiert nicht automatisch die PHP-Version in einem Container oder einer Appliance. Für gebündelte PHP-Komponenten können eigene Herstellerupdates erforderlich sein. Das NCSC empfiehlt ausdrücklich, solche Produkte und Images gesondert einzubeziehen.
Ein praktikables Arbeitsblatt kann so aussehen:
| System | Laufzeit und Paketquelle | Verantwortlich | Nachweis und nächster Schritt |
|---|---|---|---|
| Kundenportal | Noch zu ermitteln | Zuständigen Dienstleister eintragen | Paketstand bestätigen lassen |
| Buchungssystem | Noch zu ermitteln | Hosting-Verantwortlichen eintragen | Herstellerhinweis abgleichen |
| Interne Anwendung | Noch zu ermitteln | IT-Verantwortlichen eintragen | Erreichbarkeit und Updateweg prüfen |
Diese Tabelle ist eine Arbeitsvorlage, keine Aussage über eine konkrete Installation. Entscheidend ist, dass am Ende keine Zeile bei „vermutlich erledigt“ stehen bleibt.
2. Zuständigkeiten eindeutig festlegen
Kläre für jedes System, wer die PHP-Laufzeit aktualisieren darf und wer den Abschluss prüft. Verlasse dich nicht darauf, dass Hoster, Entwickler und interner Administrator jeweils von derselben Aufgabenverteilung ausgehen.
Frage konkret: Wer spielt das Update ein? Bis wann? Wer startet betroffene Dienste neu? Wer testet die Anwendung? Wer bestätigt anschließend den tatsächlichen Stand?
Gerade bei mehreren Dienstleistern sollte ein Ansprechpartner die Rückmeldungen zusammenführen. Unser Vorschlag: Behandle einen fehlenden Nachweis als offenen Prüfpunkt – nicht als automatische Entwarnung, aber auch nicht als Beweis einer Kompromittierung.
Du suchst einen festen Ansprechpartner für den laufenden Betrieb? In unseren Leistungen rund um Hosting, Website-Pflege und Monitoring findest du die Möglichkeiten einer regelmäßigen technischen Betreuung. Welche Systeme und Aufgaben dazugehören, wird im Betreuungsumfang festgelegt.
3. Wiederherstellung vorbereiten und kontrolliert aktualisieren
Stelle vor Änderungen sicher, dass verwendbare Sicherungen von Anwendungsdateien, Datenbanken und relevanten Konfigurationen vorhanden sind. Halte außerdem fest, wie du bei einem fehlgeschlagenen Update wieder in eine funktionsfähige Umgebung kommst.
Unsere Empfehlung: Bevorzuge zunächst eine passende Sicherheitsaktualisierung im vorhandenen unterstützten Zweig. Ein großer Versionssprung und ein dringender Sicherheitspatch sind zwei unterschiedliche Änderungen. Muss wegen einer Altversion migriert werden, prüfe zusätzlich die Kompatibilität von Anwendung, Erweiterungen und benötigten PHP-Modulen.
Bei Fremdsoftware sollte der dokumentierte Updateweg des Herstellers verwendet werden. Tausche eine eingebettete PHP-Laufzeit nicht auf Verdacht manuell aus.
Besteht bereits ein konkreter Einbruchsverdacht, stimme Änderungen und Neustarts mit der Vorfallsbearbeitung ab. Die Sicherung von Beweisdaten und die Begrenzung des Schadens gehören dann von Anfang an in den Ablauf.
4. Nicht nur installieren, sondern den laufenden Stand kontrollieren
Ein Paket auf der Festplatte und der Prozess, der gerade Anfragen bearbeitet, sind zwei unterschiedliche Prüfgegenstände. Bestätige deshalb nach dem Update, dass die vorgesehenen Dienste neu gestartet wurden und die Anwendung tatsächlich die korrigierte Laufzeit verwendet.
Für Plesk ist besonders wichtig: Unterschiedliche Domains können unterschiedliche PHP-Versionen und Handler verwenden. Ein erfolgreicher Test an einer einzelnen Domain sagt daher nicht automatisch etwas über alle anderen Projekte aus.
Dokumentiere nicht nur „PHP aktualisiert“, sondern auch das betroffene System, den Paketstand, den Neustart und das Ergebnis der Prüfung. So lässt sich später nachvollziehen, was wirklich erledigt wurde.
5. Die wichtigen Geschäftsabläufe testen
Prüfe nach der Aktualisierung nicht ausschließlich die Startseite. Stelle dir stattdessen die Frage: Welche Funktionen müssen für Kunden und Mitarbeiter zuverlässig funktionieren?
Ein sinnvoller Testablauf umfasst beispielsweise Anmeldung, Dateiübertragung, Formularversand, eine Testbuchung oder Testbestellung und relevante Schnittstellen. Beziehe geplante Aufgaben, Hintergrundverarbeitung und Fehlerprotokolle ein, soweit diese zu deiner Anwendung gehören.
Diese Tests dienen der Funktionskontrolle. Sie ersetzen weder den Patchnachweis noch eine Untersuchung auf frühere Angriffe. Ein funktionierender Checkout und eine korrekt aktualisierte PHP-Version beantworten unterschiedliche Fragen.
Plesk prüfen: Website-PHP und Verwaltungsoberfläche getrennt betrachten
Plesk stellt Korrekturen für die ausgelieferten PHP-Versionen bereit. Zusätzlich verwendet die Plesk-Oberfläche eine eigene PHP-Engine. Deshalb darf die Prüfung nicht bei der PHP-Auswahl einer Kundendomain enden.
Für die eigene Engine nennt Plesk unter anderem diese korrigierten Stände:
- Plesk Obsidian 18.0.81 Update 4.
- Plesk Obsidian 18.0.80 Update 11.
Diese Angaben gelten für die in der Herstellerwarnung genannten Linux- und Windows-Komponenten. Nutze einen passenden aktuellen Stand mit diesen Korrekturen oder neueren kumulativen Updates.
Updates über die Plesk-Oberfläche
Administratoren finden den Updateweg unter „Tools & Einstellungen → Updates → Komponenten aktualisieren“. Plesk dokumentiert außerdem den CLI-Aufruf plesk installer update. Plane Änderungen bewusst und kontrolliere den Abschluss; automatische Update-Einstellungen allein sind kein Installationsnachweis.
Danach solltest du die Zuordnung der Domains zu ihren PHP-Handlern prüfen. Achte auch auf separat installierte System-PHP-Pakete und Container, die nicht durch denselben Updatevorgang erfasst werden.
Diagnose über SSH: Diese Befehle verändern keine Konfiguration
Der folgende Block ist für Administratoren auf Plesk-Linux-Servern gedacht. Er zeigt die Plesk-Version, registrierte Handler und die Versionen der üblichen Plesk-PHP-Binaries:
plesk version
plesk bin php_handler --list
for php_bin in /opt/plesk/php/*/bin/php; do
[ -x "$php_bin" ] || continue
printf '\n%s\n' "$php_bin"
"$php_bin" -v | head -n 1
done
Welche Domains einen bestimmten Handler verwenden, lässt sich beispielsweise so abfragen:
plesk bin php_handler --get-usage -id plesk-php83-fpm
Die Handler-ID ist ein Beispiel. Verwende die tatsächliche ID aus der Handlerliste. Berücksichtige bei der Bestandsaufnahme auch andere registrierte Handler derselben PHP-Version.
Wichtig: php -v ohne vollständigen Pfad prüft nur das dadurch aufgerufene Kommandozeilenprogramm. Das ist kein vollständiger Nachweis für alle Webanwendungen oder bereits laufenden PHP-Prozesse.
Sonderfall: Plesk-Patches für alte PHP-Versionen
Für Plesk unter Linux nennt der Hersteller auch korrigierte Builds von PHP 7.4.33, 8.0.30 und 8.1.34. Ihre Versionsnummer bleibt unverändert; die in der Warnung genannten Builds vom 21. Oktober 2026 enthalten die Korrekturen.
Prüfe den vollständigen Herstellerpaketstand. Ein beliebiges neueres Build-Datum allein beweist nicht, dass beide Patches enthalten sind.
Diese Nachricht kannst du an deinen Hoster oder IT-Dienstleister senden
Du brauchst keinen Root-Zugang, um eine verbindliche Auskunft anzufordern. Diese Vorlage macht deutlich, welche Informationen du benötigst:
Betreff: PHP2Shell – Bitte Patchstand unserer PHP-Systeme bestätigen
Bitte prüft unsere betreuten Websites, Portale und sonstigen PHP-Anwendungen auf CVE-2026-109618 und CVE-2026-109619.
Bitte bestätigt für jedes betroffene System die tatsächlich verwendete PHP-Version einschließlich Paketrevision beziehungsweise Backport-Nachweis und den Zeitpunkt, seit dem die korrigierte Laufzeit aktiv ist.
Sind alle betroffenen PHP-Dienste beziehungsweise Instanzen neu gestartet worden? Wurden außerdem der PHP-Hinweis vom 23. Oktober zu CVE-2026-115560 und die relevante Session-Konfiguration geprüft?
Bitte teilt uns mit, welche Installationen noch offen sind, welche Übergangsmaßnahmen dort gelten und ob eine Prüfung auf frühere Angriffe erfolgt ist.
Bezieht bitte auch Testsysteme, Subdomains und separat gebündelte PHP-Laufzeiten ein, soweit diese zu eurem Betreuungsumfang gehören.
Woran erkenne ich einen möglichen Angriff?
Amazon empfiehlt, Webserver-Protokolle sowie unerwartete Prozessausführungen und Dateiänderungen zu untersuchen. Aufgrund des beobachteten frühen Versuchs sollte die Untersuchung mindestens den Zeitraum ab 17. Oktober 2026 berücksichtigen – bei Bedarf auch weiter zurück.
Ergänze die Prüfung um Auffälligkeiten in Benutzerkonten, geplanten Aufgaben und ausgehenden Verbindungen. Vergleiche Veränderungen mit deinen eigenen Deployments und Wartungsarbeiten, statt jede neue Datei automatisch als Schadsoftware einzustufen.
Einzelne verdächtige Requests beweisen noch keinen erfolgreichen Einbruch. Umgekehrt ist ein unauffälliger Blick in einige Logdateien kein belastbarer Beweis dafür, dass nichts passiert ist.
Bei konkretem Verdacht: Nicht einfach Dateien löschen
Begrenze den Zugriff auf betroffene Systeme und sichere relevante Protokolle sowie den Systemzustand für die Untersuchung. Vermeide vorschnelle Bereinigungsversuche, die Spuren vernichten könnten. Hole Unterstützung durch qualifizierte Incident-Response-Fachleute hinzu.
Bei bestätigter Kompromittierung müssen Bereinigung beziehungsweise Neuaufbau und die Erneuerung möglicherweise offengelegter Zugangsdaten zusammen geplant werden. Das betrifft gegebenenfalls auch Datenbankkennwörter, API-Schlüssel und andere Geheimnisse. Ein Passwortwechsel sollte über eine vertrauenswürdige Umgebung erfolgen.
Prüfe vor einer Wiederherstellung, ob das Backup aus einem vertrauenswürdigen Stand stammt. Spiele nicht einfach die jüngste Sicherung zurück: Sie könnte die unerwünschten Änderungen bereits enthalten. Bereinigte Systeme sollten vor der erneuten Freigabe aktualisiert und geprüft werden.
Ein Sicherheitsupdate schließt eine Schwachstelle. Es entfernt nicht automatisch einen bereits eingerichteten Fremdzugang. Deshalb sind Patchen und Vorfallsprüfung getrennte Aufgaben.
Was tun, wenn ein Update nicht sofort möglich ist?
Nicht jede ältere Anwendung lässt sich ohne Vorbereitung auf einen neuen PHP-Zweig umstellen. Das ist jedoch kein Grund, eine verwundbare Installation unverändert öffentlich erreichbar zu lassen.
ENISA empfiehlt, gefährdete Anwendungen gegebenenfalls aus öffentlichen Netzen zu isolieren, bis die Korrektur umgesetzt werden kann. Plane dann eine technische Zugriffsbeschränkung vor PHP, etwa am vorgeschalteten System oder an der Netzwerkgrenze.
Eine Wartungsseite innerhalb der PHP-Anwendung ist kein gleichwertiger Schutz: Bei dem beschriebenen mod_php-Angriffsweg kann die Schwachstelle bereits vor dem Anwendungscode ausgelöst werden.
Die offiziellen Hinweise nennen außerdem konfigurationsabhängige Übergangsmaßnahmen. Sie begrenzen bestimmte Angriffswege, ersetzen aber nicht beide Sicherheitskorrekturen. Insbesondere sollten Änderungen an Speichergrenzen nicht blind auf einen produktiven Server übertragen werden. Solche Maßnahmen gehören in die Hände der verantwortlichen Administration.
Eine Web Application Firewall kann ergänzend bestimmte Anfragen abfangen. Sie ist aber kein Ersatz für das PHP-Update. Auch Amazon beschreibt WAF-Regeln ausdrücklich als ergänzende Schutzmaßnahme während des Patchens.
Drei Fragen, die bei der Prüfung häufig auftauchen
Reicht ein externer Online-Scanner?
Nicht als alleiniger Nachweis. Ein Scanner, der nur öffentlich sichtbare Versionsangaben vergleicht, kann herstellerseitige Backports falsch bewerten. Er kann einen Hinweis liefern; der belastbare Abgleich erfolgt mit den installierten Paketen und den zugehörigen Herstellerinformationen.
Muss jede Anwendung auf PHP 8.5 umgestellt werden?
Nein. Die ursprünglichen Korrekturen wurden für mehrere PHP-Zweige veröffentlicht. Entscheidend sind ein korrigierter Paketstand, die Kompatibilität der Anwendung und ein sinnvoller verbleibender Supportzeitraum. Ein Versionssprung sollte geplant werden, nicht als pauschale Sofortmaßnahme erfolgen.
Ist ein System nach dem Update garantiert sicher?
Nein. Du kannst dokumentieren, dass bestimmte Schwachstellen behoben wurden. Daraus folgt weder ein Ausschluss anderer Fehler noch der Nachweis, dass vor dem Update kein Angriff erfolgreich war. Behalte diese drei Fragen getrennt: Ist die Lücke geschlossen? Funktioniert die Anwendung? Gibt es Hinweise auf eine frühere Kompromittierung?
Kostenloser PHP-Check von Retaro: Klarheit statt Vermutungen
Du weißt nicht, welche PHP-Version deine Systeme verwenden oder ob die erforderlichen Updates tatsächlich aktiv sind?
Retaro bietet dir einen kostenlosen und unverbindlichen PHP-Check. Gemeinsam klären wir den Versions- und Update-Stand der vereinbarten PHP-Umgebung und gleichen die verfügbaren Informationen mit den relevanten Herstellerhinweisen ab. Du erhältst eine verständliche Einschätzung, ob weiterer Handlungsbedarf besteht.
Dabei geht es nicht nur um Websites: Auch Shops, Portale und individuelle PHP-Anwendungen gehören zu den möglichen Prüfkandidaten.
Der kostenlose Check ist eine eingegrenzte Erstprüfung des Versions- und Patchstands. Er ersetzt keinen vollständigen Penetrationstest und keine forensische Untersuchung. Eventuell notwendige Updates, Migrationen oder weitergehende Analysen stimmen wir separat mit dir ab.
Auch bei der anschließenden technischen Betreuung unterstützen wir dich. Einen Überblick findest du unter Webentwicklung & IT.
Schreib uns mit dem Stichwort „PHP-CHECK“ an kontakt@retaro-group.com oder nutze unser Kontaktformular. Nenne zunächst die betroffene Anwendung und, soweit bekannt, den Hosting-Anbieter. Zugangsdaten gehören nicht in öffentliche Kommentare.
Kostenlosen PHP-Check anfragen
Fazit: „Wird schon jemand gemacht haben“ ist kein Update-Status
Die wichtigste Aufgabe ist jetzt, aus Vermutungen einen nachvollziehbaren technischen Stand zu machen: Systeme erfassen, Verantwortliche festlegen, Korrekturen installieren, laufende Prozesse prüfen und Auffälligkeiten untersuchen.
Nicht eine grüne Update-Meldung entscheidet darüber, ob die Arbeit erledigt ist. Sondern der Nachweis, dass die richtige PHP-Laufzeit in der richtigen Anwendung korrigiert wurde – und offene Punkte nicht übersehen werden.
Quellen und weiterführende Informationen
Stand der fachlichen Angaben: 23. Oktober 2026. Die folgenden Hersteller- und Behördenquellen belegen die jeweiligen Abschnitte. Paketstände und Empfehlungen können sich ändern. Externe Quellen öffnen in einem neuen Tab.
Sicherheitsmeldungen, Angriffswege und betroffene Produkte
- PHP: Sicherheitsmeldungen vom 21. und 23.10.2026
- CERT-EU: Security Advisory 2026-018, aktualisiert am 23.10.2026
- ENISA: Joint statement on critical PHP vulnerabilities
- PHP: CVE-2026-109618 – RCE via OOM corruption
- PHP: CVE-2026-109619 – RCE via stale global state
- NCSC-NL: PHP2Shell – operative Informationen und Produktübersicht
Versionen, Backports und PHP-Konfiguration
- Red Hat: Security Backporting Practice
- PHP: Unterstützte Versionen und Supportzeiträume
- PHP-Handbuch: Session Upload Progress
- PHP-Handbuch: Optionen der Kommandozeilenschnittstelle
Plesk: Sicherheitsupdates, Handler und Administration
- Plesk: PHP2Shell-Sicherheitswarnung und korrigierte Paketstände
- Plesk: Installation von Plesk-Updates
- Plesk: PHP Handler Types
- Plesk: php_handler – Handler und verwendende Domains abfragen
