Sicherheitshinweis: kritische PHP-Lücken CVE-2026-109618 und CVE-2026-109619
Am 21. Oktober 2026 wurden zwei kritische Schwachstellen im PHP-Kern veröffentlicht, die Remote Code Execution ohne Anmeldung erlauben. Betroffen ist jeder Server mit PHP-Websites, auch Server, die mit ShadowPanel verwaltet werden. Hier steht, was Sie aktualisieren müssen, wie Sie Ihre Versionen prüfen, was Sie bis zum Eintreffen der korrigierten Pakete tun und was mit Websites auf PHP 7.4, 8.0 oder 8.1 geschieht.
Am 21. Oktober 2026 hat das PHP-Projekt ein Notfall-Release für zwei kritische Schwachstellen im PHP-Kern veröffentlicht: CVE-2026-109618 und CVE-2026-109619 (jeweils CVSS v4.0 9,2). Beide erlauben Remote Code Execution ohne Anmeldung: Wer eine HTTP-Anfrage an ein beliebiges PHP-Skript senden kann, kann Code mit den Rechten des PHP-Prozesses ausführen. Der offizielle PHP-Sicherheitshinweis trägt den Titel „update now“. Details sind vor der koordinierten Veröffentlichung durchgesickert, erste Angriffe werden bereits gemeldet. Hoster spielen den Fix gerade auf ihre verwalteten Plattformen ein. Hetzner etwa aktualisiert seine Managed-Hosting-Produkte. Auf Ihrem eigenen VPS ist das Patchen Ihre Aufgabe.
Wer betroffen ist
Jede PHP-Installation, die Web-Anfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Projekt stuft mod_php als am stärksten gefährdet ein. Die Lücken liegen in der Verarbeitung der Anfrage, bevor Ihr Anwendungscode läuft. Login-Seiten, Sicherheits-Plugins und Middleware schützen Sie deshalb nicht.
- CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): Die Behandlung von Speichermangel kann PHP unterbrechen, während die Anfragedaten erst teilweise initialisiert sind. Das anschließende Aufräumen behandelt ungültige Daten dann als gültig.
- CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): Anfragezustand kann weiterleben, nachdem sein Speicher freigegeben wurde, und eine spätere Anfrage auf demselben Worker kann ihn verwenden. Erreichbar über die Upload-Fortschrittsanzeige und Backtraces bei fatalen Fehlern.
ShadowPanel-Server sind über PHP betroffen, nicht über ShadowPanel selbst. API und Daemon des Panels laufen auf Node.js. Aber jede gehostete PHP-Website läuft auf dem PHP-FPM des Servers, ebenso phpMyAdmin und Webmail auf dem Admin-Port. Der Fix kommt über die PHP-Pakete Ihrer Distribution. Für ihn ist kein ShadowPanel-Update nötig.
Die korrigierten Versionen
| Zweig | Behoben in |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | kein Release, nur Backports im Quellcode (End of Life) |
| PHP 7.3 und älter | nichts |
Beachten Sie: PHP 8.2 selbst erreicht am 31. Dezember 2026 das Ende seines Supports.
Schritt 1: Prüfen, was Ihr Server ausführt
ShadowPanel installiert PHP aus dem Repository ondrej/php und kann mehrere Versionen parallel betreiben. Prüfen Sie jede einzelne:
for v in /etc/php/*/; do v=$(basename "$v"); echo "$v: $(php$v -v 2>/dev/null | head -1)"; done
Jede Version unterhalb der Tabelle ist verwundbar.
Schritt 2: Die korrigierten Pakete installieren
apt update
apt list --upgradable 2>/dev/null | grep '^php'
apt upgrade
systemctl restart 'php*-fpm'
Verwenden Sie restart, nicht reload, damit kein Worker das alte Binary weiter ausführt. Führen Sie danach die Prüfung aus Schritt 1 erneut aus und kontrollieren Sie die neuen Versionsnummern.
Distributionspakete können einige Stunden nach dem offiziellen Release erscheinen. Zeigt apt list --upgradable die korrigierte Version noch nicht, setzen Sie jetzt Schritt 3 um und wiederholen Sie Schritt 2 im Laufe des Tages.
Schritt 3: Das Risiko bis zum Eintreffen der Pakete senken
Die PHP-Entwickler sind eindeutig: Nur das Update behebt diese Lücken. Die folgenden Maßnahmen senken das Risiko. Sie beseitigen es nicht.
Schalten Sie den Session-Upload-Fortschritt ab. Das schließt den bestätigten Angriffsweg für CVE-2026-109619 und kostet auf den meisten Websites nichts:
for d in /etc/php/*/fpm/conf.d; do
echo 'session.upload_progress.enabled = 0' > "$d/99-upload-progress-off.ini"
done
systemctl restart 'php*-fpm'
Die Datei in conf.d gilt für alle Pools dieser PHP-Version, auch für die Pools pro Website, die ShadowPanel anlegt. Sie können sie nach dem Update stehen lassen. Unter PHP 8.5 ergänzen Sie in derselben Datei fatal_error_backtraces = 0.
Begrenzen Sie die Anfragegröße gegen CVE-2026-109618. Der PHP-Hinweis empfiehlt memory_limit = -1 zusammen mit post_max_size = 8M und upload_max_filesize = 8M (32M, wenn die Website Uploads braucht). Ohne Speicherlimit zu arbeiten ist nur sicher, wenn etwas anderes einen außer Kontrolle geratenen Worker stoppt, etwa ein MemoryMax=-Limit auf dem systemd-Dienst von PHP-FPM. Verwenden Sie dafür nicht RLIMIT_AS oder RLIMIT_DATA.
Bringen Sie Ihre PHP-Konfiguration zum Schweigen. Veraltete oder ungültige Einstellungen, die bei jeder Anfrage eine Warnung ausgeben, sowie fatale Fehler oder Timeouts, die ein Angreifer auslösen kann, erleichtern den Angriff. Sie mit error_reporting, display_errors oder @ zu verstecken hilft nicht.
Blockieren Sie Multipart-Anfragen auf Websites ohne Uploads. Eine Visitenkarten-Website oder ein Blog ohne öffentliche Formulare kann multipart/form-data schon in nginx ablehnen, bevor PHP die Anfrage sieht. Tun Sie das nicht bei einem Shop, einem Forum oder einem WordPress-Backend, das Medien hochlädt: Es blockiert jeden Datei-Upload.
Eine Regel in einer Web Application Firewall (CDN oder ModSecurity) kann bekannte Exploit-Anfragen stoppen, neue Varianten tauchen aber schnell auf. Betrachten Sie sie nur als Notlösung. Einstellungen über ini_set() oder .user.ini schützen Sie nicht: Setzen Sie sie in der PHP-FPM-Konfiguration und starten Sie neu.
Schritt 4: Websites von PHP-Versionen ohne Support wegbringen
PHP 7.4, 8.0 und 8.1 erhalten kein neues Release. Das PHP-Projekt hat minimale Backports im Quellcode veröffentlicht, ob Ihr Paket-Repository sie baut, entscheidet aber dessen Maintainer. Läuft eine Website noch auf einer dieser Versionen, ist jetzt der Moment für den Wechsel, am besten auf PHP 8.3 oder neuer, denn der Support für 8.2 endet dieses Jahr. In ShadowPanel wird die PHP-Version pro Website eingestellt, Sie können also eine Website nach der anderen umstellen, ohne die übrigen anzufassen. Testen Sie die Website zuerst mit der neuen Version, am besten auf einer Staging-Kopie. Wie Versionen pro Website funktionieren, lesen Sie unter mehrere PHP-Versionen pro Website.
Schritt 5: Nach Anzeichen einer Kompromittierung suchen
Die Lücken waren vor dem Patch öffentlich. Waren Ihre Websites in der Zwischenzeit erreichbar, prüfen Sie:
- unbekannte PHP-Dateien in Upload- und Cache-Verzeichnissen sowie kürzlich geänderte Dateien in Ihren Web-Roots;
- PHP-FPM-Fehler in
/var/log/php/und ungewöhnliche POST-Anfragen in den nginx-Access-Logs; - neue Admin-Konten, Cronjobs oder SSH-Schlüssel, die Sie nicht angelegt haben.
Der Malware-Scanner von ShadowPanel (Pro und Agency) prüft eine komplette Website mit ClamAV.
Zusammenfassung
- Prüfen Sie jede installierte PHP-Version.
- Installieren Sie die korrigierten Pakete und starten Sie PHP-FPM neu.
- Bis dahin:
session.upload_progressabschalten, die Anfragegröße begrenzen und Uploads einschränken, wo es geht. - Websites auf PHP 7.4, 8.0 oder 8.1 auf 8.3 oder neuer umstellen.
- Ihre Websites auf Anzeichen einer Kompromittierung prüfen.
Die offiziellen Details finden Sie im PHP-Sicherheitshinweis auf php.net. Wenn Sie ShadowPanel nutzen und Fragen zu Ihrem Server haben, eröffnen Sie ein Support-Ticket in Ihrem Konto.
Verwandte Artikel
Viele WordPress-Sites verwalten: Updates, Backups, Sicherheit
Zehn WordPress-Sites sind ein Hobby, fünfzig sind ein Job. Hier ist eine wiederholbare Routine, mit der Sie einen ganzen...
SPF, DKIM und DMARC: So landen Server-E-Mails nicht mehr im Spam
Ihr Kontaktformular funktioniert, aber die Nachrichten landen im Spam – oder kommen nie an. Mailbox-Anbieter bewerten E-...
Von cPanel auf einen VPS umziehen – ohne Ausfallzeit
Der Abschied vom Shared Hosting ist vor allem eine Planungsfrage, keine technische. Dieser Leitfaden führt durch Bestand...