Die PHP-Lücke,
ohne den Lärm.

01 — Erste Frage

Bist du betroffen?

Nicht raten, nachsehen. Zwei Befehle genügen. Der erste zeigt deine Version, der zweite, ob der bekannteste Angriffspfad bei dir offensteht.

# Welche Version läuft?
php -v

# Ist eine riskante Funktion eingeschaltet? (On heißt: ja)
php -i | grep upload_progress

Gepatcht ab

Jede PHP-Version der letzten rund zehn Jahre ist betroffen. Sehr alte Versionen wie 7.x und 5.x bekommen gar kein Update mehr. Für sie gilt der Abschnitt weiter unten.

02 — Was passiert da

Der Fehler, einfach erklärt.

Wenn PHP beim Abarbeiten einer Anfrage plötzlich der Speicher ausgeht, bricht es mitten in der Arbeit ab. Dabei bleibt ein Durcheinander zurück: halb fertige Daten und Verweise, die ins Leere zeigen. Die nächste Anfrage stolpert dann über dieses Durcheinander. Ein Angreifer kann es gezielt so vorbereiten, dass dabei sein eigener Code läuft oder geheime Daten nach außen fallen.

03 — Wie gefährlich ist das?

Was alles passen muss.

Der spektakuläre Fall aus den Videos funktioniert nur, wenn sechs Dinge gleichzeitig zutreffen. Drei davon sind die normale Standardeinstellung. Drei weitere muss die betroffene Seite zusätzlich mitbringen, und das tun die wenigsten. Ernst, ja. Aber kein Ein-Klick-Hack, der überall klappt.

Die Begriffe oben sind Server-Einstellungen. Wichtig ist nur: die rechte Spalte ist selten komplett erfüllt.

Am zuverlässigsten vorgeführt wurde der Angriff auf der klassischen Apache-Variante (mod_php). PHP-FPM ist über einen eigenen Pfad ebenfalls betroffen. Wie leicht es gelingt, hängt von Version und Betriebsart ab. Die Entdecker nennen bestätigte Treffer ohne Login in gängiger Software wie WordPress, Drupal, Joomla, MediaWiki, Nextcloud und phpMyAdmin unter Standardeinstellungen. Keine Betriebsart ist also außen vor.

04 — Kannst du nicht sofort updaten?

Was du sonst tun kannst.

Ein Update ist fast immer der einfachste Weg. Diese Liste ist für den Fall, dass es gerade nicht geht. Das Problem hat zwei Seiten, und die ersten beiden Punkte treffen je eine davon an der Wurzel. Keiner der Punkte schützt vollständig. Sie machen es dem Angreifer nur schwerer, bis du updaten kannst.

1. memory_limit = -1 stärkster Hebel

   Nimmt dem Fehler die Grundlage. Der gefährliche Abbruch passiert, wenn PHP beim knappen Speicher mitten in einer Aktion aufgibt. Ohne dieses Limit gibt es diesen Abbruch nicht mehr. Wichtig: Auf geteilten Servern (Shared Hosting) kann dann eine einzige Anfrage sehr viel Speicher ziehen. Nur setzen, wenn der Server dir allein gehört oder der Speicher anders begrenzt ist.

2. session.upload_progress.enabled = 0

   Schaltet eine Funktion ab, die kaum jemand braucht und die die zweite Seite des Problems öffnet. Danach die PHP-Prozesse neu starten.

3. fatal_error_backtraces = 0

   Nur bei PHP 8.5. Nimmt einen weiteren Einstieg weg. Prozesse neu starten.

4. pm.max_requests kleiner setzen

   Lässt den Server seine Arbeits-Prozesse öfter frisch starten. So überlebt kein Durcheinander von einer Anfrage zur nächsten.

5. Datei-Uploads abweisen, wenn deine Seite keine braucht

   Solche Anfragen (Fachbegriff: multipart) schon vom Webserver mit einer Fehlermeldung ablehnen. Hilft zusätzlich, ersetzt aber Punkt 1 nicht.

6. PHP-Grenzen enger stellen

   Maximale Upload-Größe klein halten, die erlaubte Verschachtelung von Eingaben senken, die Zahl der Teile pro Anfrage begrenzen. Auch das nur als Ergänzung.

7. Einen verbreiteten Tipp NICHT befolgen

   Harte Speicher-Grenzen auf Betriebssystem-Ebene (RLIMIT_AS, RLIMIT_DATA) machen das Problem schlimmer statt besser. Finger weg.

05 — Woran du einen Versuch erkennst

Die Warnzeichen.

Die Angriffe spielen sich tief im Server ab, nicht in deiner Anwendung. In den normalen Besucher-Logs deiner Seite steht deshalb wenig. Schau in die Protokolle von Webserver und PHP.

06 — Zum Nachdenken

Wie der Tag ablief.

Die Lücke war echt und wurde ordentlich gemeldet. Trotzdem wurde eine Panikwelle daraus. Hier, woran du erkennst, wem du glauben kannst.

• Monate vorherDie Lücken werden gefunden und im Stillen an PHP gemeldet. Ein außerplanmäßiges Update wird vorbereitet.
• 20.10. ~15:00Das Leck. Jemand postet die beiden Nummern, eine falsche Uhrzeit und einen zu hohen Gefahrenwert. Noch keine technischen Details.
• 20.10. abendsPHP zieht die Ankündigung vor und verschiebt das Update um einen Tag nach vorn. Ein Entdecker-Video wird versehentlich veröffentlicht und wieder gelöscht, Kopien verbreiten sich.
• 21.10. frühEin Anbieter stellt die Reparatur über sechs Stunden zu früh online. Die offiziellen Nummern und erfundene Details vermischen sich im Netz.
• 21.10. 14:00Die offizielle Reparatur erscheint. Sie bestätigt den Kern, nicht die Show drumherum. Die PHP Foundation findet zu diesem Zeitpunkt keine funktionierenden Angriffswerkzeuge im Umlauf.

Primärquellen

Zum Selberlesen.

Kein Angriffscode, keine Links zu Werkzeugen. Nur das, womit du dir selbst ein Bild machst.