Kontakt

    21. Oktober 2026 6 Min.

    PHP2Shell: Warum der Patchtag nicht mit dem Update endet

    SicherheitWartungServer

    PHP2Shell zeigt, warum ein neues Container-Image noch keinen behobenen Fehler garantiert und selbst am Patchtag schon die nächste Schwachstelle auftauchen kann.

    Das Sicherheitsupdate ist verfügbar, der Container neu gebaut, die Anwendung wieder erreichbar. Fertig? Der Patchtag rund um PHP2Shell am 21. Oktober 2026 zeigt, warum diese Reihenfolge allein nicht reicht. Zwischen einem veröffentlichten Patch und einem tatsächlich geschützten Dienst liegen mehrere Schritte. Und während die einen noch aktualisieren, kann bereits die nächste Schwachstelle bekannt werden.

    Dieser Beitrag ordnet die öffentlich dokumentierten Ereignisse vom 21. Oktober 2026 ein. Die genannten Versionen und Meldungen beschreiben diesen Patchtag, keine dauerhafte Empfehlung für einen bestimmten Softwarestand.

    Was hinter PHP2Shell steckt

    PHP ist die Laufzeitumgebung vieler Webanwendungen. Sie verarbeitet deren Programmcode auf dem Server. Eine Lücke in dieser Grundlage betrifft deshalb nicht nur eine einzelne Website oder ein bestimmtes Zusatzmodul.

    Unter PHP2Shell werden zwei kritische Sicherheitslücken bekannt: CVE-2026-109618 und CVE-2026-109619. Sie können es Angreifern ermöglichen, ohne vorherige Anmeldung eigenen Code auf dem Server auszuführen. Das PHP-Projekt nennt insbesondere Apache mit direkt eingebundenem PHP als hohes Risiko; andere Betriebsarten wie PHP-FPM sind nicht pauschal ausgenommen. Wie ein Angriff gelingt, hängt auch von der konkreten Umgebung ab. Die offizielle Sicherheitsmeldung nennt PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 als korrigierte Versionen der jeweiligen Reihe.

    Die Fehler liegen in der Speicherverwaltung. Bei einem kann die Behandlung von Speichermangel unvollständig vorbereitete Daten in einen unsicheren Zustand bringen. Beim anderen bleiben Verweise auf bereits freigegebenen Speicher für spätere Anfragen erreichbar. Die technischen Einzelheiten beschreiben die Hinweise zu CVE-2026-109618 und CVE-2026-109619.

    Für Betreiber ist zunächst entscheidend: Nicht nur die sichtbare Anwendung muss aktuell sein, sondern auch das PHP darunter. Bei Paketen einer Linux-Distribution kann die Korrektur zurückübertragen worden sein, ohne dass die ursprüngliche PHP-Versionsnummer entsprechend steigt. Dann zählt die Sicherheitsmeldung des Paketlieferanten einschließlich der Paketversion.

    Ein neues Etikett ist noch kein neues PHP

    Ein Container-Image bündelt eine Anwendung mit ihrer Laufzeitumgebung und weiteren Bestandteilen. Ein neuer Name oder ein frisches Erstellungsdatum beweist noch nicht, dass alle Bestandteile aktualisiert wurden.

    Im mailcow-Issue zu PHP2Shell wurde genau das sichtbar. Am frühen Abend meldete ein Nutzer, dass das Image mit dem Tag 8.2.35-1 tatsächlich noch PHP 8.2.34 enthielt. Ein Projektbetreuer bestätigte den Befund: Neue Tags waren bereits sichtbar, beim Testbau wurde aber noch das alte Basis-Image bezogen. Die aktualisierten Images waren zu diesem Zeitpunkt noch nicht bereitgestellt.

    Das beschreibt eine konkrete Zwischenphase dieses Patchtags, nicht den dauerhaften Zustand der mailcow-Updates. Die Lehre daraus bleibt: Wir müssen den Inhalt prüfen, nicht nur das Etikett. Anschließend muss der laufende Dienst auch wirklich aus dem geprüften Image neu erstellt werden. Ein heruntergeladenes Update ersetzt keinen bereits laufenden Container.

    Auch das Basis-Image muss nachziehen

    Beim Drittanbieter-Projekt crazy-max/docker-matomo zeigte sich die Abhängigkeit von einer weiteren Stelle. Im Issue zur Aktualisierung verwies der Betreuer auf die noch benötigten PHP-Pakete von Alpine Linux. Der anschließend zusammengeführte Änderungsvorschlag Nummer 257 stellte auf Alpine Linux 3.24 und PHP 8.5 um.

    Das betrifft dieses konkrete Container-Projekt, nicht pauschal jede Matomo-Installation. Eine zusammengeführte Änderung ist außerdem noch kein Nachweis, welche PHP-Patchversion im ausgelieferten und schließlich gestarteten Image steckt. Zwischen Quellcode, Paketquelle, Image-Bau und laufendem Container kann jeweils ein anderer Stand liegen.

    Deshalb gehört die Versionskontrolle an das Ende der Auslieferung: Welche PHP-Version verarbeitet jetzt tatsächlich die Webanfragen? Eine Versionsausgabe auf dem Docker-Host beantwortet diese Frage nicht, wenn die Anwendung ihr eigenes PHP im Container mitbringt.

    Vom Patch zum laufenden DienstWo das Sicherheitsupdate stecken bleiben kann

    Fünf Stationen. Erst am Ende zeigt sich, ob die Korrektur wirklich im Betrieb angekommen ist.

    1. PHP veröffentlicht den Patch

      Die Korrektur ist verfügbar. Der laufende Dienst ist damit noch nicht aktualisiert.

    2. Der Paketlieferant übernimmt ihn

      Die korrigierte PHP-Version muss in der verwendeten Paketquelle bereitstehen.

    3. Das Container-Image wird gebaut

      Entscheidend ist, welches PHP tatsächlich im Image enthalten ist.

    4. Der laufende Container wird ersetzt

      Das geprüfte Image muss den bisherigen Stand in allen betroffenen Instanzen ablösen.

    5. Den wirksamen Stand nachweisen

      Welches PHP verarbeitet jetzt die Webanfragen? Version und Herstellerhinweis abgleichen.

    Diese Lücken geschlossen. Weitere Meldungen im Blick behalten.

    Auch am Patchtag kann eine andere Schwachstelle bekannt werden. Neue Hinweise prüfen und bei Bedarf erneut aktualisieren.

    Zwei unabhängige Beispiele vom selben Patchtag

    Verschiedene Projekte, getrennte Aktualisierungen. Die Beispiele sind keine aufeinanderfolgenden Schritte desselben Updates.

    docker-matomo

    Das Drittanbieter-Image für Matomo wartete auf die aktualisierten PHP-Pakete von Alpine Linux.

    mailcow-Testbau

    Tag 8.2.35-1, aber noch PHP 8.2.34 im Image: Ein neues Etikett reichte nicht.

    Die beiden Beispiele zeigen Zwischenstände vom 21. Oktober 2026, nicht den heutigen Aktualisierungsstand der Projekte.

    Am Patchtag kann schon die nächste Lücke auftauchen

    Selbst wer das richtige Update eingespielt hat, kann noch am selben Patchtag mit einem neuen Exploit konfrontiert werden. Ein Exploit ist eine konkrete Methode oder ein Programm, das eine Schwachstelle ausnutzt. Ein Sicherheitsupdate behebt bekannte Fehler; es ist kein Nachweis, dass die Software danach keine weiteren enthält.

    Ein Beitrag von elise am selben Nachmittag meldete, dass ein untersuchter Fehler auch unter PHP 8.5.12 noch auslösbar sei. Im vorherigen Verlauf ordnete elise ihn ausdrücklich als andere Schwachstelle ein. Später folgte die Mitteilung, der Befund sei gemeldet worden.

    Diese Meldung müssen wir sauber von den beiden bestätigten PHP2Shell-Lücken trennen. Sie belegt für sich genommen weder einen unter üblichen Serverbedingungen funktionierenden Fernzugriffs-Exploit noch, dass die gerade veröffentlichten Korrekturen wirkungslos sind. Ebenso wenig zeigt sie, dass das Update die weitere Lücke erst eingebaut hat. Ein reproduzierbarer Speicherfehler und eine praktisch ausnutzbare Übernahme des Servers sind nicht dasselbe.

    Der praktische Punkt bleibt trotzdem: Nach dem Update sollte jemand die weiteren Herstellerhinweise verfolgen. Neue Erkenntnisse können zusätzliche Maßnahmen nötig machen, auch wenn die erste Wartung korrekt abgeschlossen wurde. Das ist ein Grund für Nachkontrolle, nicht dafür, ein verfügbares Sicherheitsupdate aufzuschieben.

    Was nach dem Einspielen noch zu prüfen ist

    Wir würden eine solche Wartung erst abschließen, wenn vier Fragen beantwortet sind:

    1. Ist der Fix enthalten? Maßgeblich sind die tatsächliche Laufzeit- oder Paketversion und der zugehörige Sicherheitshinweis, nicht allein der Name des Images.
    2. Läuft der korrigierte Stand? Alle betroffenen Instanzen und PHP-Prozesse müssen die aktualisierte Umgebung verwenden. Ein erfolgreicher Download oder Build genügt nicht.
    3. Funktioniert die Anwendung weiterhin? Anmeldung, Formulare, Hintergrundaufgaben und wichtige Schnittstellen gehören in einen kurzen Funktionstest.
    4. Wer verfolgt die Nachmeldungen? Für weitere Hinweise und notwendige Folgeupdates braucht es eine klare Zuständigkeit, auch nach dem eigentlichen Wartungsfenster.

    Eine geprüfte Datensicherung gehört zur Vorbereitung. Sie macht eine anfällige Installation aber nicht sicher. Ebenso wenig räumt ein Update einen möglicherweise schon erfolgten Einbruch auf. Gibt es Hinweise auf unbefugte Zugriffe, muss dieser Verdacht zusätzlich untersucht werden.

    PHP2Shell ist damit auch ein Beispiel dafür, was laufende IT-Betreuung leisten muss: nicht nur auf „Aktualisieren“ drücken, sondern den wirksamen Stand prüfen und auf neue Erkenntnisse reagieren. Was wir dabei übernehmen, steht unter Webauftritte und deren Betrieb.

    Weiterlesen