--- title: "PHP2Shell: Ursachen und Behebungsanleitung" description: "Verstehen Sie PHP2Shell-Lebenszyklusfehler, Laufzeit-Upgrades, vorübergehende Abhilfemaßnahmen, Patch-Auswahl und Überprüfung über den Live-Web-Anfragepfad." language: "de" url: "https://keendigit.com/de/insights/php2shell-remediation-guide" author: "KeenDigit" published: "2026-10-22" --- # PHP2Shell: Ursachen und Behebungsanleitung Verstehen Sie PHP2Shell-Lebenszyklusfehler, Laufzeit-Upgrades, vorübergehende Abhilfemaßnahmen, Patch-Auswahl und Überprüfung über den Live-Web-Anfragepfad. **Quellen überprüft am 22. Oktober 2026.** **Zielgruppe: PHP Anwendungsbetreiber, Sicherheitsbeauftragte und Ingenieure, die benutzerdefinierte PHP-Builds verwalten.** Dieser Artikel fasst die Ursache, den Umfang der Auswirkungen, den formellen Reparaturprozess, vorübergehende Abhilfemaßnahmen und die offizielle Patch-Implementierung der PHP2Shell-Schwachstelle zusammen. Der Haupttext wird mit Nummern wie [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1) zitiert; Alle Quellenlinks sind im Anhang am Ende des Textes aufgeführt. Das Konfigurationsfragment ist eine Bereitstellungsvorlage, die basierend auf der tatsächlichen Version, der Geschäftskapazität und der Konfigurationsvererbungsbeziehung angepasst werden muss. ## TL;DR: Reparaturschritte und Vorschläge 1. **Upgrade der PHP-Laufzeit**: Aktualisieren Sie den relevanten Zweig auf mindestens **8.2.35, 8.3.36, 8.4.27 oder 8.5.12**. Verwenden Sie für Distributionspakete die vollständige Paketversion, von der der Anbieter bestätigt, dass sie beide CVEs behebt. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S10](https://keendigit.com/de/insights/php2shell-remediation-guide#source-10) 2. **Ersetzen Sie alle alten Prozesse**: Starten Sie alle PHP worker, Hosting-Dienste und Container nach dem Upgrade neu oder führen Sie einen Rollover durch und bestätigen Sie, dass alte Instanzen beendet wurden. 3. **Überprüfen Sie den tatsächlichen Web-Anforderungspfad.**: Überprüfen Sie Web SAPI, die vollständige Paketversion und die laufende Instanz. Die alleinige Überprüfung von `php -v` stellt nicht sicher, dass der Live-Dienst repariert ist. 4. **Führen Sie geschäftliche Regressionsprüfungen durch und stellen Sie normale Ressourcenbudgets wieder her**: Testanmeldung, Sitzungsverwaltung, Uploads, Importe und Fehlerbehandlung. Wenn das Speicherlimit PHP vorübergehend aufgehoben wurde, stellen Sie nach dem Patchen ein entsprechendes endliches Budget wieder her. 5. **Wenn ein sofortiges Upgrade nicht möglich ist**: Beschränken Sie nicht vertrauenswürdigen Datenverkehr, bevor er PHP erreicht. Bewerten Sie die Deaktivierung des Upload-Fortschritts und der schwerwiegenden PHP 8.5-Backtraces, wie in Abschnitt 5 beschrieben. Konfigurationsminderungen und WAF-Regeln haben eine begrenzte Abdeckung und können ein Upgrade nicht ersetzen. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) ## 1. Schwachstellenübersicht und Risikobeurteilung PHP2Shell bezieht sich in diesem Artikel auf zwei Schwachstellen der Stufe Critical, die von PHP am 21. Oktober 2026 offiziell bekannt gegeben wurden. Beide stehen im Zusammenhang mit der Speicher- und Anforderungslebenszyklusverwaltung der PHP-Engine und bergen das Risiko einer nicht authentifizierten Remotecodeausführung. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) | Projekt | CVE-2026-109618 | CVE-2026-109619 | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | offizieller Name | RCE via OOM corruption | RCE via stale global state | | Kernthemen | Unzureichender Speicher führt zu einem abnormalen Sprung und hinterlässt einen Zustand, in dem die Initialisierung noch nicht abgeschlossen ist. | Der im Worker verbleibende globale Status verweist auf den freigegebenen Anforderungsspeicher. | | Typischer Auftrittszeitpunkt | Der Initialisierungs-, Ausführungs- oder Bereinigungsprozess der aktuellen Anfrage | Die vorherige Anfrage verlässt den Status und nachfolgende Anfragen verbrauchen ihn im Voraus. | | Ist OOM eine notwendige Bedingung? | Gehört zum zentralen Auslösemechanismus der Sicherheitslücke | Nein; Andere schwerwiegende Fehler und Bereinigungen nach der Diagnose können ebenfalls beteiligt sein | | Grundlegende Reparaturrichtung | Behandeln Sie Zuordnungsfehler und Anforderungsbeendigung sicher | Korrigieren Sie die Staatseigentümerschaft, den Zeitpunkt der Bereinigung und die frühe Initialisierung | | Entsorgungspflichten | muss repariert werden | muss gleichzeitig repariert werden | Grundlage: Zwei offizielle Sicherheitsbulletins und Fixeinreichungen. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/de/insights/php2shell-remediation-guide#source-4) ### 1.1 Informationen zu betroffenen Bereitstellungen PHP betrachtet offiziell **alle PHP-Bereitstellungen, die Web-Anfragen** verarbeiten, als gefährdet, einschließlich PHP-FPM, Apache mod\_php, php-cgi, FrankenPHP und LiteSpeed. Der demonstrierte mod\_php-Angriff kann stattfinden, bevor Anwendungscode ausgeführt wird, sodass Anmeldeprüfungen, Framework-Middleware und Anwendungs-Upload-Validierung diesen Weg nicht abdecken können. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1) Es muss zwischen „Bereitstellung muss behoben werden“ und „Eine bestimmte Angriffskette wurde vollständig nachgewiesen“ unterschieden werden. Ankündigung von CVE-2026-109618: FPM verlässt den untergeordneten Prozess, nachdem der Start der Anforderung fehlgeschlagen ist, und blockiert den entsprechenden Bereinigungspfad von mod\_php nach dem Startfehler. Allerdings ist der OOM-Pfad nach erfolgreichem Start immer noch gefährdet. In der Ankündigung wird außerdem darauf hingewiesen, dass der vollständige FPM-Exploit für diesen CVE noch nicht demonstriert wurde. Aus dieser Einschränkung kann nicht abgeleitet werden, dass FPM sicher ist, insbesondere kann CVE-2026-109619 nicht ignoriert werden. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) Die unmittelbaren Berechtigungsgrenzen für eine erfolgreiche Ausnutzung hängen von der Identität des Prozesses ab, der PHP hostet, und den Ressourcen, auf die er Zugriff hat. Im Allgemeinen sollte auf den Website-Code, das Upload-Verzeichnis, die Datenbankanmeldeinformationen, die Service-Tokens und die internen Netzwerkzugriffsfunktionen geachtet werden. „Remote-Code-Ausführung“ bedeutet nicht, natürlich Root-Berechtigungen zu erhalten. Die Folgenbeurteilung basiert hier auf dem Prozessberechtigungsmodell, und die tatsächlichen Auswirkungen müssen in Verbindung mit Bereitstellungsberechtigungen bewertet werden. Gewöhnliche einmalige CLI-Skripte haben nicht denselben HTTP-Eintrag; Prozesse, die im CLI oder im Embedded-Modus über längere Zeit externe Aufgaben erledigen, sollten aber dennoch in die Laufzeit- und Lebenszyklusinventur einbezogen werden. Nur die CMS-, Framework- oder Composer-Abhängigkeiten werden aktualisiert und die zugrunde liegende PHP-Engine wird nicht automatisch ersetzt. ## 2. Ursachenanalyse ### 2.1 Verstehen Sie zunächst die beiden Lebenszyklen PHP worker bearbeitet oft mehrere Anfragen nacheinander. Der während der Anfrage zugewiesene Speicher kann am Ende der Anfrage einheitlich freigegeben werden, während der Worker selbst und einige seiner globalen Felder weiterhin bestehen bleiben. Daher muss die Engine zwei Einschränkungen einhalten: - **Initialisierungsbeschränkung**: Für andere Codes sichtbare Daten müssen in einem Zustand sein, der sicher gelesen, durchlaufen und zerstört werden kann. - **Lebenszyklusbeschränkung**: Sobald der Anforderungsspeicher freigegeben wurde, dürfen langlebigere Felder Adressen in diesem Speicher nicht mehr als gültigen Zustand behandeln. Diese beiden Einschränkungen entsprechen den Hauptfehlermodi der beiden Schwachstellengruppen. Der folgende Prozess ist eine Mechanismusbeschreibung, die Ankündigungen und Patch-Kompilierung kombiniert. Dies bedeutet nicht, dass jede Bereitstellung genau den gleichen erreichbaren Pfad hat. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) ### 2.2 CVE-2026-109618: OOM hat eine nicht abgeschlossene Statusaktualisierung unterbrochen Die alte Implementierung verwendet einen nicht lokalen Sprung vom Typ `longjmp()`, um OOM zu verarbeiten, und der zugehörige Pfad verlässt den aktuellen Ausführungskontext über `zend_bailout()`. Die Gefahr besteht darin, dass ein Teil des C-Codes möglicherweise ein neues Objekt, Array oder einen neuen Anforderungsstatus für anderen Code veröffentlicht hat, aber noch nicht die gesamte Feldinitialisierung abgeschlossen hat. Zu diesem Zeitpunkt kann ein Zuordnungsfehler zum relevanten Zeitpunkt dazu führen, dass die normalen Abschlussschritte übersprungen werden. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2) Der Fehlerprozess kann in vier Schritte unterteilt werden: 1. Erstellen oder aktualisieren Sie die interne Struktur der Anfrage und machen Sie sie zugänglich. 2. Die nachfolgende Speicherzuweisung schlägt fehl und OOM wird ausgelöst. 3. Der Ausführungsablauf springt von der aktuellen Funktion weg und der Code, der ursprünglich zum Abschließen der Initialisierung oder zum Wiederherstellen des Status verwendet wurde, wird nicht ausgeführt. 4. Die Anforderungsbereinigung verarbeitet diese Strukturen weiter und behandelt ungültige Inhalte als gültige Felder oder Adressen. Das Problem besteht nicht darin, dass Speichermangel immer RCE verursacht. Vielmehr ändert die Speichererschöpfung **den Kontrollfluss und verstößt gegen die Annahmen der Engine über gültige Strukturen**. Die fehlgeschlagene Zuordnung muss nicht direkt die Struktur betreffen, die letztendlich falsch gelesen wird. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2) #### Warum auch bei kleineren Anfragen der Speicher knapp werden kann Die Anzahl der Bytes im Anforderungstext und die Heap-Nutzung nach dem Parsen sind nicht dasselbe. Das Feld A kann mehreren Zeichenfolgen, Array-Elementen und Metadatenobjekten innerhalb von PHP entsprechen. Die strukturelle Komplexität der Eingabe wirkt sich auf den Grad der Speicherverstärkung aus. Zu den in der offiziellen Ankündigung aufgeführten Problemen mit Multipart gehören: Lücke bei der anfänglichen Größenprüfung, wenn die verfügbare Deklarationslänge fehlt, die Anzahl der Header für einen einzelnen Teil nicht ausreichend begrenzt ist und leere Dateisteuerelemente weiterhin Metadaten erzeugen, wobei verschachtelte Namen die Array-Arbeitsbelastung weiter erhöhen. Die anwendungseigene Abwicklung, Dekodierung oder Neuzuweisung von Eingaben kann ebenfalls eine Quelle für OOM sein. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2) Daraus lassen sich zwei schützende Schlussfolgerungen ziehen: - Vor der Eingabe von PHP müssen die Einschränkungen des Anforderungstexts so weit wie möglich implementiert werden, und die tatsächliche Leselänge und die strukturelle Komplexität müssen berücksichtigt werden. - Eine individuelle Begrenzung der Dateigröße, der Anzahl der Dateien oder das Schließen nur eines Upload-Portals kann nicht alle OOM-Quellen abdecken. #### Warum die Anwendungsauthentifizierung möglicherweise zu spät ist In mod\_php kann der Anforderungstext während der Anforderungsinitialisierungsphase automatisch analysiert werden. Selbst wenn der Start fehlschlägt, wird die entsprechende Anforderungsbereinigung dennoch durchgeführt. Bestätigte Angriffspfade können daher vor Anwendungscode auftreten. Um die Gefährdung in dieser Phase zu verringern, müssen Einschränkungen am Reverse-Proxy, am Web-Server oder an einer anderen Grenze vorgenommen werden, die der PHP-Anforderungsverarbeitung vorausgeht. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2) ### 2.3 CVE-2026-109619: Der Anforderungsspeicher wurde freigegeben, die globale Referenz ist noch aktiv Bei diesem Problem handelt es sich um einen Fehler-, Sitzungs-, Objekt- oder Erweiterungsstatus: Das Feld wird an einem Worker-Langzeitzugriffsspeicherort gespeichert, aber die Daten, auf die das Feld verweist, gehören zu einer einzelnen Anfrage. Solange die Referenz nicht ordnungsgemäß bereinigt wird, bevor der Anforderungsheap freigegeben wird, kann es bei nachfolgenden Anforderungen zu einem Dangling-Zustand kommen, der zu einer Verwendung nach dem Freigeben führt. [S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) Die offizielle Analyse unterteilt die Ausbeutungsbedingungen in „Produzenten“ und „Konsumenten“: | Rolle oder Bedingung | Bedeutung | Auswirkungen auf den Schutz | | ------------------------------ | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | Staatsproduzent | Legen Sie den Staat, der dieser Anfrage gehört, an einem Ort ab, auf den später noch zugegriffen werden kann | Um zu überprüfen, ob die entsprechende Bereinigung nach einem abnormalen Beenden abgeschlossen ist | | Status bleibt bestehen | Es wurde nicht geräumt, oder es wurde durch eine verspätete Operation geräumt und dann wieder aufgefüllt. | Es reicht möglicherweise nicht aus, nur einmal in der früheren Phase des Herunterfahrens zu löschen | | Wiederverwendung von Arbeitern | Derselbe Worker verarbeitet weiterhin nachfolgende Anfragen | Bei mehreren Workern handelt es sich lediglich um einen Planungsunterschied, nicht um eine Garantie für die Speichersicherheit | | Vorabverbraucher | Den Restwert lesen, freigeben oder ermitteln, bevor der entsprechende Zustand normal initialisiert wird. | Vor der Initialisierung müssen INI, Sitzung und andere Pfade überprüft werden | Diese Bedingungen müssen in Kombination erfüllt sein; Ein Fehlerprotokoll allein beweist nicht, dass die Sicherheitslücke erfolgreich ausgenutzt wurde. [S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) #### OOM ist nicht als notwendige Voraussetzung erforderlich Schwerwiegende Fehler können die Veröffentlichung und Wiederherstellung des gepaarten Zustands unterbrechen. Kompilierungs- oder Analysefehler, nicht erfasste Fehler, `require`-Fehler und Ausführungszeitüberschreitungen können bestimmte Zustände zurücklassen. Eine nicht schwerwiegende Diagnose zu einem späten Zeitpunkt der Bereinigung kann auch bereits gelöschte Fehlerinformationen erneut auffüllen. [S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) Daher deckt die Änderung von `memory_limit` in „unbegrenzt“ diese Schwachstellen nicht ab. #### „Vor der Initialisierung“ muss separat behandelt werden Der Zeitpunkt der beiden Arten bestätigter Verbraucher ist unterschiedlich: - **Frühe INI-Diagnose**: Einige auf Anfrage angewendete Konfigurationen geben vor der normalen Executor-Initialisierung eine Warnung, einen Hinweis oder eine veraltete Version aus, und die Diagnoseverarbeitung greift möglicherweise auf den alten Fehlerstatus zu. - **Session-Upload-Fortschritt**: Die Sitzung wird möglicherweise im Voraus während des Analysevorgangs des Anforderungstexts verarbeitet, aber das reguläre Modul `RINIT` wurde noch nicht abgeschlossen. Es kann nicht gefolgert werden, dass der Pfad nicht existiert, da die Anwendung `session_start()` nicht explizit aufruft. [S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) Nicht alle INI-Konfigurationen haben den gleichen Risikozeitpunkt. Die vom FPM-Frontend übergebene Konfiguration auf Verzeichnisebene von mod\_php und `PHP_VALUE` / `PHP_ADMIN_VALUE` muss von der gewöhnlichen Startkonfiguration `php.ini`, FPM pool und FPM `.user.ini` unterschieden werden. Letztere haben unterschiedliche Konfigurationszeitpunkte und können nicht gemeinsam als dieselben frühen Verbraucher bezeichnet werden. [S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) Das Ausschalten von `display_errors`, `log_errors`, das Reduzieren von `error_reporting` oder die Verwendung von `@` wirkt sich nur auf die Sichtbarkeit der Diagnose aus; Möglicherweise wurde auf den relevanten internen Status zugegriffen, bevor entschieden wurde, ob das Protokoll ausgegeben werden soll. [S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) ## 3. Reparaturversion und Patchauswahl ### 3.1 Offizielle Upstream-Fix-Baseline | Aktueller Zweig PHP | Die erste Version, die diesen offiziellen Fix enthält | Vorschläge | | ------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | 8.2 | 8.2.35 | Führen Sie ein Upgrade auf diese Version oder eine Folgeversion durch, die dieselben Korrekturen enthält | | 8.3 | 8.3.36 | Das Gleiche wie oben | | 8.4 | 8.4.27 | Das Gleiche wie oben | | 8.5 | 8.5.12 | Das Gleiche wie oben | | 8.1 und frühere Versionen | Der allgemeine Upstream-Support ist beendet | Priorisieren Sie die Migration zu unterstützten Zweigstellen. Kurzzeit-Check-Release oder LTS-Hersteller-Backport | Die Version und der Supportstatus basieren auf der offiziellen Ankündigung von PHP und die Zeitbasis ist der 22. Oktober 2026. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1) Dies sind **zweigspezifische Fixschwellenwerte**. Sie können nicht durch die Aussage ersetzt werden, dass jede Version unterhalb von 8.5.12 anfällig ist: Versionen wie 8.2.35 und 8.4.27 in anderen Zweigen enthalten die Fixes bereits. ### 3.2 Überprüfen Sie die vollständige Version des Distributionspakets Distributionen fügen oft Sicherheitsfixes hinzu, die auf älteren Upstream-Versionen basieren. Bei der Annahme sollten auch die Release-Version, die Repository-Quelle, die vollständige Paketversion und das Sicherheitsbulletin überprüft werden. Die für Ubuntu USN-8948-1 aufgeführte Fixpaketversion Ubuntu 24.04 LTS lautet beispielsweise: ```text 8.3.6-0ubuntu0.24.04.13 ``` Der Upstream-Teil ist immer noch `8.3.6`, aber die vollständige Paketversion dieser Distribution ist in dieser Fixankündigung enthalten. Diese Schlussfolgerung gilt nur für die entsprechende Distribution und Paketquelle und kann nicht auf einen Build verallgemeinert werden, der auch `8.3.6` anzeigt. [S10](https://keendigit.com/de/insights/php2shell-remediation-guide#source-10) ### 3.3 Den richtigen Patch auswählen | Szene | Prioritätsplan | Wichtige Punkte für die Akzeptanz | | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Verwendung des Distributionspakets PHP | Installieren Sie vom Hersteller veröffentlichte Sicherheitsupdates | Die Ankündigung betrifft sowohl CVE; Die vollständige Paketversion ist korrekt | | Verwenden Sie den offiziellen PHP-Container oder ein selbst erstelltes Image | Aktualisieren Sie die Basislaufzeit, erstellen Sie sie neu und stellen Sie sie bereit | Die laufende Instanz verwendet das neue Image; alle alten Kopien werden verlassen | | Selbstkompilierte unterstützte Zweige | Verwenden Sie die offizielle Sicherheitsversion dieses Zweigs oder das vollständige offizielle Patch-Set | Zweigabgleich, Abhängigkeitsvervollständigung, Erweiterungskompatibilität und Regressionsübergabe | | Vorbehaltlich 7.4, 8.0, 8.1 | Priorisieren Sie den Anbieter-Backport; Evaluieren Sie bei Bedarf den offiziellen Notfall-Quellcode-Zweig | Identifizieren Sie Verhaltensänderungen und planen Sie die Migration auf unterstützte Versionen | Offizielle Patches wurden veröffentlicht und die eigentlichen Korrekturen sollten mit diesen Patches beginnen. Die Codeausschnitte in Abschnitt 6 dienen der Veranschaulichung von Entwurfs- und Überprüfungshighlights und stellen keinen vollständigen Patch dar, der unabhängig angewendet werden kann. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/de/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/de/insights/php2shell-remediation-guide#source-6) ## 4. Formaler Reparaturprozess ### 4.1 Inventar der Laufzeit, die tatsächlich Anfragen verarbeitet Es wird empfohlen, ein Kurzbuch zu erstellen, um mindestens Folgendes aufzuzeichnen: - Eintragsdomänenname oder -dienst, Reverse-Proxy-Backend, PHP SAPI. - PHP-Zweig, vollständige Paketversion oder Image-Digest, Build-Quelle. - FPM pool, tatsächliche Serviceeinheit, Container oder Pod, Anzahl der Replikate. - Erweiterungen, Hauptkonfiguration und zusätzliche Konfigurationsdateien wurden geladen. - Gibt es andere PHP-Versionen, alte Bereitstellungskopien oder Ursprungsportale, auf die direkt zugegriffen werden kann? Hierbei handelt es sich um Implementierungsvorschläge, sodass „aktualisiert“ jedem tatsächlichen Verkehrseintrag entsprechen kann. Überprüfen Sie insbesondere, ob die Befehlszeilen PHP und Web PHP unterschiedliche Versionen verwenden, das Image erstellt wird, der alte Container jedoch noch läuft, ein Teil des Pools oder die Kopie nicht ersetzt wird usw. ### 4.2 Wählen Sie das richtige Update aus und stellen Sie es bereit Bestätigen Sie die Fixversion gemäß Abschnitt 3, vorzugsweise mithilfe einer vorhandenen vertrauenswürdigen Paketquelle oder einer kontrollierten Build-Kette. Der Aktualisierungsbereich sollte die Komponente umfassen, die die Anforderung tatsächlich hostet, z. B. das FPM-Paket, das Apache PHP-Modul, die CGI-Binärdatei oder den Dienst-Build, in den PHP eingebettet ist. Bewahren Sie vor dem Upgrade die Konfiguration und die Paketliste auf und überprüfen Sie den Start und die wichtigsten Dienste in einer produktionsähnlichen Umgebung. Überprüfen Sie bei selbstverwalteten Erweiterungen die Build- und Ausführungskompatibilität entsprechend der Version PHP. Die bloße Auswahl eines scheinbar relevanten Commits aus einem anderen Zweig garantiert nicht, dass alle Korrekturen implementiert wurden. ### 4.3 Starten Sie laufende Instanzen neu oder führen Sie ein Rollover durch Das Installieren einer Datei und das Laden von neuem Code in einen Prozess sind zwei verschiedene Dinge. Der entsprechende Dienst sollte neu gestartet oder der fortlaufende Austausch abgeschlossen werden und der alte Worker und der alte Container sollten als beendet bestätigt werden. Starten Sie für mod\_php den Apache-Prozess neu, der das Modul hostet. Bei Diensten, die PHP einbetten, muss der Hosting-Prozess ersetzt werden. Für FPM ersetzt das Löschen von OPcache nicht die Aktualisierung der Laufzeit und die Einstellung alter Worker. Wenn Sie Graceful Switching verwenden, müssen Sie prüfen, ob der Prozess der alten Generation noch lange Verbindungen oder ausstehende Anfragen verarbeitet. Der Abnahmedatensatz sollte den tatsächlichen Dienst, die Bereitstellungsversion, den Zeitpunkt des Abschlusses der Änderung und die Exit-Ergebnisse der alten Instanz enthalten. ### 4.4 Überprüfung durch echte Web-Anfragen Es wird empfohlen, die folgenden Beweise zu kombinieren, anstatt sich ausschließlich auf einen einzelnen Versionsbefehl zu verlassen: | Beweise | Was kann bewiesen werden | Allein kann man nichts beweisen | | --------------------------------------------------------------------- | ----------------------------------------------------- | --------------------------------------------------- | | Paketmanager oder Bildmetadaten | Installationsquellen und vollständige Builds | Der Datenverkehr wurde auf diese Instanz umgeleitet | | Prozess- und Bereitstellungsstatus | Der Arbeiter oder Container schließt den Austausch ab | Der Außeneingang muss dorthin geführt werden | | Eingeschränkter Zugriff auf Diagnoseergebnisse über ein echtes Portal | Tatsächliche Web SAPI und laufende Konfiguration | Ob der Release-Backport zwei CVE abdeckt | | Herstellerankündigung oder vollständige Patchaufzeichnung | Dieser Bugfix ist in diesem Build enthalten | Alle Replikate werden bereitgestellt | `PHP_VERSION`, `PHP_SAPI`, geladene Konfigurationsdateien und Notfallkonfigurationen können über vorhandene interne Diagnosefunktionen oder temporäre und zugriffskontrollierte Diagnoseportale überprüft werden. Stellen Sie sicher, dass die Anfrage nicht direkt von CDN oder dem Seitencache zurückgegeben wird. Entfernen Sie den temporären Diagnoseeintrag, wenn Sie fertig sind. `php -v` gibt normalerweise nur die Binärdatei CLI an, die aktuell von der Shell ausgewählt wird; Befehle wie `php-fpm -i` sind nicht gleichbedeutend mit der Überprüfung des vorhandenen Workers, der Datenverkehr empfängt. Setzen Sie die gesamte `phpinfo()`-Seite nicht über längere Zeit dem öffentlichen Netzwerk aus. ### 4.5 Geschäftsregressionsprüfungen und Entfernung von Notfalleinstellungen Überprüfen Sie die normale Anmeldung, das Lesen und Schreiben von Sitzungen, Formulare und Uploads, den Import, die Fehlerbehandlung und die Worker-Stabilität rund um die von dieser Änderung betroffenen Funktionen. Überprüfen Sie, ob die Fehlerrate, die Antwortverzögerung, die Speicherspitze, der Prozessabbruch und die Wiederaufbauhäufigkeit abnormal sind. Wenn `memory_limit=-1` vorübergehend festgelegt ist, wird das begrenzte Budget, das der Geschäftskapazität entspricht, nach Inkrafttreten des offiziellen Patches wiederhergestellt. Wenn `pm.max_requests=1` festgelegt ist, wird die kapazitätsbewertete Lebenszykluskonfiguration wiederhergestellt, nachdem die Reparatur bestätigt wurde. Eingabegrößenbeschränkungen und Quellenzugriffskontrollen können je nach Geschäftsanforderungen beibehalten werden. Wenn während des Upgrades Kompatibilitätsprobleme auftreten, sollte vor einem Rollback vorrangig das betroffene Portal gesperrt, sein externer Zugriff eingeschränkt oder die Anwendung angepasst werden. Wenn Sie der nicht reparierten Laufzeit direkt erlauben, das öffentliche Netzwerk erneut zu bedienen, wird das ursprüngliche Risiko erneut aktiviert. ## 5. Abhilfemaßnahmen, wenn ein sofortiges Upgrade nicht möglich ist Dieser Abschnitt dient der kurzfristigen Reduzierung der Exposition bzw. Verbesserung der Verfügbarkeit. Jede Maßnahme deckt nur einen bestimmten Weg ab und eine Kombination mehrerer Maßnahmen ist nicht gleichbedeutend mit einer vollständigen Reparatur. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) ### 5.1 Priorisieren Sie Verkehrskontrollen vor PHP Wenn der Dienst dies zulässt, beschränken Sie sensible Endpunkte vorübergehend auf vertrauenswürdige Quellen oder erzwingen Sie die Zugriffskontrolle vor PHP. Begrenzen Sie für Upload-Workloads die Größe des Anforderungshauptteils, die Anzahl der Felder, Teile, Header pro Teil und die Verschachtelungstiefe. Dienste, die Multipart nicht benötigen, können es am Frontend ablehnen. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2) Diese Beschränkungen gelten für alle Zugänge zu PHP. Nur wenn URL mit dem Namen „upload“ abgefangen wird, werden andere Einträge übersehen, die noch automatisch von PHP im Anforderungstext analysiert werden. In Fällen wie geblockten Übertragungen, fehlender verfügbarer deklarierter Länge usw. sollte die Begrenzung auf der tatsächlichen Lesegröße basieren; Die Anwendung sollte auch über ein eigenes Ausgabegrößenbudget verfügen, wenn der Inhalt erneut dekomprimiert oder erweitert wird. ### 5.2 FPM pool Konfigurationsvorlage Platzieren Sie die folgenden Einstellungen im Konfigurationsabschnitt **FPM pool, der tatsächlich Anfragen** bedient, nicht wörtlich in `php.ini`. Die Werte 8M und 4M sind Beispiele zur Anpassung an die Arbeitsbelastung. Lassen Sie Platz für Formularfelder und mehrteilige Grenzen, wenn Sie die gesamte POST-Anfrage einschränken. [S11](https://keendigit.com/de/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/de/insights/php2shell-remediation-guide#source-12) ```ini ; Temporary mitigation: evaluate capacity before applying. php_admin_value[memory_limit] = -1 php_admin_value[post_max_size] = 8M php_admin_value[upload_max_filesize] = 4M php_admin_flag[session.upload_progress.enabled] = off ``` Nur **PHP 8.5**, plus: ```ini php_admin_flag[fatal_error_backtraces] = off ``` Die Funktionen und Grenzen jedes einzelnen sind wie folgt: | Konfiguration | erwartete Wirkung | Beschreibung der Einschränkungen, die beibehalten werden müssen | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `memory_limit=-1` | Entfernen Sie die vorhersehbare Auslösebedingung für die obere Grenze des Anforderungsspeichers PHP | Es verhindert nicht, dass zugrunde liegende Zuordnungsfehler auftreten. Das Stornieren des ursprünglichen Budgets kann das Risiko einer Speichererschöpfung und einer Dienstunterbrechung erhöhen. | | Kleiner `post_max_size` | Reduzieren Sie die Größe der Daten, die in den Parsing-Prozess gelangen | Der nicht reparierte Parser weist eine bekannte Lücke auf; Eine Gedächtnisverstärkung kann nicht unabhängig verhindert werden | | `upload_max_filesize < post_max_size` | Begrenzen Sie die Größe einer einzelnen Datei und reservieren Sie Speicherplatz für den Anforderungs-Overhead | Beschränkt nicht alle Felder, Metadaten oder In-App-Zuweisungen | | Schließen Sie den Upload-Fortschritt | Blockieren Sie den bestätigten sitzungsbezogenen Pfad | Andere globale Zustandsvarianten werden nicht abgedeckt | | PHP 8.5 Schwerwiegender Backtrace schließen | Blockieren Sie bestätigte verwandte Statusproduzenten | Deckt andere Pfade wie Sitzungen nicht ab | Die Maßgrenzen stammen aus der offiziellen Ankündigung; Informationen zur Poolsyntax und Konfigurationssemantik auf Verwaltungsebene finden Sie im PHP-Handbuch. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/de/insights/php2shell-remediation-guide#source-11) `php_admin_*`-Einstellungen auf Verwaltungsebene können nicht von Anwendungen über `ini_set()` überschrieben werden. Alle eingehenden Pool-, Verzeichnisebene- und Front-End-Konfigurationen sollten dennoch überprüft werden, um sicherzustellen, dass die Werte bei tatsächlichen Anforderungen den Erwartungen entsprechen. Erstellen Sie nach der Änderung alle Worker neu, um zu verhindern, dass vorhandene Prozesse weiterhin den alten Zustand beibehalten. Wenn Sie `php.ini` direkt ändern möchten, sollte die Syntax wie folgt geändert werden: ```ini memory_limit = -1 post_max_size = 8M upload_max_filesize = 4M session.upload_progress.enabled = Off ``` Im Gegensatz zu `php_admin_value` im Pool verhindert das bloße Festlegen von `memory_limit=-1` in `php.ini` nicht, dass die App es erneut ändert. Das Framework, der Anwendungscode und andere Konfigurationen sollten überprüft werden, um festzustellen, ob sie den begrenzten Wert zurückgesetzt haben. Wenn eine Durchsetzung erforderlich ist, verwenden Sie die für den aktuellen SAPI geeigneten Managementebeneneinstellungen und überprüfen Sie den tatsächlichen effektiven Wert. [S11](https://keendigit.com/de/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/de/insights/php2shell-remediation-guide#source-12) Fügen Sie `fatal_error_backtraces = Off` nur für PHP 8.5 hinzu. Verwenden Sie `ini_set()` auf Anwendungsebene nicht als Workaround zum Deaktivieren des Upload-Fortschritts und verlassen Sie sich nicht darauf, dass FPM `.user.ini` vor dem Analysieren der Anforderung wirksam wird. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3) ### 5.3 Verwalten Sie die Kosten für die Aufhebung der PHP-Speicherbeschränkungen `memory_limit=-1` ist eine temporäre Pfadminderung für nicht reparierte Umgebungen und sollte nicht als langfristige Standardkonfiguration kopiert werden. Wenn eine Anwendung oder Anforderung außer Kontrolle gerät, kann sie mehr Speicher des Hosts verbrauchen. Daher sollten Sie vor der Verwendung die Anzahl der Parallelen, den Spitzenwert einzelner Worker und die gesamte Servicekapazität bewerten und Front-End-Eingabegrenzen festlegen. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2) Container- oder Cgroup-Speicherbeschränkungen können Verfügbarkeitsgrenzen festlegen, garantieren jedoch nicht, dass Zuweisungen niemals fehlschlagen. Der gesamte Container, der Master und alle Worker können ebenfalls beendet werden, wenn das Limit ausgelöst wird. Isolationsgranularität und Beendigungsstrategien müssen in Verbindung mit der Bereitstellung evaluiert werden und können nicht als vollständiger Schutz für diese beiden CVE bezeichnet werden. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2) Ersetzen Sie die oben genannten Strategien nicht durch `RLIMIT_AS`, `RLIMIT_DATA` oder entsprechende Einschränkungen des Prozessadressraums. Sie können direkt dazu führen, dass die zugrunde liegende Zuordnung im immer noch problematischen OOM-Pfad fehlschlägt. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2) ### 5.4 Nginx Konfigurationsbeispiel Gilt für die Bereitstellung, bei der Nginx Anforderungen an PHP-FPM weiterleitet. Es kann auf der Konfigurationsebene des eigentlichen Hosting-Dienstes festgelegt werden: ```nginx client_max_body_size 8m; fastcgi_request_buffering on; ``` `client_max_body_size` begrenzt die Größe des Anforderungstexts; Mit `fastcgi_request_buffering on` kann Nginx zunächst den vollständigen Anforderungstext lesen und ihn dann an das FastCGI-Backend senden. Ob es in einem bestimmten `server` oder `location` wirksam wird, muss in Verbindung mit den bestehenden Vererbungs- und Abdeckungsbeziehungen geprüft werden. [S13](https://keendigit.com/de/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/de/insights/php2shell-remediation-guide#source-14) **Nur wenn das Unternehmen kein Multipart** benötigt, können Sie dem entsprechenden Serviceeingang eine Ablehnungsregel hinzufügen: ```nginx if ($http_content_type ~* "multipart/form-data") { return 403; } ``` Dies ist eine einfache Eingabebeschränkungsvorlage mit `if` und `return`, keine allgemeine Filterregel für Parser-Schwachstellen. Überprüfen Sie vor der Bereitstellung die Konfigurationssyntax und die normalen Anfragen und prüfen Sie, ob der benutzerdefinierte `error_page` 403-Anfragen an PHP umleitet. Der String-Abgleich bietet keine vollständige Garantie für alle Parsing-Unterschiede. [S15](https://keendigit.com/de/insights/php2shell-remediation-guide#source-15) Darüber hinaus begrenzen diese Konfigurationen nicht automatisch die Datenmenge, die Anzahl der Felder oder die Anzahl der PHP-Objekte, die von der Anwendung dekomprimiert werden können; Unternehmen, die hochladen müssen, sollten zusätzliche Einschränkungen verwenden, die die Struktur ihrer Anfragen verstehen. ### 5.5 Optionale Schadensbegrenzung: eine Anfrage pro FPM-Arbeiter Für FPM-Bereitstellungen, die sich den Overhead leisten können, können kurzfristige Setups evaluiert werden: ```ini pm.max_requests = 1 ``` Und den vorhandenen Arbeiter neu aufbauen. Es blockiert die beschriebene anfrageübergreifende Kette auf der Ebene der Worker-Wiederverwendung, erhöht jedoch den Aufwand für die Prozesserstellung und -initialisierung. Gleichzeitig können die gleichen Anforderungsprobleme OOM und Bereinigungsprobleme CVE-2026-109618 nicht behoben werden. Wenn der Wert kleiner, aber größer als 1 ist, gibt es immer noch ein Fenster zur Wiederverwendung von Anforderungen. [S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/de/insights/php2shell-remediation-guide#source-11) ### Deckungsgrenzen 5.6 WAF und Cloudflare Cloudflare hat Bereitstellungsvereinbarungen zum Schutz vor PHP2Shell angekündigt, einschließlich des Free-Plans. Bei der Nutzung seiner Dienste sollten Sie prüfen, ob der tatsächliche Datenverkehr über den Proxy läuft, ob die Schutzregeln in Kraft sind und ob die Ursprungsseite direkt umgangen werden kann; Bei kostenpflichtigen Plänen müssen Sie außerdem die Konfiguration und Ausnahmen der entsprechenden verwalteten Regeln überprüfen. [S16](https://keendigit.com/de/insights/php2shell-remediation-guide#source-16) Einige der vom Anbieter beschriebenen Erkennungen nutzen Antwortsignale, daher können nicht alle Schutzmaßnahmen so interpretiert werden, dass „jeder Angriff blockiert wird, bevor er PHP erreicht“. WAF kann dazu beitragen, die Exposition zu reduzieren und Beobachtungsinformationen bereitzustellen, es sind jedoch weiterhin Aktualisierungen von PHP erforderlich. [S16](https://keendigit.com/de/insights/php2shell-remediation-guide#source-16) ### 5.7 Warum gemeinsame Maßnahmen nicht ausreichen | Maßnahmen oder Urteile | Mängel | | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Nur `file_uploads` schließen | Kann nicht die gesamte mehrteilige Verarbeitung abdecken und einen eigenen OOM-Pfad anwenden | | Einstellung `enable_post_data_reading=Off` | Ändern Sie das Verhalten beim automatischen Ausfüllen von POST/FILES; Der Anforderungstext kann weiterhin von der Anwendung gelesen werden und kann den normalen Geschäftsbetrieb stören | | Fehleranzeige ausschalten, protokollieren oder `@` verwenden | Die interne Diagnoseverarbeitung greift möglicherweise immer noch auf den Ruhezustand zu | | Erhöhen Sie die Anzahl der Arbeitskräfte | Richten Sie keinen sicheren Mechanismus zur Zustandsbereinigung ein und verhindern Sie auch nicht die Wiederverwendung einzelner Mitarbeiter | | Konfigurieren Sie nur `disable_functions` oder `open_basedir` | Diese Einschränkungen beheben nicht die Speicherbeschädigung der C-Engine-Ebene | | Überprüfen Sie eine Version oder eine einzelne Kopie nur einmal | Es kann nicht nachgewiesen werden, dass alle Eingänge und Laufinstanzen ersetzt wurden | | Es werden keine Ausnahmeprotokolle angezeigt | Es kann nicht nachgewiesen werden, dass die Schwachstelle nicht existiert oder dass sie noch nie ausgenutzt wurde. | Darunter finden sich die Konfigurations- und Schwachstellenmechanismusbasis von PHP in [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/de/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/de/insights/php2shell-remediation-guide#source-12); Die Beurteilungen über Abdeckungs-, Akzeptanz- und Erlaubnisgrenzen basieren auf den Umsetzungsvorschlägen dieser Mechanismen. ## 6. Implementierungsideen und Überprüfungspunkte des offiziellen Patches ### 6.1 Verwenden Sie vollständige Fixes für den richtigen Zweig Die repräsentative offizielle Einreichung für PHP 8.5 lautet: ```text 31c0ea7d7ff1d1fccb6492e52dab544011628065 Avoid state corruption via bailout ``` Der Commit ordnet explizit zwei CVEs zu, sowohl um den Exit-Mechanismus OOM anzupassen als auch um den globalen Status zu korrigieren, auf den während der Initialisierungsphase zugegriffen werden kann. Seite mit vollständigem Diff einreichen, siehe [S4](https://keendigit.com/de/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5). Andere Niederlassungen sollten ihre eigenen offiziellen Sicherheitsversionen oder passende Patches verwenden, und es kann nicht davon ausgegangen werden, dass Änderungen an 8.5 direkt auf eine ältere Version angewendet werden können. ### 6.2 OOM Reparatur: Stellen Sie zuerst den verarbeitbaren Zustand wieder her und beenden Sie dann die Anforderung Die formale Implementierung führt zwei Ebenen der weichen und harten OOM-Verarbeitung ein: Wenn die weiche Grenze erreicht ist, wird der ausstehende Status aufgezeichnet und ein kontrollierter Ausstieg an einem sicheren Ort wie VM durchgeführt; Die fehlgeschlagene Zuordnungsschnittstelle ermöglicht es dem Aufrufer, den Fehler explizit zu behandeln. Bei Zuweisungen, die einen Fehler nicht direkt zurückgeben können, wird der Prozess direkt beendet, wenn erwartet wird, dass ein höherer harter Schwellenwert überschritten wird, um zu vermeiden, dass Anforderungen weiterhin in einem unsicheren Zwischenzustand verarbeitet werden. [S2](https://keendigit.com/de/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) Das Folgende ist ein Auszug des Schlüsselcodes im 8.5-Diff, der zum Markieren von ausstehenden OOM verwendet wird: ```c EG(delayed_oom).state = ZEND_OOM_STATE_PENDING; zend_atomic_bool_store_ex(&EG(vm_interrupt), true); ``` Die Interrupt-Verarbeitung von VM und andere sichere Orte rufen anschließend `zend_handle_delayed_oom()` auf. Sein Benutzercode-Ausführungskontext verwendet einen kontrollierten Abwicklungspfad. Der harte Pfad OOM ruft `_exit(137)` auf. [S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) Aus gestalterischer Sicht sind die wichtigen Änderungen: **vermeidet das willkürliche Überqueren des C-Aufrufstapels, wenn sich die Struktur in einem Zwischenzustand befindet, und platziert den Exit an einem Ort**, der Zustandsbeschränkungen aufrechterhalten kann. Nachdem der Soft-Grenzwert ausgelöst wurde, ist möglicherweise zusätzlicher Speicher erforderlich, um den Prozess abzuschließen. Daher kann der neue Soft-Schwellenwert nicht als absolute Obergrenze für den Gesamtspeicher des Prozesses verstanden werden. Es kann auch nicht als „PHP hat alle `zend_bailout()` gelöscht“ zusammengefasst werden. Der Patch nutzt weiterhin relevante Mechanismen in bestimmten Kontexten; Was behoben wird, ist der gefährliche Austrittszeitpunkt und das damit einhergehende Zustandsmanagement. [S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) ### 6.3 Zuordnungsaufrufer und mehrteiliges Parsen gemeinsam aktualisieren Wenn Sie eine Zuordnungsfunktion nur auf „Bei Fehler NULL zurückgeben“ ändern und der ursprüngliche Aufrufer immer noch davon ausgeht, dass immer ein gültiger Zeiger zurückgegeben wird, führen Sie neue Nullzeigerzugriffe oder eine unvollständige Bereinigung ein. Die fehlgeschlagene Zuordnungsschnittstelle im Patch muss zusammen mit der Aufruferprüfung und der Ausnahmeweitergabe überprüft werden. [S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) Zu mehrteiligen Korrekturen gehören auch die Durchführung kumulativer Prüfungen basierend auf dem tatsächlichen Lesevolumen, die Reduzierung der Verarbeitung nutzloser oder doppelter Header und die Einführung einer konsistenten Exit- und Bereinigungslogik, wenn OOM aussteht. Diese Änderungen reduzieren sowohl die Ressourcenverstärkung als auch sorgen dafür, dass der Parser dem neuen OOM-Protokoll entspricht. [S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) Für Teams, die ihre eigenen Zweige verwalten, wird empfohlen, dass die folgenden Probleme im Mittelpunkt der Codeüberprüfung stehen: - Ist der Zustand für die Außenwelt sichtbar, bevor er vollständig initialisiert ist? - Ist der Besitz nach einem Zuordnungsfehler oder einer Rückrufausnahme immer noch eindeutig und eindeutig? - Können Sie den einheitlichen Bereinigungsausgang erreichen, wenn Sie auf halbem Weg scheitern? - Kann die Bereinigungsfunktion nicht initialisierte oder freigegebene Felder erkennen? - Basiert das Parsing-Budget auf dem tatsächlichen Verarbeitungsvolumen und nicht nur auf Vertrauensanfrageansprüchen? - Wurde der neue Fehlerrückgabewert von allen Anrufern verarbeitet? Hierbei handelt es sich um Überprüfungsfragen, die auf der Grundlage des Korrekturmechanismus zusammengefasst wurden, und nicht um die Schlussfolgerung einer Prüfung, die für eine nicht bereitgestellte Codebasis abgeschlossen wurde. ### 6.4 Cross-Request-Fix: Initialisierung früher, endgültige Bereinigung später Entsprechend CVE-2026-109619 passt der Patch mehrere Lebenszyklusgrenzen gleichzeitig an. Die unten aufgeführten Dateien und Vorgänge nehmen als Beispiel das offizielle Diff PHP 8.5. [S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) | Standort | Richtung ändern | Problem gelöst | | ----------------------------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | `Zend/zend_execute_API.c` usw. | Setzen Sie den Executor-Status wie Fehler, Ausnahmen, Handler, Objekte usw. zurück. | Nach Beendigung der Anfrage sind noch alte Referenzen vorhanden, auf die bei der nächsten Anfrage zugegriffen werden kann. | | Startpfad von `main/main.c` | Rufen Sie `php_basic_early_rinit()` auf, bevor SAPI aktiviert wird | Wenn ein früher Verbraucher auftritt, wurde der entsprechende zugrunde liegende Zustand noch nicht initialisiert. | | Naher Pfad von `main/main.c` | Zerstören Sie HTTP globals und markieren Sie es als undefiniert | Der freigegebene Wert gilt weiterhin als gültiges Objekt | | bevor der Anforderungsheap endgültig freigegeben wird | Bereinigen Sie die letzte Fehlermeldung noch einmal | Die Diagnose einer verspäteten Bereinigung füllt den Fehlerstatus erneut aus | | `ext/session/session.c` | Upload-Fortschritt Der frühe Pfad wird mit den ersten Sitzungsglobalen initialisiert | Das reguläre Modul RINIT hat zuvor auf den alten Zustand zugegriffen | | Serialisierungsbezogener Code | Beschränken Sie das Parsen von Klassen und Benutzerrückrufe in der frühen Verarbeitung | Führen Sie zusätzlichen Benutzercode aus, wenn die Initialisierung nicht abgeschlossen ist | Die Startsequenz umfasst beispielsweise: ```c zend_activate(); php_basic_early_rinit(); sapi_activate(); ``` Nachdem HTTP globals zerstört wurde, fügen Sie die Statusfehlermarkierung hinzu: ```c zval_ptr_dtor(&PG(http_globals)[i]); ZVAL_UNDEF(&PG(http_globals)[i]); ``` Diese Auszüge veranschaulichen zwei Prinzipien: **Initialisierung vor dem frühestmöglichen Verbraucher und abschließende Bereinigung nach der letzten Operation, die möglicherweise den Status wiederherstellt.** Das Zurücksetzen eines Zeigers nur während der normalen RINIT oder einer früheren Abschaltphase kann frühere oder spätere Zugriffe übersehen. [S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) ### 6.5 Warum ist es nicht empfehlenswert, eine „One-Line-Reparatur“ selbst durchzuführen? Das Ersetzen aller `zend_bailout()` durch `_exit()` oder das einfache Hinzufügen einer Nullzeigerprüfung an einem bestimmten Eintrag würde eine große Anzahl verschiedener Ausführungskontexte umfassen. Sie lassen möglicherweise andere Statusfelder weg oder ändern die Zerstörung, erweiterte Rückrufe, das Prozesshosting und die Semantik des Anforderungsendes. Bei unterstützten Versionen haben bereits veröffentlichte vollständige Fixes Vorrang. Bei der Migration eigener Zweigstellen sollten die Quelle von Patches, anwendbare Baselines, Konfliktbehandlung und Verhaltensänderungen erfasst sowie entsprechende Upstream-Regressionsanwendungsfälle und die Überprüfung dieses Geschäftsprozesses verwendet werden. Die Vorschläge hier stammen aus einer Analyse des Patch-Umfangs über Allokator-, VM-, Sitzungs- und Anforderungslebenszyklusänderungen hinweg. [S4](https://keendigit.com/de/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/de/insights/php2shell-remediation-guide#source-5) ## 7. Notfall-Backport von PHP 7.4, 8.0, 8.1 PHP stellt offiziell den minimalen Quellcode-Backport von drei alten Zweigen basierend auf dem Schweregrad bereit. Die Filialnamen sind: ```text PHP-7.4-CVE-2026-109618-109619 PHP-8.0-CVE-2026-109618-109619 PHP-8.1-CVE-2026-109618-109619 ``` Informationen zu Zweiglinks finden Sie unter [S7](https://keendigit.com/de/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/de/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/de/insights/php2shell-remediation-guide#source-9). Dabei handelt es sich um Notfalllieferungen für diese Schwachstelle und stellen weder eine Rückkehr zum regulären Upstream-Support für den alten Zweig dar, noch ersetzen sie andere Sicherheitsupdates. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1) ### 7.1 Nehmen Sie den Backport PHP 8.1 als Beispiel Die relevanten Einreichungen für PHP 8.1 sind: ```text 1d7dec178a094e6e75b229ce22754045f8c6070a ``` Seine Strategie bevorzugt Fail-Fast: Aufruf von `_exit(1)` nach Ausgabe der Diagnose im entsprechenden OOM-Pfad und Einbeziehung des globalen Status und anderer relevanter Korrekturen; während die entsprechende Verarbeitung des Sitzungs-Upload-Fortschritts intern deaktiviert wird. Informationen zur Einreichung relevanter Quellcodes finden Sie unter [S6](https://keendigit.com/de/insights/php2shell-remediation-guide#source-6). Dies ist ein Verhaltensunterschied zum vollständigeren verzögerten OOM-Design im unterstützten Zweig. Nur weil die Konfiguration immer noch anzeigt, dass der Upload-Fortschritt aktiv ist, bedeutet das nicht, dass das interne Verarbeitungsverhalten nach diesem Backport unverändert bleibt. ### 7.2 Der Preis, den Sie bei der Bereitstellung akzeptieren müssen Das direkte Beenden des Prozesses kann dazu führen, dass die aktuelle Anforderung fehlschlägt und die normalen PHP-Rückrufe zum Herunterfahren und ein Teil des Schließens der Anwendung übersprungen werden. Wenn der Host ein Thread-Modell übernimmt, müssen auch die Auswirkungen des gesamten Host-Prozess-Exits auf andere gleichzeitige Arbeiten bewertet werden. In die Überprüfung sollte auch einbezogen werden, ob der Prozessverantwortliche den Austauschprozess rechtzeitig durchführen kann. Daher sollten Benutzer älterer Versionen Folgendes berücksichtigen: 1. Migrieren Sie zum unterstützten PHP-Zweig und seiner festen Version. 2. Verwenden Sie eine Version, die explizit sowohl das Hersteller-Update CVE als auch das LTS abdeckt. 3. Wenn es sich tatsächlich um die alte Version des Quellcodes handelt, verwenden Sie den offiziellen Notfall-Backport der passenden Version, um die vollständigen Änderungen und die Kompatibilität zu überprüfen und eine anschließende Migration zu veranlassen. Der „Mindest-Backport“ beschreibt hier den vom Beamten gewählten Kompatibilitäts- und Implementierungsumfang und sollte nicht automatisch als „bekannte unvollständige Schwachstellenbehebung“ interpretiert werden. Sie sollten anhand des Quellcodes des entsprechenden Zweigs und der Ankündigung des Herstellers urteilen und die unterstützenden Änderungen nicht selbst löschen. [S1](https://keendigit.com/de/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/de/insights/php2shell-remediation-guide#source-6) ## 8. Abnahmekriterien und Nachkontrollen Es wird empfohlen, die folgenden Ergebnisse als Grundlage für die Durchführung dieser Reparatur zu verwenden: | Annahmeartikel | Fertigstellungsstandards | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Abdeckung von Sicherheitslücken | Die Build- oder Herstellerankündigung behebt explizit CVE-2026-109618 und CVE-2026-109619 | | Bereitstellungsabdeckung | Alle Portale, Pools, Dienste und Replikate verwenden die reparierte Laufzeit | | Prozess tritt in Kraft | Der alte Worker, der alte Hostprozess und der alte Container werden alle beendet | | Authentische Anfrageüberprüfung | Bestätigter SAPI, erstellt und konfiguriert mit tatsächlichem Web-Link, um eine Cache-Fehlleitung zu verhindern | | Geschäftsverfügbarkeit | Schlüsselfunktionen wie Sitzung, Hochladen, Importieren und Fehlerbehandlung sind normal zurückgekehrt. | | Ende der vorübergehenden Maßnahmen | Unbegrenzter Speicher und extreme Worker-Recycling-Konfigurationen wurden gemäß dem Kapazitätsplan wiederhergestellt oder es gibt einen klaren Grund für die Beibehaltung | | Beweis für Veränderung | Notieren Sie die Paketversion oder den Image-Digest, den Aktualisierungsumfang, die Fertigstellungszeit und die Überprüfungsergebnisse | Bei den oben aufgeführten Vorschlägen handelt es sich um Umsetzungsvorschläge. Wenn Sie das OOM-Verhalten, einen abnormalen Exit oder benutzerdefinierte Patches überprüfen müssen, sollten Sie als Akzeptanzmethode vorgelagerte Regressionstests oder eine kontrollierte Fehlerinjektion in einer isolierten Umgebung verwenden, um zu vermeiden, dass in der Produktionsumgebung wiederholt eine Speicherauslastung entsteht. Überprüfen Sie außerdem die Ereignisse PHP (fatal, Worker-Absturz, abnormaler Neustart), Anforderungsfehlerrate und WAF vor und nach dem Update. Protokolle können nur Anhaltspunkte für die Untersuchung liefern: Das Auftreten von OOM bedeutet nicht, dass es ausgenutzt wurde, und das Fehlen von Alarmen beweist nicht, dass keine Ausnutzung stattgefunden hat. Das Upgrade behebt Schwachstellenpfade, die in Zukunft erreicht werden können; Wenn Anomalien wie Dateimanipulationen oder Anmeldedatenlecks festgestellt werden, sollten separate Vorfalluntersuchungen durchgeführt werden. ## Anhang: Zitierte Quellen und Links Alle Quelllinks sind unten zusammengestellt. Die Hinweise, Patches und Herstelleranweisungen spiegeln Prüfungen mit Stand **O22. Oktober 2026** wider; Nachfolgende Bereitstellungen sollten nach Anbieteraktualisierungen suchen. Die nummerierten Zitate im Text beziehen sich auf diese Einträge. ### S1 – PHP offizielles Sicherheitsbulletin und Reparaturversion - Quelle: Projekt PHP, 21. Oktober 2026. - Zweck: Risikoumfang, vier offizielle Reparaturversionen, offizielle temporäre Maßnahmen und Notfall-Backport-Anweisungen für alte Filialen. - Verweis: [PHP 2026 This security bulletin](https://www.php.net/archive/2026.php#2026-10-21-5) befindet sich im jährlichen Bulletin-Archiv ### S2 – CVE-2026-109618 Offizielles technisches Bulletin - Quelle: php/php-src GitHub Security Advisory, 21. Oktober 2026. - Identifikation: GHSA-w8hw-w9fx-j79w. - Zweck: Abdeckungsgrenze für OOM, mehrteilige Verstärkung, SAPI-Differenz und -Abschwächung. - Verweis: [RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) ### S3 – CVE-2026-109619 Offizielles technisches Bulletin - Quelle: php/php-src GitHub Security Advisory, 21. Oktober 2026. - Identifikation: GHSA-6wmf-4rv5-p3rp. - Zweck: Cross-Request-Dangling-Status, Produzenten und Konsumenten, frühe Initialisierung, Konfigurationsminderung. - Verweis: [RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) ### S4 – Offizielle Korrektureinreichung PHP 8.5 - Quelle: php/php-src. - Senden: `31c0ea7d7ff1d1fccb6492e52dab544011628065`. - Zweck: Bestätigen Sie die formelle Einreichung, um zwei Schwachstellen gleichzeitig zu beheben, und erläutern Sie die allgemeine Änderungsrichtung. - Verweis: [Avoid state corruption via bailout](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065) ### S5 — PHP 8.5 Offiziell restauriertes und komplettes Diff - Quelle: Abweichung von der gleichen offiziellen Einreichung. - Zweck: Überprüfen Sie die spezifische Implementierung von Allokator, VM, HTTP globals, Sitzung, Serialisierung und Anforderungslebenszyklus. - Verweis: [offizielles vollständiges Diff](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff) ### S6 – PHP 8.1 offizielle Notfall-Backport-Übermittlung - Quelle: php/php-src. - Senden: `1d7dec178a094e6e75b229ce22754045f8c6070a`. - Zweck: Überprüfen Sie das schnelle Beenden alter Zweige und laden Sie Fortschrittsverhaltensänderungen hoch. - Verweis: [PHP 8.1 Notfall-Backfill-Übermittlung](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a) - Verweis: [entspricht dem vollständigen diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff) ### S7 – PHP 7.4 offizieller Notfall-Backport-Zweig - Quelle: Quellcodezweige php/php-src, PHP, aufgeführt im offiziellen Sicherheitsbulletin. - Verweis: [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619) ### S8 – PHP 8.0 offizieller Notfall-Backport-Zweig - Quelle: Quellcodezweige php/php-src, PHP, aufgeführt im offiziellen Sicherheitsbulletin. - Verweis: [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619) ### S9 – PHP 8.1 offizieller Notfall-Backport-Zweig - Quelle: Quellcodezweige php/php-src, PHP, aufgeführt im offiziellen Sicherheitsbulletin. - Verweis: [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619) ### S10 – Ubuntu Sicherheitsbulletin USN-8948-1 - Quelle: Canonical / Ubuntu, 21. Oktober 2026. - Zweck: Beispiele für Backports und vollständige Paketversionen veröffentlichen. - Verweis: [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1) ### S11 – PHP-FPM Configuration Handbuch - Quelle: Offizielles Dokument PHP. - Zweck: Konfigurationssemantik wie `php_admin_value`, `php_admin_flag`, `pm.max_requests` usw. - Verweis: [PHP-FPM Configuration](https://www.php.net/manual/en/install.fpm.configuration.php) ### S12 – PHP Core INI Konfigurationshandbuch - Quelle: Offizielles Dokument PHP. - Zweck: Definition und Umfang des Anforderungshauptteils, des Uploads, des Speichers und der automatischen POST-Lesekonfiguration. - Verweis: [Description of core php.ini directives](https://www.php.net/manual/en/ini.core.php) ### S13 – Nginx fordert Körpergrößenbeschränkung an - Quelle: Offizielles Dokument Nginx. - Zweck: Die Bedeutung von `client_max_body_size` und die verfügbaren Konfigurationsebenen. - Verweis: [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) ### S14 – Nginx FastCGI Anforderungspuffer - Quelle: Offizielles Dokument Nginx. - Zweck: Die Verarbeitungsreihenfolge und Funktion von `fastcgi_request_buffering`. - Verweis: [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering) ### S15 — Nginx Bedingungs- und Rückgabeanweisungen - Quelle: Offizielles Dokument Nginx. - Zweck: Konfigurationssyntax von `if` und `return`. - Verweis: [ngx\_http\_rewrite\_module](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if) ### S16 — Cloudflare PHP2Shell Schutzanweisungen - Quelle: Offizieller Blog von Cloudflare. - Zweck: Beschreibung des WAF-Bereitstellungsbereichs, der Free-Plananordnung und des Erkennungsmechanismus. - Verweis: [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) ## Beratung zur Sicherheitswartung Benötigen Sie Hilfe bei der Aktualisierung Ihrer PHP-Systeme? Wir können die Gefährdung beurteilen, das Update planen und die laufende Anwendung überprüfen. [Besprechen Sie Sicherheitsupdates]() [Originalseite]() · [Inhaltsindex]() KeenDigit LLC · Wyoming-Einreichungs-ID: 2026-002106155 [Erkundigen Sie sich beim Außenminister von Wyoming]() © 2026 KeenDigit LLC · Sheridan, Wyoming, USA · Alle Rechte vorbehalten.