Zum Video
Nachhilfe-VermittlungWir helfen helfen. Nachhilfe finden

Erklärvideo · 8 Minuten · Deutsch · kostenlos

PHP2Shell einfach erklärt

Eine Webseite zeigt „Fehler 500“ und bricht ab. Ist danach alles wieder sauber? Dieses Video baut Schritt für Schritt auf, wie aus genau dieser Annahme eine der schwersten Sicherheitslücken des Jahres entsteht — ohne Vorwissen, mit Bildern statt Fachsprache.

8:21 Minuten · Untertitel · Deutsch Auf YouTube ansehen · Video herunterladen · Untertitel (VTT)

Abschrift

Die gesprochene Fassung zum Nachlesen. Ein Klick auf die Zeit springt im Video dorthin.

Eine Webseite antwortet: Fehler fünfhundert. Irgendwas ist schiefgegangen. Die Anfrage ist abgebrochen.

Frage an dich: Ist danach wieder alles sauber? Die meisten sagen ja. Und genau das war zwanzig Jahre lang der blinde Fleck.

Zwei Sicherheitslücken, Oktober zwanzig sechsundzwanzig. Ihr Spitzname: P H P to Shell.

Sie stecken nicht in einem Programm, das jemand schlecht geschrieben hat. Sie stecken im Kern von P H P selbst. Es sind zwei verwandte Fehler; wir bauen hier den Weg des einen Schritt für Schritt auf. Ohne Vorwissen.

Stell dir eine Restaurantküche vor. Vorne im Lokal nimmt der Kellner Bestellungen an. Das ist der Webserver.

In der Küche stehen ein paar Köche. Jeder Koch ist ein Arbeitsprozess. Verwaltet werden sie von einem Programm, das F P M heißt.

Und jetzt der Punkt, auf den alles hinausläuft: Die Köche gehen nach einer Bestellung nicht nach Hause. Derselbe Koch kocht die nächste Bestellung. Und die nächste. Hunderte Male.

Jeder Koch hat eine Werkbank. Darauf liegt alles, was zu dieser einen Bestellung gehört: die Zutaten, die Zettel, die Zwischenergebnisse. Das ist der Anfragespeicher.

Am Ende der Bestellung wird die Werkbank freigegeben. Freigegeben heißt aber nur: Der Platz darf neu vergeben werden. Die Bank selbst bleibt stehen, genau da, wo sie war.

An der Wand hängt noch etwas: ein Notizbrett. Darauf notiert der Koch Dinge, die länger gelten sollen als eine Bestellung.

Zum Beispiel: Die Zutaten für Tisch sieben liegen vorne links auf der Bank. Dieser Zettel ist keine Kopie. Er ist ein Verweis. Er sagt nur, wo etwas liegt.

Im Normalfall läuft das Aufräumen in einer bestimmten Reihenfolge ab. Erst wird der Zettel abgehängt. Dann wird die Bank geräumt.

Diese Reihenfolge ist die ganze Sicherheit. Solange sie stimmt, zeigt nie ein Zettel auf eine Stelle, die schon weg ist.

Jetzt kommt der schwere Fehler. Ein fataler Fehler in P H P ist kein höfliches Rückmelden. Es ist ein Notausgang.

Das Programm springt mitten aus der Arbeit heraus, direkt zum Ausgang. In der Fachsprache heißt dieser Sprung long jump.

Und alles, was zwischen dem Sprung und dem Ausgang gestanden hätte, läuft nicht. Auch nicht der Schritt: Zettel abhängen.

Die Bestellung endet trotzdem. Der Platz auf der Werkbank wird freigegeben — in einem Zug, nicht Stück für Stück. Abgeräumt wird dabei nichts.

Aber der Zettel hängt noch an der Wand. Und er zeigt weiter auf eine Stelle, auf der jetzt nichts mehr liegt. So ein Zettel hat einen Namen: ein hängender Zeiger.

Nächste Bestellung. Derselbe Koch, dieselbe Küche, dieselbe Werkbank.

Er legt neue Zutaten auf die Bank. Freie Plätze werden bevorzugt wieder vergeben, also landen die neuen Zutaten mit guter Chance genau dort, wo vorher die alten lagen. Sicher ist das nicht. Merk dir das, wir kommen darauf zurück.

Dann liest ein Handgriff den alten Zettel. Einer von denen, die PHP bei jeder neuen Anfrage automatisch macht, noch bevor irgendein Programm läuft. Der Zettel sagt: Vorne links liegen die Zutaten für Tisch sieben. Vorne links liegt auch wirklich etwas. Es ist nur nicht das, was der Zettel meint.

Genau das ist der Fehler mit dem englischen Namen Use after free. Benutzung nach dem Freigeben. Das Programm arbeitet weiter mit Speicher, den es längst zurückgegeben hat.

Deshalb braucht ein Angriff zwei Anfragen. Die erste Anfrage legt den Zettel und sorgt für den Absturz. Die zweite Anfrage füllt die Werkbank mit eigenen Daten und lässt den Zettel darauf zeigen.

Und jetzt kommt der Schritt, der aus einem Datenfehler einen Angriff macht. Nicht jeder Zettel sagt nur, wo etwas liegt. Manche sagen: Als Nächstes ist dieses Rezept dran.

Wenn an dieser Stelle die Daten des Angreifers liegen, dann bestimmt er, womit PHP weiterarbeitet. Über mehrere solcher Schritte kann daraus am Ende ein fremder Befehl werden. Wie genau, hängt vom Einzelfall ab. Die Hersteller bewerten es als das Schlimmste, was passieren kann: Der Server führt aus, was von außen kommt.

Zwei Dinge müssen also zusammenkommen: ein Zettel, der zu lange hängt, und ein Koch, der weiterarbeitet. Beides ist Alltag, kein Unfall.

Und damit kommen wir zur wichtigsten Frage überhaupt. Nicht nur bei dieser Lücke, sondern bei jeder: Was muss eigentlich alles zusammenkommen, damit so etwas wirklich ausgenutzt werden kann?

Fünf Dinge. Und zwar alle gleichzeitig. Erstens: ein Zettel, der überhaupt hängen bleibt. Zweitens: ein Fehler, der mitten im Aufräumen herausspringt und dabei die Lücke erst aufreißt.

Drittens: ein Prozess, der danach weiterlebt. Viertens: die nächste Anfrage muss ausgerechnet bei diesem einen Prozess landen. Und fünftens: die eigenen Daten müssen genau auf dem frei gewordenen Platz zu liegen kommen.

Jede einzelne Bedingung ist eine Hürde. So läuft der häufigste Weg, und deshalb gilt der Angriff offiziell als schwierig. Nur: Schwierig ist nicht dasselbe wie unmöglich.

Ein Angreifer darf es zehntausend Mal probieren. Ein Fehlversuch kostet ihn nichts. Ein einziger Treffer kostet dich alles. Genau deshalb ist schwer auszunutzen kein Grund zu warten.

Und hier kommt die Stelle, an der es für Betreiber unangenehm wird. Du denkst jetzt vielleicht: Mein Code hat gar keinen fatalen Fehler.

Das muss er auch nicht. Der Angreifer bringt den Fehler mit. Er stellt eine Anfrage so, dass P H P beim Einlesen der Anfrage der Speicher ausgeht. Speicher voll ist auch ein fataler Fehler.

Dieses Einlesen passiert, bevor die erste Zeile deines Programms läuft. Und wo das nicht reicht, genügt eine ganz alltägliche Stelle im Programm: eine Sitzung, die geladen wird, ein gespeicherter Wert, der ausgepackt wird. Nichts davon ist ein Fehler in deinem Code.

Dazu kommt eine Funktion, die seit Jahren in fast jeder Standard-Einstellung an ist: der Fortschrittsanzeiger beim Hochladen von Dateien. Er arbeitet schon während des Einlesens. Deshalb ist er in diesen Lücken der erste, der auf den alten Zettel schaut.

Noch ein verbreiteter Irrtum, und der ist wichtig. Viele Server zeigen Fehler nicht an. Die Anzeige ist aus, der Besucher sieht nur eine höfliche Seite.

Das hilft hier nichts. Die Anzeige entscheidet nur, was der Besucher liest. Der Zettel bleibt trotzdem hängen. Der Schaden passiert innen, nicht am Bildschirm.

Was hilft, ist eine einzige Sache: das Update. P H P acht Punkt fünf Punkt zwölf, acht Punkt vier Punkt siebenundzwanzig, acht Punkt drei Punkt sechsunddreißig, acht Punkt zwei Punkt fünfunddreißig.

Alles andere verkleinert nur die Trefferfläche. Den Fortschrittsanzeiger abschalten nimmt einen Weg weg, nicht den Fehler. Es gibt noch andere, die auf den Zettel schauen.

Und ein Filter davor, eine Schutzmauer im Netz, muss erkennen, was er sieht. Dieser Angriff sieht aber aus wie ganz normaler Verkehr. Dazu kommt: Wer die Adresse des Servers kennt, kann an der Mauer vorbeigehen, solange der Server direkte Zugriffe überhaupt annimmt.

Deshalb haben in diesen Tagen Städte, Kliniken und Behörden ihre Seiten freiwillig abgeschaltet. Nicht weil sie angegriffen wurden. Sondern weil Abschalten schneller ging als Patchen.

Drei Dinge zum Mitnehmen, und die gelten weit über P H P hinaus.

Erstens: Wo Prozesse wiederverwendet werden, überlebt Zustand länger, als man denkt. Zweitens: Der Fehlerpfad ist Teil der Sicherheit, nicht ein Randfall. Drittens: Code, der scheinbar nie erreicht wird, ist die liebste Abkürzung eines Angreifers.

Wenn dir das Video beim Verstehen geholfen hat: Genau so erklären wir auch Mathe, Physik und Informatik.

Wir helfen helfen. Nachhilfe-Vermittlung Punkt com.

Die Eckdaten zum Nachschlagen

Betroffen
PHP im Kern — unabhängig davon, welches Programm darauf läuft.
Behoben in
PHP 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 (veröffentlicht am 21. Oktober 2026)
Kennungen
CVE-2026-109618 und CVE-2026-109619, zusammen „php2shell“ genannt
Schwere
9,2 von 10 — bei gleichzeitig als hoch bewerteter Angriffskomplexität
Primärquellen
GHSA-6wmf-4rv5-p3rp · GHSA-w8hw-w9fx-j79w · php.net

Was dieses Video bewusst nicht zeigt: Es erklärt die Ursache und die Wirkungskette, damit verständlich wird, warum ein Update dringend ist. Es zeigt keine Angriffsdaten und keine Anleitung. Wer eine eigene Seite betreibt: die PHP-Version aktualisieren — alles andere verkleinert nur die Trefferfläche.

Dieses Video darfst du benutzen

Für Unterricht, Ausbildung und Schulungen frei verwendbar — herunterladen, zeigen, weitergeben. Eine Quellenangabe freut uns, ist aber keine Bedingung.

Wir sind eine Vermittlung für Nachhilfe. Genau so erklären wir auch Mathe, Physik und Informatik: so lange, bis es sitzt.

Passende Nachhilfe finden Auf YouTube ansehen und teilen