Sicherheit & Entwicklung

Zwei kritische PHP-Lücken: Sicherheitsbewusstsein statt Sprach-Bashing

Zwei kritische PHP-Lücken verlangen schnelle Updates, keine Sprachkriege. Was KI, Rust und Go mit der wichtigeren Frage zu tun haben: Wie bauen und betreiben wir sichere Software?

G Unit Solutions22. Oktober 20268 Min. Lesezeit

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken veröffentlicht und korrigierte Versionen bereitgestellt. Beide können die Ausführung von Code aus der Ferne ohne vorherige Anmeldung ermöglichen. Wer PHP-Anwendungen betreibt, muss diese Meldung ernst nehmen und aktualisieren.

Was daraus nicht folgt: dass PHP grundsätzlich ungeeignet ist oder ein Wechsel zu Rust, Go oder einer anderen Sprache das Sicherheitsproblem automatisch lösen würde. Die wichtigere Frage lautet: Wie bauen, prüfen und betreiben wir Software, wenn auch lange etablierter Code gefährliche Fehler enthalten kann?

Zuerst aktualisieren, dann diskutieren

Die Sicherheitsmeldung des PHP-Projekts nennt diese korrigierten Versionen:

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12

Aktualisieren Sie auf die korrigierte Version Ihres unterstützten Zweigs oder eine neuere Version mit diesen Korrekturen. Distributionen und LTS-Anbieter können die Fixes in Pakete mit älteren Versionsnummern zurückportieren. Prüfen Sie deshalb die Sicherheitsmeldung Ihres Anbieters und die tatsächlich installierte Paketversion, nicht nur die sichtbare PHP-Versionsnummer.

Das PHP-Projekt richtet die Warnung an alle Installationen, die Webanfragen verarbeiten. Dazu gehören unter anderem Apache mit mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das Projekt bei mod_php: Dort wurde eine Ausnutzung nachgewiesen, die bereits vor dem ersten Aufruf des Anwendungscodes ansetzen kann. Eine Anmeldung in Ihrer Anwendung ist deshalb kein ausreichender Schutz.

Nur ein Update mit den vollständigen Korrekturen behebt die Lücken zuverlässig. Die veröffentlichten Konfigurationsmaßnahmen reduzieren einzelne Angriffswege, machen eine ungepatchte Installation aber nicht sicher. Eine WAF-Regel oder ein Wechsel zu PHP-FPM ersetzt das Update nicht.

PHP 8.1 und ältere Zweige erhalten vom PHP-Projekt keine regulären Sicherheitsupdates mehr. Für diese Ausnahmesituation wurden minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 bereitgestellt. Das ist keine Wiederaufnahme des Supports. Klären Sie mit Ihrem Anbieter die Versorgung mit Korrekturen und planen Sie den Wechsel auf einen unterstützten Zweig.

Was die beiden Lücken bedeuten

CVE-2026-109618: Beschädigter Zustand bei Speichermangel

Bei einem Speicherfehler kann PHP die Verarbeitung unterbrechen, während interne Daten einer Anfrage erst teilweise initialisiert sind. Beim Aufräumen kann die Laufzeit diesen ungültigen Zustand anschließend wie gültige Daten behandeln. Daraus kann eine Ausführung von fremdem Code entstehen.

Das Advisory zu CVE-2026-109618 beschreibt eine bestätigte Ausnutzung gegen mod_php. Andere Betriebsarten haben andere Voraussetzungen und Abläufe. Daraus lässt sich aber keine allgemeine Entwarnung für PHP-FPM oder andere Integrationen ableiten.

CVE-2026-109619: Veralteter Zustand zwischen Anfragen

Ein PHP-Worker verarbeitet üblicherweise mehrere Anfragen nacheinander. Bestimmte interne Zustände können dabei noch auf Speicher einer früheren Anfrage zeigen, obwohl dieser bereits freigegeben wurde. Greift eine spätere Anfrage auf diesen Zustand zu, bevor die normale Initialisierung ihn zurücksetzt, kann ein Use-after-free entstehen.

Das Advisory zu CVE-2026-109619 beschreibt bestätigte Wege zur Codeausführung bei mod_php und PHP-FPM. Die genauen Voraussetzungen hängen vom betroffenen Zustand, der Konfiguration und teilweise vom Verhalten der Anwendung ab.

Beide Fehler liegen in der PHP-Laufzeit. Es wäre falsch, daraus pauschal schlechten Anwendungscode oder Nachlässigkeit der Betreiber abzuleiten. Betreiber verantworten trotzdem, wie schnell sie betroffene Systeme erkennen, aktualisieren und die Wirkung des Updates prüfen.

PHP ist nicht die einzige Sprache mit Sicherheitslücken

Auch andere Ökosysteme kennen erhebliche Sicherheitsprobleme. Zwei konkrete Beispiele zeigen, warum ein Sprachkrieg an der Sache vorbeigeht:

Rust, CVE-2024-24576: Die Standardbibliothek maskierte Argumente beim Aufruf von Windows-Batchdateien nicht ausreichend. Wenn nicht vertrauenswürdige Eingaben als Argumente übergeben wurden, war die Ausführung beliebiger Shell-Befehle möglich. Die offizielle Warnung stuft diesen konkreten Einsatz als kritisch ein. Andere Plattformen und andere Verwendungen waren nicht betroffen. Die Korrektur erschien in Rust 1.77.2.
Go, CVE-2025-22871: Das Paket net/http akzeptierte beim Lesen von Chunk-Größen unzulässige Zeilenenden. Zusammen mit einem vorgeschalteten Server mit einer bestimmten abweichenden Interpretation konnte das Request Smuggling ermöglichen. Die Korrekturen erschienen in Go 1.23.8 und 1.24.2.

Diese Beispiele sind keine Rangliste und kein Beleg für gleiche Risiken. Eine CVE zählt einen gemeldeten Fall, nicht die Sicherheit einer Sprache. Auswirkungen, Voraussetzungen und Verbreitung müssen getrennt betrachtet werden.

Die Sprachwahl ist trotzdem nicht bedeutungslos. Rusts Speichersicherheit verhindert im sicheren Rust viele Klassen von Speicherfehlern. Das ist ein realer Vorteil. Sie verhindert aber nicht automatisch Fehler beim Umgang mit Shell-Argumenten, Berechtigungen oder Protokollen. Auch Garbage Collection ersetzt keine korrekte HTTP-Verarbeitung.

Die sinnvolle Schlussfolgerung lautet deshalb nicht „alle Sprachen sind gleich unsicher“. Sie lautet: Keine Sprache nimmt uns die Verantwortung für das gesamte System ab. Laufzeit, Bibliotheken, native Erweiterungen, Schnittstellen, Konfiguration und Betrieb gehören dazu.

KI wird mehr solcher Probleme sichtbar machen

Unsere Erwartung: KI-gestützte Codeanalyse und die Unterstützung bei Tests, Fuzzing und der Prüfung von Fehlerpfaden werden weitere, bislang übersehene Schwachstellen häufiger ans Licht bringen. Das ist eine Einschätzung zur Entwicklung der Sicherheitsarbeit, keine Aussage darüber, wie diese beiden PHP-Lücken entdeckt wurden.

Mehr veröffentlichte Funde bedeuten nicht automatisch, dass Software plötzlich schlechter geworden ist. Sie können auch zeigen, dass vorhandener Code intensiver untersucht wird. Ein veröffentlichter und behobener Fehler ist ein Fortschritt gegenüber demselben Fehler, von dem niemand weiß.

Das macht die Arbeit nicht einfacher. Auch Angreifer können KI-Werkzeuge nutzen. Gleichzeitig sind KI-Berichte nicht automatisch richtig: Ein plausibler Hinweis ist noch kein reproduzierbarer Sicherheitsbefund. Ungeprüfte Meldungen können Maintainer belasten und wichtige Funde im Rauschen verschwinden lassen.

Deshalb brauchen wir beides: bessere Werkzeuge und Menschen, die Ergebnisse validieren. Betroffene Versionen eingrenzen, Voraussetzungen prüfen, einen Fehler reproduzieren und eine Korrektur testen bleibt notwendig. Verantwortliche Meldung und koordinierte Veröffentlichung sind wichtiger als möglichst viele Schlagzeilen.

Sicherheitsbewusstsein muss im Alltag sichtbar werden

„Wir nehmen Sicherheit ernst“ hilft erst, wenn daraus wiederholbare Arbeit wird. Für kleine Teams beginnt das nicht mit einem großen Programm, sondern mit klaren Antworten auf einige praktische Fragen.

1. Wissen wir, was tatsächlich läuft?

Erfassen Sie PHP-Laufzeiten, Erweiterungen, Frameworks, Pakete, Container und vorgeschaltete Dienste mit Version und Verantwortlichen. Webprozesse, Kommandozeile und Hintergrundjobs können unterschiedliche Laufzeiten nutzen. php -v allein belegt nicht, welche Version eine Webanfrage verarbeitet.

2. Können wir dringende Updates wirklich ausrollen?

Legen Sie fest, wer Sicherheitsmeldungen prüft, die eigene Betroffenheit bewertet und dringende Updates freigibt. Testen Sie kritische Abläufe gezielt, rollen Sie die korrigierten Pakete oder neu gebauten Images aus und ersetzen Sie die laufenden Worker kontrolliert. Prüfen Sie anschließend die tatsächlich ausgelieferte Laufzeit. Ein heruntergeladenes Paket ist noch kein behobener Produktivserver.

3. Prüfen wir mehr als Abhängigkeiten?

composer audit ist sinnvoll für bekannte Schwachstellen in Composer-Paketen. Es ersetzt aber weder die Prüfung der PHP-Laufzeit und ihrer Erweiterungen noch die Sicherheitsmeldungen des Betriebssystems. Kombinieren Sie Abhängigkeitsprüfungen mit gepflegten Laufzeiten, Code-Reviews und Tests für Anmeldung, Rechte und Integrationen.

4. Testen wir auch den unangenehmen Weg?

Prüfen Sie nicht nur erfolgreiche Anfragen. Fehlerhafte Uploads, ungewöhnliche Eingaben, abgebrochene Verarbeitung und Fehler beim Aufräumen gehören in eine isolierte Testumgebung. Fuzzing und KI können bei der Suche helfen. Führen Sie solche Tests nicht unkontrolliert gegen Produktionssysteme aus. Sobald ein Fehler bestätigt ist, sollte ein Regressionstest die Korrektur absichern.

5. Begrenzen wir den Schaden eines erfolgreichen Angriffs?

Ein Webprozess braucht nicht automatisch umfassende Dateirechte, sämtliche Zugangsdaten oder freien Zugriff auf jedes interne System. Trennen Sie Verantwortlichkeiten, begrenzen Sie Berechtigungen und halten Sie Secrets aus unnötig erreichbaren Umgebungen heraus. Das behebt keine Laufzeitlücke, kann aber deren Folgen begrenzen.

6. Können wir auf einen Verdacht reagieren?

Sorgen Sie für brauchbare Logs, Monitoring und einen dokumentierten Incident-Ablauf. Fehlende auffällige Logeinträge beweisen nicht, dass ein System sicher ist. Bei Hinweisen auf eine Kompromittierung reicht ein Update allein nicht: Betroffene Systeme müssen untersucht, Zugänge bewertet und gegebenenfalls erneuert werden. Getestete Wiederherstellung gehört ebenfalls dazu.

Weniger Sprachkriege, mehr sichere Systeme

Die richtige Reaktion auf diese PHP-Lücken ist weder Verharmlosung noch Spott. Sie ist: aktualisieren, Betroffenheit prüfen, aus den Fehlerklassen lernen und den eigenen Entwicklungs- und Betriebsprozess verbessern.

Wer PHP einsetzt, sollte es unterstützt und gepflegt betreiben. Wer Rust oder Go einsetzt, ebenfalls. Ein Rewrite beseitigt nicht automatisch die Risiken in Schnittstellen, Berechtigungen und Betrieb. Eine neue Sprache ersetzt keine Sicherheitskultur.

Wenn Sie nicht sicher wissen, welche PHP-Laufzeiten in Ihrem Unternehmen laufen oder wie schnell Sie eine kritische Korrektur ausrollen können, setzen Sie dort an. Unsere PHP-Modernisierung und Anwendungsbetreuung helfen, diese technische und organisatorische Grundlage aufzubauen.

Quellen und Stand

Stand: 22. Oktober 2026. Die genannten PHP-Versionen sind die korrigierten Versionen für diese beiden Lücken, keine dauerhaft gültige Empfehlung für die jeweils neueste Version. Prüfen Sie für aktuelle Maßnahmen die Originalmeldungen und die Hinweise Ihres Paket- oder Hosting-Anbieters.

Im Zusammenhang

5 Verweise