Häufig gestellte Fragen
Welche PHP-Versionen sind betroffen?
Alle Versionen vor 8.5.12, 8.4.27, 8.3.36 und 8.2.35 in den unterstützten Zweigen. PHP 8.1 und älter sind End of Life und erhalten kein Release des PHP-Projekts; betrachten Sie sie als betroffen, sofern Ihr Hersteller keinen zurückportierten Fix bestätigt.
Meine Website zeigt keine PHP-Version an. Bin ich sicher?
Nicht unbedingt. Das Verbergen der Version (expose_php = Off) ist gute Praxis, patcht aber nichts. Prüfen Sie auf dem Server mit php -v oder fragen Sie Ihren Anbieter.
Die Prüfung zeigt eine alte Version, mein Hoster sagt aber, sie sei gepatcht. Wer hat recht?
Möglicherweise beide. Linux-Distributionen wie Debian, Ubuntu und RHEL portieren Sicherheitskorrekturen oft zurück, ohne die Versionsnummer zu ändern. Fragen Sie Ihren Hoster, welcher Paket-Build installiert ist und ob dessen Changelog CVE-2026-109618 und CVE-2026-109619 erwähnt.
Sind WordPress, Laravel oder mein CMS betroffen?
Die Fehler liegen in PHP selbst, daher ist jede Anwendung gefährdet, die auf einem betroffenen PHP läuft. Die Forscher haben Angriffe ohne Authentifizierung auf WordPress, Drupal und Joomla demonstriert, doch das waren nur Beispiele — schon eine einfache „Hello World“-Seite genügt. Ein Update von WordPress oder Plugins behebt das Problem nicht; PHP muss aktualisiert werden.
Können Daten abfließen, auch wenn kein Code ausgeführt wurde?
Ja. CVE-2026-109619 kann den Speicher des PHP-Prozesses offenlegen — Passwörter, Session-Tokens, API-Schlüssel und Zertifikate aus anderen Anfragen —, ohne dass der Angreifer Code ausführt. Solche Lecks hinterlassen keine Dateien und sind schwer zu erkennen; wechseln Sie daher die Geheimnisse jeder Website, auf der eine betroffene Version aus dem Internet erreichbar lief.
Hilft es, session.upload_progress abzuschalten?
Nein. php.net führt session.upload_progress.enabled=0 als teilweise Gegenmaßnahme für einige bestätigte Angriffswege von CVE-2026-109619 auf. Sie deckt nicht alle Varianten ab und wirkt nicht gegen CVE-2026-109618.
Reicht eine Web Application Firewall aus?
Eine WAF oder Anfragelimits können das Risiko bis zum Update verringern, aber die Probleme liegen darin, wie PHP Anfragen und Speicher verarbeitet. Ein Update ist weiterhin erforderlich.
Muss ich nach dem Update etwas neu starten?
Ja. PHP-FPM, Apache, LiteSpeed und langlaufende Worker führen den alten Code aus, bis sie neu gestartet werden. Container müssen aus dem neuen Image neu erstellt werden.
Was macht diese Prüfung eigentlich?
Sie sendet eine HEAD-Anfrage (oder ein GET, falls HEAD nicht erlaubt ist) an die eingegebene Adresse, folgt bis zu drei Weiterleitungen und liest Antwort-Header wie X-Powered-By und Server. Sie sendet niemals Exploit-Payloads, große Anfragen oder Uploads und scannt keine anderen Pfade.
Ist es legal, jede beliebige Website zu prüfen?
Prüfen Sie nur Websites, die Ihnen gehören oder für deren Bewertung Sie befugt sind. Die Anfrage entspricht einem normalen Besuch, für die verantwortungsvolle Nutzung sind jedoch Sie verantwortlich. Wir begrenzen die Prüfungen pro Netz und pro Website.
Wurde PHP 8.5.12 vollständig behoben?
Am 22. Oktober 2026 kursierten Berichte über einen Absturz in 8.5.12, die jedoch nicht als Remote-Schwachstelle bestätigt wurden. Wir richten uns nach php.net; erscheint ein neues Release, wird diese Website aktualisiert und das Datum „zuletzt geprüft“ ändert sich.
Wo finde ich die offiziellen Details?
Auf php.net und in den GitHub-Sicherheitshinweisen des PHP-Projekts GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp. Das Forschungsteam (Wiz Research, OpenAI Codex Security und Calif) hat seine Ergebnisse auf php2shell.com veröffentlicht.
Wer hat die Schwachstellen gefunden?
Forscher von Wiz Research, OpenAI Codex Security und Calif, im Rahmen einer koordinierten Offenlegung mit dem PHP-Sicherheitsteam, das die Fixes vorbereitet hat. Siehe den Beitrag von The PHP Foundation zum Release.