{"content_id":"vufynon7qa","slug":"php2shell-enterprise-security-patch-response-guide","locale":"de","schema_type":"HowTo","category":"how_to","category_name":"Anleitungen","title":"PHP2Shell: Unternehmensserver absichern","summary":"Bei PHP2Shell stehen zunächst das Update und der Neustart von PHP im laufenden Webdienst an. Bei Verdacht auf eine Kompromittierung hat die Beweissicherung Vorrang. Auch nach dem Patch sind Logprüfungen und der Austausch der Zugangsdaten erforderlich.","sponsorship_disclosure":null,"affiliate_disclosure":null,"commerce_disclosure":null,"author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["Prüfen Sie den PHP-Einsatz auf laufenden Servern und in Embedded-Produkten.","Isolieren Sie bei Verdacht auf eine Kompromittierung den Server und sichern Sie vor dem Neustart die Beweise.","Installieren Sie eine korrigierte Version oder wenden Sie bis zum Update die offizielle Übergangsmaßnahme an.","Starten Sie die Dienste, die PHP ausführen, neu und prüfen Sie anschließend, ob der Patch im laufenden Webdienst wirksam ist.","Prüfen Sie frühere Logs und tauschen Sie die Zugangsdaten der exponierten Server aus."],"content_markdown":"Die Maßnahmen gegen PHP2Shell beginnen damit, den PHP-Einsatz zu erfassen und eine korrigierte Version einzuspielen. Starten Sie nach dem Update die ausführenden Dienste neu. Bei Verdacht auf eine Kompromittierung müssen vor dem Neustart Beweise gesichert werden. Auch nach dem Patch sind eine Prüfung der Protokolle und der Austausch von Zugangsdaten erforderlich.\n\nDie Angaben zu Versionen und Einstellungen beruhen auf der KISA-Mitteilung vom 22. Oktober 2026 und der ergänzenden PHP-Mitteilung vom 23. Oktober.\n\n## Was für eine Schwachstelle ist PHP2Shell?\n\nPHP2Shell ist eine PHP-Schwachstelle, die es ermöglicht, ohne Authentifizierung Code auf dem Server auszuführen. Sie betrifft die Speicherverwaltung bei der Verarbeitung von Anfragen durch den Webserver. Ob ein Angriff gelingt, hängt von der Laufzeitumgebung und der Konfiguration ab.\n\n| Kategorie | Kennung | Art des Problems |\n| --- | --- | --- |\n| Problem bei der Behandlung von Speichermangel | CVE-2026-109618 | Verarbeitung unvollständiger interner Daten bei Speichermangel |\n| Problem mit Zuständen, die zwischen Anfragen erhalten bleiben | CVE-2026-109619 | Verwendung eines Zustands, der auf bereits freigegebenen Speicher verweist, bei späteren Anfragen |\n\nKISA gibt den Schweregrad beider Schwachstellen mit einem CVSS-Wert von 9.2 an. Bei einem erfolgreichen Angriff können Webshells installiert oder Kundendaten entwendet werden. Eine Webshell ist eine Datei, die zur Fernsteuerung eines Servers missbraucht wird. Auch die Manipulation von Websites und das Eindringen in interne Netzwerke sind möglich.\n\nKISA berichtete über Datenabflüsse und Angriffsversuche vor der Bereitstellung der Patches. Das Forschungsteam veröffentlichte, wie es die Schwachstellen mithilfe von KI entdeckt hatte. Das Problem liegt in PHP selbst und ist daher nicht auf bestimmte Website-Produkte beschränkt. [KISA-Handlungsempfehlungen für Unternehmen](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230), [Erläuterungen des Forschungsteams zu PHP2Shell](https://www.php2shell.com/)\n\n## Reihenfolge der Maßnahmen je nach Situation\n\nDie Reihenfolge von Update und Beweissicherung hängt davon ab, ob ein Verdacht auf eine Kompromittierung besteht. Bei regulären Patcharbeiten folgen nach dem Test das Update und der Neustart. Isolieren Sie Server mit Verdacht auf eine Kompromittierung zuerst.\n\n| Aktueller Zustand | Zuerst zu erledigen | Anschließend zu erledigen |\n| --- | --- | --- |\n| Öffentlich zugänglicher Server ohne Anzeichen einer Kompromittierung | Kompatibilität prüfen und korrigierte Version einspielen | Neustarten, tatsächlich verwendete Version prüfen, Protokolle kontrollieren |\n| Webshell oder verdächtige Verbindung entdeckt | Vom Netzwerk isolieren und Vorfall melden | Nach der Beweissicherung Wiederherstellungsmaßnahmen durchführen |\n| Server, der nicht sofort aktualisiert werden kann | Offizielle vorläufige Einstellungen anwenden und Anfragen auf vorgeschalteten Systemen begrenzen | Patchtermin festlegen und Patch einspielen |\n| Server, bei dem auch vorläufige Maßnahmen schwierig sind | Sperrung externer Zugriffe oder vorübergehende Abschaltung prüfen | Nach dem Patch über die Wiederaufnahme des Betriebs entscheiden |\n| Vom Hosting-Anbieter oder Hersteller verwaltete Umgebung | Beim zuständigen Anbieter nachfragen, ob die Maßnahmen umgesetzt wurden | Nachweise für die Umsetzung in der Laufzeitumgebung einholen |\n\nDer Neustart nach dem Update dient dazu, den korrigierten Code auszuführen. Bei der Behandlung eines Sicherheitsvorfalls wird der Neustart zur Beweissicherung aufgeschoben. Auch beim selben Server gilt bei Verdacht auf eine Kompromittierung die letztgenannte Reihenfolge.\n\n## So erfassen Sie den PHP-Einsatz\n\nPrüfen Sie sowohl das Systeminventar als auch die tatsächlich laufenden Server. Wenn Sie nur die Hauptwebsite prüfen, können Sie Server übersehen, die nicht mehr in der Verwaltung erfasst sind. Auch Geräte und Container, die PHP enthalten, müssen geprüft werden.\n\n1. Erstellen Sie eine Liste der im Internet öffentlich zugänglichen Websites und Systeme.\n2. Prüfen Sie extern erstellte und ältere Websites.\n3. Prüfen Sie Server für Veranstaltungen und Tests sowie Administrationsseiten.\n4. Prüfen Sie, ob Verwaltungsoberflächen von Geräten und Softwarelösungen PHP enthalten.\n5. Prüfen Sie Container-Images und laufende Container.\n6. Dokumentieren Sie für jede Umgebung die PHP-Version und die zuständige Person.\n\nWenn Sie Hosting nutzen, lassen Sie sich vom Anbieter bestätigen, ob die Patches eingespielt wurden. Prüfen Sie bei PHP, das in Geräten enthalten ist, die Updates des Herstellers. Kontrollieren Sie auch interne Systeme, beginnen Sie die Maßnahmen jedoch bei den im Internet öffentlich zugänglichen Servern.\n\n## Korrigierte PHP-Versionen und Kriterien zum Supportende\n\nDie korrigierte Version der Reihe 8.5 ist laut offizieller PHP-Mitteilung **8.5.12**. Auch die ursprüngliche KISA-Mitteilung nennt dieselbe Version. Das bedeutet nicht, dass Sie mit dem Patchen auf 8.5.13 warten müssen.\n\n| Verwendete Versionsreihe | Korrigierte Version für beide Schwachstellen | Maßstab für die Maßnahmen |\n| --- | --- | --- |\n| PHP 8.5 | 8.5.13 oder höher | Aktuelle Sicherheitsversion der jeweiligen Reihe prüfen |\n| PHP 8.4 | 8.4.27 oder höher | Aktuelle Sicherheitsversion der jeweiligen Reihe prüfen |\n| PHP 8.3 | 8.3.36 oder höher | Aktuelle Sicherheitsversion der jeweiligen Reihe prüfen |\n| PHP 8.2 | 8.2.35 oder höher | Neben dem Patch den Wechsel zu einer höheren Versionsreihe vorbereiten |\n| PHP 8.1 und älter | Regulärer Sicherheitssupport beendet | Zu einer unterstützten Versionsreihe wechseln oder Patches des Anbieters prüfen |\n\nDie Tabelle basiert auf den am 21. Oktober 2026 veröffentlichten korrigierten Versionen. Bei Distributionspaketen kann die angezeigte Versionsnummer unverändert bleiben. Prüfen Sie in diesem Fall im Änderungsprotokoll, ob beide CVEs behoben wurden. [Mitteilung zu PHP-Sicherheitsversionen](https://www.php.net/archive/2026.php)\n\nDer Sicherheitssupport für PHP 8.2 endet am 31. Dezember 2026. KISA empfiehlt den Wechsel zu PHP 8.3 oder höher. Testen Sie vor dem Wechsel die Anwendungskompatibilität. [PHP-Supportzeitplan](https://www.php.net/supported-versions.php)\n\nFür PHP 8.1 und ältere Versionen ist der reguläre Sicherheitssupport beendet. Patches von Distributionen oder Anbietern mit Langzeitunterstützung müssen gesondert geprüft werden. Auch die jetzt veröffentlichten Quellcode-Patches für ältere Versionen bedeuten keine Wiederaufnahme des regulären Supports.\n\n## So führen Sie Update und Neustart durch\n\nNach dem Austausch der Installationsdateien müssen die Dienste neu gestartet werden, die PHP ausführen. Bestehende Prozesse können weiterhin den im Speicher verbliebenen Code ausführen. Bei Verdacht auf eine Komromittierung sichern Sie zuerst Beweise, bevor Sie die folgenden Schritte durchführen.\n\n1. Prüfen Sie, wie sich der Patch auf bestehende Funktionen auswirkt.\n2. Prüfen Sie in einer Testumgebung die Kompatibilität des Dienstes.\n3. Spielen Sie die korrigierten Pakete zuerst auf den im Internet öffentlich zugänglichen Servern ein.\n4. Starten Sie alle Dienste neu, die PHP ausführen.\n5. Stellen Sie Container-Umgebungen mit korrigierten Images erneut bereit.\n6. Prüfen Sie, ob die Änderungen bei dem PHP wirksam sind, das die tatsächlichen Webanfragen verarbeitet.\n\nZu den neu zu startenden Diensten gehören PHP-FPM und Apache mod_php. Prüfen Sie auch php-cgi, FrankenPHP und LiteSpeed. Wenn auf einem Server mehrere PHP-Umgebungen vorhanden sind, müssen Sie jede einzeln prüfen.\n\n`php -v` zeigt die PHP-Version an, die auf der Kommandozeile ausgeführt wird. Sie kann von der PHP-Version des Webdienstes abweichen. Beurteilen Sie den Abschluss des Updates nicht allein anhand der Kommandozeilenausgabe.\n\n## Vorgaben für vorläufige Einstellungen vor dem Update\n\nVorläufige Maßnahmen können einige Angriffswege einschränken. Sie beheben nicht alle Schwachstellen. Falls sich die Einstellungen nur schwer umsetzen lassen, prüfen Sie eine Sperrung externer Zugriffe.\n\n### Wie wird memory_limit eingestellt?\n\nDie offizielle vorläufige Empfehlung für diese Schwachstelle lautet `memory_limit=-1`. Dieser Wert hebt die PHP-eigene Begrenzung der Speichernutzung auf. Verstehen Sie ihn nicht als Einstellung für den normalen Betrieb.\n\nDurch das Aufheben der Begrenzung werden bestimmte Pfade eingeschränkt, die Speichermangel auslösen. Die Einstellung verhindert jedoch nicht, dass tatsächliche Speicherzuweisungen fehlschlagen. Prüfen Sie zugleich Begrenzungen der Anfragegröße und Maßnahmen zur Ressourcenverwaltung. [Sicherheitshinweis zur PHP-Schwachstelle bei Speichermangel](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)\n\n| Parameter | Offizielle vorläufige Maßnahme | Bei der Anwendung zu prüfen |\n| --- | --- | --- |\n| `memory_limit` | Auf `-1` setzen | Administratoreinstellung verwenden, damit die Anwendung den Wert nicht ändern kann |\n| `session.upload_progress.enabled` | Auf `0` setzen | Eine Konfigurationsstelle verwenden, die vor der Anfrageverarbeitung wirksam wird |\n| `post_max_size` | `8M` als Beispiel, wenn keine Uploads benötigt werden | Tatsächliche Dienstanforderungen und vorgeschaltete Begrenzungen gemeinsam prüfen |\n| `upload_max_filesize` | Kleiner als `post_max_size` festlegen | Auswirkungen auf die Datei-Upload-Funktion prüfen |\n| `fatal_error_backtraces` | Unter PHP 8.5 auf `0` setzen | Nicht pauschal auf andere Versionsreihen anwenden |\n\nDie Einstellungswerte in der Tabelle beruhen auf den offiziellen Mitteilungen zu Gegenmaßnahmen vom Oktober 2026. `8M` ist ein Beispiel für Dienste, die keine Uploads benötigen. Es ist keine Vorgabe, dieselbe Größe auf alle Dienste anzuwenden.\n\n1. Begrenzen Sie die Anfragegröße in der Web Application Firewall, im Webserver und im Proxy.\n2. Prüfen Sie, ob die Begrenzungen auch für Anfragen ohne Größenangabe gelten.\n3. Blockieren Sie multipart-Anfragen auf vorgeschalteten Systemen, wenn keine Uploads benötigt werden.\n4. Prüfen Sie die aktuellen Blockierregeln der Web Application Firewall.\n5. Wenden Sie die Einstellungen in `php.ini`, im PHP-FPM-Pool oder an vergleichbarer Stelle an.\n6. Prüfen Sie, ob Beweise gesichert werden müssen, und starten Sie anschließend die PHP-Prozesse neu.\n\nWenden Sie die vorläufigen Einstellungen nicht allein mit `ini_set()` an. Einstellungen, die vor der Anfrageverarbeitung erforderlich sind, könnten dadurch zu spät wirksam werden. Erwarten Sie auch von `.user.ini` unter PHP-FPM nicht dieselbe Wirkung. [Offizielle vorläufige PHP-Maßnahmen](https://www.php.net/archive/2026.php)\n\n### Was Sie in der ergänzenden Mitteilung vom 23. Oktober prüfen sollten\n\nPHP empfiehlt in der ergänzenden Mitteilung, die Funktion zur Erfassung des Upload-Fortschritts zu deaktivieren. Der Hinweis betrifft einen gesonderten Ausführungspfad, der bei bestimmten Einstellungskombinationen bestehen bleibt. Wenn die Funktion bereits deaktiviert wurde, soll sie bis zur nächsten regulären Fehlerkorrekturversion deaktiviert bleiben.\n\nZu den betreffenden Bedingungen gehört eine Änderung des Verfahrens zur Session-Serialisierung während der Laufzeit. Diese Bedingungen liegen nicht bei jeder PHP-Installation vor. Entscheiden Sie anhand der ergänzenden Mitteilung, ob die Einstellungen nach dem Patch zurückgesetzt werden sollen. (Bestätigte Angabe: Empfehlung, session.upload_progress.enabled=0 bis zur nächsten regulären Fehlerkorrekturversion beizubehalten · Quelle php.net · geprüft am 2026-10-23) [Ergänzende PHP-Mitteilung zu Session upload progress](https://www.php.net/archive/2026.php)\n\n## So prüfen Sie Protokolle und tauschen Zugangsdaten aus\n\nKISA empfiehlt, mindestens die Aufzeichnungen **ab dem 20. Oktober 2026** zu prüfen. Prüfen Sie nach Möglichkeit auch frühere Aufzeichnungen. Ein Patch kann eine bereits erfolgte Kompromittierung oder einen Datenabfluss nicht rückgängig machen.\n\n| Prüfbereich | Zu suchende Spuren |\n| --- | --- |\n| Webserver-Protokolle | Wiederholte HTTP-500-Fehler |\n| PHP-Ausführungsprotokolle | Unerwartete Abbrüche und segfault |\n| Web-, Upload- und temporäre Verzeichnisse | Neu angelegte oder geänderte PHP-Dateien |\n| Protokolle zur Prozessausführung | Ausführung von sh, bash oder Download-Werkzeugen durch den Webserver |\n| Netzwerkverbindungen | Spuren neuer Verbindungen zu unbekannten externen Adressen |\n| Website und Administrationsseiten | Heimlich hinzugefügte externe Skripte |\n\nFehler allein belegen noch keine Kompromittierung. Umgekehrt lässt sich auch aus dem Fehlen auffälliger Aufzeichnungen nicht schließen, dass ein System sicher ist. KISA gibt folgenden Hinweis:\n\n\u003e Auch wenn die Aufzeichnungen keine Auffälligkeiten zeigen, ist die Sicherheit nicht gewährleistet. Führen Sie deshalb das Update und den Austausch der Zugangsdaten gemeinsam durch.\n\u003e\n\u003e KISA „Sicherheitsmaßnahmen für Unternehmen zu PHP-Sicherheitslücken (PHP2Shell)“\n\nFür Server, die vor dem Patch über das Internet erreichbar waren, wird der Austausch der Zugangsdaten empfohlen. Bei Servern mit Spuren einer Kompromittierung müssen Sie die Zugangsdaten unbedingt austauschen. Dazu gehören Datenbank- und Administratorpasswörter. Prüfen Sie auch, ob API-Schlüssel und Zugriffstoken offengelegt worden sein könnten.\n\nPrüfen Sie bei Diensten, die mit einer Datenbank mit personenbezogenen Daten verbunden sind, auch die Datenbankprotokolle. Dabei müssen Spuren umfangreicher Abfragen und Datenabflüsse untersucht werden. Beschränken Sie auch den direkten Internetzugriff auf phpMyAdmin. Reduzieren Sie die Datenbankberechtigungen des Webdienstkontos auf den erforderlichen Umfang. [Hinweise der Personal Information Protection Commission zu vorbeugenden Maßnahmen](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588)\n\n## Vorgehen bei Verdacht auf eine Kompromittierung\n\nSchalten Sie den Server bei Verdacht auf eine Kompromittierung nicht aus und starten Sie ihn nicht sofort neu. Ein Neustart kann Angriffsspuren löschen, die sich noch im Speicher befinden. Isolieren Sie den Server vom Netzwerk und sichern Sie anschließend die Beweise.\n\n1. Sperren Sie auf Netzwerkebene die externen Verbindungen des Servers.\n2. Unternehmen in Korea melden den Vorfall über das Menü zur Meldung von Sicherheitsvorfällen auf 보호나라.\n3. Sichern Sie Protokolle und die Liste der laufenden Programme.\n4. Sichern Sie auch die Informationen zu den aktuellen Netzwerkverbindungen.\n5. Führen Sie nach der Beweissicherung das Update und den Neustart durch.\n6. Entfernen Sie Webshells und tauschen Sie Zugangsdaten aus.\n\nDie Beratungsstelle in Korea ist KISA 118. Der Menüpfad für die Meldung lautet 보호나라 \u003e Sicherheitsvorfall melden \u003e Meldung einreichen. Wenn Sie im Ausland tätig sind, prüfen Sie die zuständige örtliche Meldestelle.\n\n## Häufige Fehleinschätzungen im Vergleich\n\nUm festzustellen, ob ein Patch wirksam angewendet wurde, müssen auch der laufende Betrieb und das Änderungsprotokoll geprüft werden. Eine Meldung über den erfolgreichen Abschluss der Installation reicht nicht aus. Nehmen Sie die folgenden Einschätzungen in Ihre Prüfliste auf.\n\n| Häufige Einschätzung | Was geprüft werden muss |\n| --- | --- |\n| Wenn sich `php -v` geändert hat, ist alles erledigt | Das vom Webdienst tatsächlich verwendete PHP prüfen |\n| Mit der Paketinstallation ist alles erledigt | Neustart der PHP-ausführenden Dienste bestätigen |\n| Wenn die Versionsnummer unverändert ist, wurde nichts unternommen | Im Änderungsprotokoll der Distribution prüfen, ob die CVEs behoben wurden |\n| Mit einer Web Application Firewall kann auf den Patch verzichtet werden | Aktuelle Regeln prüfen und zugleich PHP aktualisieren |\n| Wenn die Protokolle unauffällig sind, gab es keinen Datenabfluss | Auch eine mögliche Offenlegung von Zugangsdaten prüfen |\n| Um extern erstellte Websites kümmert sich der Anbieter von selbst | Für jeden Dienst einen Nachweis der Umsetzung anfordern |\n\nFühren Sie keinen im Internet gefundenen Prüfcode auf Produktivservern aus. KISA warnt vor gefälschten PoCs, die Schadsoftware enthalten. Ein PoC ist Prüfcode, der zeigt, dass eine Schwachstelle ausgenutzt werden kann. Prüfen Sie zur Feststellung der Verwundbarkeit zuerst die Version und den Patchverlauf.\n\n## Prüfliste zum Abschluss der Maßnahmen in extern betreuten und Hosting-Umgebungen\n\nIm Abschlussbericht zu den Maßnahmen sollten für jeden Dienst Nachweise festgehalten werden. Die folgende Tabelle fasst die KISA-Handlungsempfehlungen zu betrieblichen Prüfpunkten zusammen. Sie ist kein gesondertes offizielles Einreichungsformular.\n\n| Prüfpunkt | Beim Anbieter oder der zuständigen Person anzufordernde Angaben |\n| --- | --- |\n| Vollständigkeit der erfassten Systeme | Prüfliste für Websites, Administrationsseiten und Testserver |\n| Behebung der Schwachstellen | Eingespielte Version oder Paketänderungsprotokoll mit beiden CVEs |\n| Laufender Betrieb | Nachweis über den Neustart der Dienste oder die erneute Bereitstellung der Container |\n| Tatsächliche Wirksamkeit | Im Webdienst überprüfte PHP-Laufzeitumgebung |\n| Prüfung auf Kompromittierung | Zeitraum der geprüften Protokolle und festgestellte Auffälligkeiten |\n| Zugangsdaten | Auszutauschende Zugangsdaten und Stand des Austauschs |\n| Verbleibende Arbeiten | Server mit ausschließlich vorläufigen Maßnahmen und Plan für nachfolgende Patches |\n\nAngenommen, der Anbieter hat lediglich die abgeschlossene Paketinstallation gemeldet. Fordern Sie in diesem Fall die Ergebnisse der Prüfung des Neustarts und der PHP-Laufzeitumgebung des Webdienstes an. Die Protokollprüfung und den Austausch der Zugangsdaten können Sie als gesonderte Punkte überprüfen.","content_html":"\u003cp\u003eDie Maßnahmen gegen PHP2Shell beginnen damit, den PHP-Einsatz zu erfassen und eine korrigierte Version einzuspielen. Starten Sie nach dem Update die ausführenden Dienste neu. Bei Verdacht auf eine Kompromittierung müssen vor dem Neustart Beweise gesichert werden. Auch nach dem Patch sind eine Prüfung der Protokolle und der Austausch von Zugangsdaten erforderlich.\u003c/p\u003e\n\u003cp\u003eDie Angaben zu Versionen und Einstellungen beruhen auf der KISA-Mitteilung vom 22. Oktober 2026 und der ergänzenden PHP-Mitteilung vom 23. Oktober.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#was-f%C3%BCr-eine-schwachstelle-ist-php2shell\" class=\"anchor\" id=\"was-für-eine-schwachstelle-ist-php2shell\"\u003e\u003c/a\u003eWas für eine Schwachstelle ist PHP2Shell?\u003c/h2\u003e\n\u003cp\u003ePHP2Shell ist eine PHP-Schwachstelle, die es ermöglicht, ohne Authentifizierung Code auf dem Server auszuführen. Sie betrifft die Speicherverwaltung bei der Verarbeitung von Anfragen durch den Webserver. Ob ein Angriff gelingt, hängt von der Laufzeitumgebung und der Konfiguration ab.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eKategorie\u003c/th\u003e\n\u003cth\u003eKennung\u003c/th\u003e\n\u003cth\u003eArt des Problems\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kategorie\"\u003eProblem bei der Behandlung von Speichermangel\u003c/td\u003e\n\u003ctd data-label=\"Kennung\"\u003eCVE-2026-109618\u003c/td\u003e\n\u003ctd data-label=\"Art des Problems\"\u003eVerarbeitung unvollständiger interner Daten bei Speichermangel\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kategorie\"\u003eProblem mit Zuständen, die zwischen Anfragen erhalten bleiben\u003c/td\u003e\n\u003ctd data-label=\"Kennung\"\u003eCVE-2026-109619\u003c/td\u003e\n\u003ctd data-label=\"Art des Problems\"\u003eVerwendung eines Zustands, der auf bereits freigegebenen Speicher verweist, bei späteren Anfragen\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eKISA gibt den Schweregrad beider Schwachstellen mit einem CVSS-Wert von 9.2 an. Bei einem erfolgreichen Angriff können Webshells installiert oder Kundendaten entwendet werden. Eine Webshell ist eine Datei, die zur Fernsteuerung eines Servers missbraucht wird. Auch die Manipulation von Websites und das Eindringen in interne Netzwerke sind möglich.\u003c/p\u003e\n\u003cp\u003eKISA berichtete über Datenabflüsse und Angriffsversuche vor der Bereitstellung der Patches. Das Forschungsteam veröffentlichte, wie es die Schwachstellen mithilfe von KI entdeckt hatte. Das Problem liegt in PHP selbst und ist daher nicht auf bestimmte Website-Produkte beschränkt. \u003ca href=\"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026amp;menuNo=205020\u0026amp;nttId=72230\"\u003eKISA-Handlungsempfehlungen für Unternehmen\u003c/a\u003e, \u003ca href=\"https://www.php2shell.com/\"\u003eErläuterungen des Forschungsteams zu PHP2Shell\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#reihenfolge-der-ma%C3%9Fnahmen-je-nach-situation\" class=\"anchor\" id=\"reihenfolge-der-maßnahmen-je-nach-situation\"\u003e\u003c/a\u003eReihenfolge der Maßnahmen je nach Situation\u003c/h2\u003e\n\u003cp\u003eDie Reihenfolge von Update und Beweissicherung hängt davon ab, ob ein Verdacht auf eine Kompromittierung besteht. Bei regulären Patcharbeiten folgen nach dem Test das Update und der Neustart. Isolieren Sie Server mit Verdacht auf eine Kompromittierung zuerst.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eAktueller Zustand\u003c/th\u003e\n\u003cth\u003eZuerst zu erledigen\u003c/th\u003e\n\u003cth\u003eAnschließend zu erledigen\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aktueller Zustand\"\u003eÖffentlich zugänglicher Server ohne Anzeichen einer Kompromittierung\u003c/td\u003e\n\u003ctd data-label=\"Zuerst zu erledigen\"\u003eKompatibilität prüfen und korrigierte Version einspielen\u003c/td\u003e\n\u003ctd data-label=\"Anschließend zu erledigen\"\u003eNeustarten, tatsächlich verwendete Version prüfen, Protokolle kontrollieren\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aktueller Zustand\"\u003eWebshell oder verdächtige Verbindung entdeckt\u003c/td\u003e\n\u003ctd data-label=\"Zuerst zu erledigen\"\u003eVom Netzwerk isolieren und Vorfall melden\u003c/td\u003e\n\u003ctd data-label=\"Anschließend zu erledigen\"\u003eNach der Beweissicherung Wiederherstellungsmaßnahmen durchführen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aktueller Zustand\"\u003eServer, der nicht sofort aktualisiert werden kann\u003c/td\u003e\n\u003ctd data-label=\"Zuerst zu erledigen\"\u003eOffizielle vorläufige Einstellungen anwenden und Anfragen auf vorgeschalteten Systemen begrenzen\u003c/td\u003e\n\u003ctd data-label=\"Anschließend zu erledigen\"\u003ePatchtermin festlegen und Patch einspielen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aktueller Zustand\"\u003eServer, bei dem auch vorläufige Maßnahmen schwierig sind\u003c/td\u003e\n\u003ctd data-label=\"Zuerst zu erledigen\"\u003eSperrung externer Zugriffe oder vorübergehende Abschaltung prüfen\u003c/td\u003e\n\u003ctd data-label=\"Anschließend zu erledigen\"\u003eNach dem Patch über die Wiederaufnahme des Betriebs entscheiden\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Aktueller Zustand\"\u003eVom Hosting-Anbieter oder Hersteller verwaltete Umgebung\u003c/td\u003e\n\u003ctd data-label=\"Zuerst zu erledigen\"\u003eBeim zuständigen Anbieter nachfragen, ob die Maßnahmen umgesetzt wurden\u003c/td\u003e\n\u003ctd data-label=\"Anschließend zu erledigen\"\u003eNachweise für die Umsetzung in der Laufzeitumgebung einholen\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDer Neustart nach dem Update dient dazu, den korrigierten Code auszuführen. Bei der Behandlung eines Sicherheitsvorfalls wird der Neustart zur Beweissicherung aufgeschoben. Auch beim selben Server gilt bei Verdacht auf eine Kompromittierung die letztgenannte Reihenfolge.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#so-erfassen-sie-den-php-einsatz\" class=\"anchor\" id=\"so-erfassen-sie-den-php-einsatz\"\u003e\u003c/a\u003eSo erfassen Sie den PHP-Einsatz\u003c/h2\u003e\n\u003cp\u003ePrüfen Sie sowohl das Systeminventar als auch die tatsächlich laufenden Server. Wenn Sie nur die Hauptwebsite prüfen, können Sie Server übersehen, die nicht mehr in der Verwaltung erfasst sind. Auch Geräte und Container, die PHP enthalten, müssen geprüft werden.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eErstellen Sie eine Liste der im Internet öffentlich zugänglichen Websites und Systeme.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie extern erstellte und ältere Websites.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie Server für Veranstaltungen und Tests sowie Administrationsseiten.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie, ob Verwaltungsoberflächen von Geräten und Softwarelösungen PHP enthalten.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie Container-Images und laufende Container.\u003c/li\u003e\n\u003cli\u003eDokumentieren Sie für jede Umgebung die PHP-Version und die zuständige Person.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eWenn Sie Hosting nutzen, lassen Sie sich vom Anbieter bestätigen, ob die Patches eingespielt wurden. Prüfen Sie bei PHP, das in Geräten enthalten ist, die Updates des Herstellers. Kontrollieren Sie auch interne Systeme, beginnen Sie die Maßnahmen jedoch bei den im Internet öffentlich zugänglichen Servern.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#korrigierte-php-versionen-und-kriterien-zum-supportende\" class=\"anchor\" id=\"korrigierte-php-versionen-und-kriterien-zum-supportende\"\u003e\u003c/a\u003eKorrigierte PHP-Versionen und Kriterien zum Supportende\u003c/h2\u003e\n\u003cp\u003eDie korrigierte Version der Reihe 8.5 ist laut offizieller PHP-Mitteilung \u003cstrong\u003e8.5.12\u003c/strong\u003e. Auch die ursprüngliche KISA-Mitteilung nennt dieselbe Version. Das bedeutet nicht, dass Sie mit dem Patchen auf 8.5.13 warten müssen.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eVerwendete Versionsreihe\u003c/th\u003e\n\u003cth\u003eKorrigierte Version für beide Schwachstellen\u003c/th\u003e\n\u003cth\u003eMaßstab für die Maßnahmen\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verwendete Versionsreihe\"\u003ePHP 8.5\u003c/td\u003e\n\u003ctd data-label=\"Korrigierte Version für beide Schwachstellen\"\u003e8.5.13 oder höher\u003c/td\u003e\n\u003ctd data-label=\"Maßstab für die Maßnahmen\"\u003eAktuelle Sicherheitsversion der jeweiligen Reihe prüfen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verwendete Versionsreihe\"\u003ePHP 8.4\u003c/td\u003e\n\u003ctd data-label=\"Korrigierte Version für beide Schwachstellen\"\u003e8.4.27 oder höher\u003c/td\u003e\n\u003ctd data-label=\"Maßstab für die Maßnahmen\"\u003eAktuelle Sicherheitsversion der jeweiligen Reihe prüfen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verwendete Versionsreihe\"\u003ePHP 8.3\u003c/td\u003e\n\u003ctd data-label=\"Korrigierte Version für beide Schwachstellen\"\u003e8.3.36 oder höher\u003c/td\u003e\n\u003ctd data-label=\"Maßstab für die Maßnahmen\"\u003eAktuelle Sicherheitsversion der jeweiligen Reihe prüfen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verwendete Versionsreihe\"\u003ePHP 8.2\u003c/td\u003e\n\u003ctd data-label=\"Korrigierte Version für beide Schwachstellen\"\u003e8.2.35 oder höher\u003c/td\u003e\n\u003ctd data-label=\"Maßstab für die Maßnahmen\"\u003eNeben dem Patch den Wechsel zu einer höheren Versionsreihe vorbereiten\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Verwendete Versionsreihe\"\u003ePHP 8.1 und älter\u003c/td\u003e\n\u003ctd data-label=\"Korrigierte Version für beide Schwachstellen\"\u003eRegulärer Sicherheitssupport beendet\u003c/td\u003e\n\u003ctd data-label=\"Maßstab für die Maßnahmen\"\u003eZu einer unterstützten Versionsreihe wechseln oder Patches des Anbieters prüfen\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDie Tabelle basiert auf den am 21. Oktober 2026 veröffentlichten korrigierten Versionen. Bei Distributionspaketen kann die angezeigte Versionsnummer unverändert bleiben. Prüfen Sie in diesem Fall im Änderungsprotokoll, ob beide CVEs behoben wurden. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eMitteilung zu PHP-Sicherheitsversionen\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eDer Sicherheitssupport für PHP 8.2 endet am 31. Dezember 2026. KISA empfiehlt den Wechsel zu PHP 8.3 oder höher. Testen Sie vor dem Wechsel die Anwendungskompatibilität. \u003ca href=\"https://www.php.net/supported-versions.php\"\u003ePHP-Supportzeitplan\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eFür PHP 8.1 und ältere Versionen ist der reguläre Sicherheitssupport beendet. Patches von Distributionen oder Anbietern mit Langzeitunterstützung müssen gesondert geprüft werden. Auch die jetzt veröffentlichten Quellcode-Patches für ältere Versionen bedeuten keine Wiederaufnahme des regulären Supports.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#so-f%C3%BChren-sie-update-und-neustart-durch\" class=\"anchor\" id=\"so-führen-sie-update-und-neustart-durch\"\u003e\u003c/a\u003eSo führen Sie Update und Neustart durch\u003c/h2\u003e\n\u003cp\u003eNach dem Austausch der Installationsdateien müssen die Dienste neu gestartet werden, die PHP ausführen. Bestehende Prozesse können weiterhin den im Speicher verbliebenen Code ausführen. Bei Verdacht auf eine Komromittierung sichern Sie zuerst Beweise, bevor Sie die folgenden Schritte durchführen.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003ePrüfen Sie, wie sich der Patch auf bestehende Funktionen auswirkt.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie in einer Testumgebung die Kompatibilität des Dienstes.\u003c/li\u003e\n\u003cli\u003eSpielen Sie die korrigierten Pakete zuerst auf den im Internet öffentlich zugänglichen Servern ein.\u003c/li\u003e\n\u003cli\u003eStarten Sie alle Dienste neu, die PHP ausführen.\u003c/li\u003e\n\u003cli\u003eStellen Sie Container-Umgebungen mit korrigierten Images erneut bereit.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie, ob die Änderungen bei dem PHP wirksam sind, das die tatsächlichen Webanfragen verarbeitet.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eZu den neu zu startenden Diensten gehören PHP-FPM und Apache mod_php. Prüfen Sie auch php-cgi, FrankenPHP und LiteSpeed. Wenn auf einem Server mehrere PHP-Umgebungen vorhanden sind, müssen Sie jede einzeln prüfen.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ephp -v\u003c/code\u003e zeigt die PHP-Version an, die auf der Kommandozeile ausgeführt wird. Sie kann von der PHP-Version des Webdienstes abweichen. Beurteilen Sie den Abschluss des Updates nicht allein anhand der Kommandozeilenausgabe.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#vorgaben-f%C3%BCr-vorl%C3%A4ufige-einstellungen-vor-dem-update\" class=\"anchor\" id=\"vorgaben-für-vorläufige-einstellungen-vor-dem-update\"\u003e\u003c/a\u003eVorgaben für vorläufige Einstellungen vor dem Update\u003c/h2\u003e\n\u003cp\u003eVorläufige Maßnahmen können einige Angriffswege einschränken. Sie beheben nicht alle Schwachstellen. Falls sich die Einstellungen nur schwer umsetzen lassen, prüfen Sie eine Sperrung externer Zugriffe.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#wie-wird-memory_limit-eingestellt\" class=\"anchor\" id=\"wie-wird-memory_limit-eingestellt\"\u003e\u003c/a\u003eWie wird memory_limit eingestellt?\u003c/h3\u003e\n\u003cp\u003eDie offizielle vorläufige Empfehlung für diese Schwachstelle lautet \u003ccode\u003ememory_limit=-1\u003c/code\u003e. Dieser Wert hebt die PHP-eigene Begrenzung der Speichernutzung auf. Verstehen Sie ihn nicht als Einstellung für den normalen Betrieb.\u003c/p\u003e\n\u003cp\u003eDurch das Aufheben der Begrenzung werden bestimmte Pfade eingeschränkt, die Speichermangel auslösen. Die Einstellung verhindert jedoch nicht, dass tatsächliche Speicherzuweisungen fehlschlagen. Prüfen Sie zugleich Begrenzungen der Anfragegröße und Maßnahmen zur Ressourcenverwaltung. \u003ca href=\"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w\"\u003eSicherheitshinweis zur PHP-Schwachstelle bei Speichermangel\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eParameter\u003c/th\u003e\n\u003cth\u003eOffizielle vorläufige Maßnahme\u003c/th\u003e\n\u003cth\u003eBei der Anwendung zu prüfen\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parameter\"\u003e\u003ccode\u003ememory_limit\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Offizielle vorläufige Maßnahme\"\u003eAuf \u003ccode\u003e-1\u003c/code\u003e setzen\u003c/td\u003e\n\u003ctd data-label=\"Bei der Anwendung zu prüfen\"\u003eAdministratoreinstellung verwenden, damit die Anwendung den Wert nicht ändern kann\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parameter\"\u003e\u003ccode\u003esession.upload_progress.enabled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Offizielle vorläufige Maßnahme\"\u003eAuf \u003ccode\u003e0\u003c/code\u003e setzen\u003c/td\u003e\n\u003ctd data-label=\"Bei der Anwendung zu prüfen\"\u003eEine Konfigurationsstelle verwenden, die vor der Anfrageverarbeitung wirksam wird\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parameter\"\u003e\u003ccode\u003epost_max_size\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Offizielle vorläufige Maßnahme\"\u003e\n\u003ccode\u003e8M\u003c/code\u003e als Beispiel, wenn keine Uploads benötigt werden\u003c/td\u003e\n\u003ctd data-label=\"Bei der Anwendung zu prüfen\"\u003eTatsächliche Dienstanforderungen und vorgeschaltete Begrenzungen gemeinsam prüfen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parameter\"\u003e\u003ccode\u003eupload_max_filesize\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Offizielle vorläufige Maßnahme\"\u003eKleiner als \u003ccode\u003epost_max_size\u003c/code\u003e festlegen\u003c/td\u003e\n\u003ctd data-label=\"Bei der Anwendung zu prüfen\"\u003eAuswirkungen auf die Datei-Upload-Funktion prüfen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Parameter\"\u003e\u003ccode\u003efatal_error_backtraces\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Offizielle vorläufige Maßnahme\"\u003eUnter PHP 8.5 auf \u003ccode\u003e0\u003c/code\u003e setzen\u003c/td\u003e\n\u003ctd data-label=\"Bei der Anwendung zu prüfen\"\u003eNicht pauschal auf andere Versionsreihen anwenden\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDie Einstellungswerte in der Tabelle beruhen auf den offiziellen Mitteilungen zu Gegenmaßnahmen vom Oktober 2026. \u003ccode\u003e8M\u003c/code\u003e ist ein Beispiel für Dienste, die keine Uploads benötigen. Es ist keine Vorgabe, dieselbe Größe auf alle Dienste anzuwenden.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eBegrenzen Sie die Anfragegröße in der Web Application Firewall, im Webserver und im Proxy.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie, ob die Begrenzungen auch für Anfragen ohne Größenangabe gelten.\u003c/li\u003e\n\u003cli\u003eBlockieren Sie multipart-Anfragen auf vorgeschalteten Systemen, wenn keine Uploads benötigt werden.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie die aktuellen Blockierregeln der Web Application Firewall.\u003c/li\u003e\n\u003cli\u003eWenden Sie die Einstellungen in \u003ccode\u003ephp.ini\u003c/code\u003e, im PHP-FPM-Pool oder an vergleichbarer Stelle an.\u003c/li\u003e\n\u003cli\u003ePrüfen Sie, ob Beweise gesichert werden müssen, und starten Sie anschließend die PHP-Prozesse neu.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eWenden Sie die vorläufigen Einstellungen nicht allein mit \u003ccode\u003eini_set()\u003c/code\u003e an. Einstellungen, die vor der Anfrageverarbeitung erforderlich sind, könnten dadurch zu spät wirksam werden. Erwarten Sie auch von \u003ccode\u003e.user.ini\u003c/code\u003e unter PHP-FPM nicht dieselbe Wirkung. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eOffizielle vorläufige PHP-Maßnahmen\u003c/a\u003e\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#was-sie-in-der-erg%C3%A4nzenden-mitteilung-vom-23-oktober-pr%C3%BCfen-sollten\" class=\"anchor\" id=\"was-sie-in-der-ergänzenden-mitteilung-vom-23-oktober-prüfen-sollten\"\u003e\u003c/a\u003eWas Sie in der ergänzenden Mitteilung vom 23. Oktober prüfen sollten\u003c/h3\u003e\n\u003cp\u003ePHP empfiehlt in der ergänzenden Mitteilung, die Funktion zur Erfassung des Upload-Fortschritts zu deaktivieren. Der Hinweis betrifft einen gesonderten Ausführungspfad, der bei bestimmten Einstellungskombinationen bestehen bleibt. Wenn die Funktion bereits deaktiviert wurde, soll sie bis zur nächsten regulären Fehlerkorrekturversion deaktiviert bleiben.\u003c/p\u003e\n\u003cp\u003eZu den betreffenden Bedingungen gehört eine Änderung des Verfahrens zur Session-Serialisierung während der Laufzeit. Diese Bedingungen liegen nicht bei jeder PHP-Installation vor. Entscheiden Sie anhand der ergänzenden Mitteilung, ob die Einstellungen nach dem Patch zurückgesetzt werden sollen. (Bestätigte Angabe: Empfehlung, session.upload_progress.enabled=0 bis zur nächsten regulären Fehlerkorrekturversion beizubehalten · Quelle php.net · geprüft am 2026-10-23) \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eErgänzende PHP-Mitteilung zu Session upload progress\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#so-pr%C3%BCfen-sie-protokolle-und-tauschen-zugangsdaten-aus\" class=\"anchor\" id=\"so-prüfen-sie-protokolle-und-tauschen-zugangsdaten-aus\"\u003e\u003c/a\u003eSo prüfen Sie Protokolle und tauschen Zugangsdaten aus\u003c/h2\u003e\n\u003cp\u003eKISA empfiehlt, mindestens die Aufzeichnungen \u003cstrong\u003eab dem 20. Oktober 2026\u003c/strong\u003e zu prüfen. Prüfen Sie nach Möglichkeit auch frühere Aufzeichnungen. Ein Patch kann eine bereits erfolgte Kompromittierung oder einen Datenabfluss nicht rückgängig machen.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePrüfbereich\u003c/th\u003e\n\u003cth\u003eZu suchende Spuren\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfbereich\"\u003eWebserver-Protokolle\u003c/td\u003e\n\u003ctd data-label=\"Zu suchende Spuren\"\u003eWiederholte HTTP-500-Fehler\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfbereich\"\u003ePHP-Ausführungsprotokolle\u003c/td\u003e\n\u003ctd data-label=\"Zu suchende Spuren\"\u003eUnerwartete Abbrüche und segfault\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfbereich\"\u003eWeb-, Upload- und temporäre Verzeichnisse\u003c/td\u003e\n\u003ctd data-label=\"Zu suchende Spuren\"\u003eNeu angelegte oder geänderte PHP-Dateien\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfbereich\"\u003eProtokolle zur Prozessausführung\u003c/td\u003e\n\u003ctd data-label=\"Zu suchende Spuren\"\u003eAusführung von sh, bash oder Download-Werkzeugen durch den Webserver\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfbereich\"\u003eNetzwerkverbindungen\u003c/td\u003e\n\u003ctd data-label=\"Zu suchende Spuren\"\u003eSpuren neuer Verbindungen zu unbekannten externen Adressen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfbereich\"\u003eWebsite und Administrationsseiten\u003c/td\u003e\n\u003ctd data-label=\"Zu suchende Spuren\"\u003eHeimlich hinzugefügte externe Skripte\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eFehler allein belegen noch keine Kompromittierung. Umgekehrt lässt sich auch aus dem Fehlen auffälliger Aufzeichnungen nicht schließen, dass ein System sicher ist. KISA gibt folgenden Hinweis:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAuch wenn die Aufzeichnungen keine Auffälligkeiten zeigen, ist die Sicherheit nicht gewährleistet. Führen Sie deshalb das Update und den Austausch der Zugangsdaten gemeinsam durch.\u003c/p\u003e\n\u003cp\u003eKISA „Sicherheitsmaßnahmen für Unternehmen zu PHP-Sicherheitslücken (PHP2Shell)“\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eFür Server, die vor dem Patch über das Internet erreichbar waren, wird der Austausch der Zugangsdaten empfohlen. Bei Servern mit Spuren einer Kompromittierung müssen Sie die Zugangsdaten unbedingt austauschen. Dazu gehören Datenbank- und Administratorpasswörter. Prüfen Sie auch, ob API-Schlüssel und Zugriffstoken offengelegt worden sein könnten.\u003c/p\u003e\n\u003cp\u003ePrüfen Sie bei Diensten, die mit einer Datenbank mit personenbezogenen Daten verbunden sind, auch die Datenbankprotokolle. Dabei müssen Spuren umfangreicher Abfragen und Datenabflüsse untersucht werden. Beschränken Sie auch den direkten Internetzugriff auf phpMyAdmin. Reduzieren Sie die Datenbankberechtigungen des Webdienstkontos auf den erforderlichen Umfang. \u003ca href=\"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026amp;mCode=C010010000\u0026amp;nttId=12588\"\u003eHinweise der Personal Information Protection Commission zu vorbeugenden Maßnahmen\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#vorgehen-bei-verdacht-auf-eine-kompromittierung\" class=\"anchor\" id=\"vorgehen-bei-verdacht-auf-eine-kompromittierung\"\u003e\u003c/a\u003eVorgehen bei Verdacht auf eine Kompromittierung\u003c/h2\u003e\n\u003cp\u003eSchalten Sie den Server bei Verdacht auf eine Kompromittierung nicht aus und starten Sie ihn nicht sofort neu. Ein Neustart kann Angriffsspuren löschen, die sich noch im Speicher befinden. Isolieren Sie den Server vom Netzwerk und sichern Sie anschließend die Beweise.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eSperren Sie auf Netzwerkebene die externen Verbindungen des Servers.\u003c/li\u003e\n\u003cli\u003eUnternehmen in Korea melden den Vorfall über das Menü zur Meldung von Sicherheitsvorfällen auf 보호나라.\u003c/li\u003e\n\u003cli\u003eSichern Sie Protokolle und die Liste der laufenden Programme.\u003c/li\u003e\n\u003cli\u003eSichern Sie auch die Informationen zu den aktuellen Netzwerkverbindungen.\u003c/li\u003e\n\u003cli\u003eFühren Sie nach der Beweissicherung das Update und den Neustart durch.\u003c/li\u003e\n\u003cli\u003eEntfernen Sie Webshells und tauschen Sie Zugangsdaten aus.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eDie Beratungsstelle in Korea ist KISA 118. Der Menüpfad für die Meldung lautet 보호나라 \u0026gt; Sicherheitsvorfall melden \u0026gt; Meldung einreichen. Wenn Sie im Ausland tätig sind, prüfen Sie die zuständige örtliche Meldestelle.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#h%C3%A4ufige-fehleinsch%C3%A4tzungen-im-vergleich\" class=\"anchor\" id=\"häufige-fehleinschätzungen-im-vergleich\"\u003e\u003c/a\u003eHäufige Fehleinschätzungen im Vergleich\u003c/h2\u003e\n\u003cp\u003eUm festzustellen, ob ein Patch wirksam angewendet wurde, müssen auch der laufende Betrieb und das Änderungsprotokoll geprüft werden. Eine Meldung über den erfolgreichen Abschluss der Installation reicht nicht aus. Nehmen Sie die folgenden Einschätzungen in Ihre Prüfliste auf.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eHäufige Einschätzung\u003c/th\u003e\n\u003cth\u003eWas geprüft werden muss\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Einschätzung\"\u003eWenn sich \u003ccode\u003ephp -v\u003c/code\u003e geändert hat, ist alles erledigt\u003c/td\u003e\n\u003ctd data-label=\"Was geprüft werden muss\"\u003eDas vom Webdienst tatsächlich verwendete PHP prüfen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Einschätzung\"\u003eMit der Paketinstallation ist alles erledigt\u003c/td\u003e\n\u003ctd data-label=\"Was geprüft werden muss\"\u003eNeustart der PHP-ausführenden Dienste bestätigen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Einschätzung\"\u003eWenn die Versionsnummer unverändert ist, wurde nichts unternommen\u003c/td\u003e\n\u003ctd data-label=\"Was geprüft werden muss\"\u003eIm Änderungsprotokoll der Distribution prüfen, ob die CVEs behoben wurden\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Einschätzung\"\u003eMit einer Web Application Firewall kann auf den Patch verzichtet werden\u003c/td\u003e\n\u003ctd data-label=\"Was geprüft werden muss\"\u003eAktuelle Regeln prüfen und zugleich PHP aktualisieren\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Einschätzung\"\u003eWenn die Protokolle unauffällig sind, gab es keinen Datenabfluss\u003c/td\u003e\n\u003ctd data-label=\"Was geprüft werden muss\"\u003eAuch eine mögliche Offenlegung von Zugangsdaten prüfen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Häufige Einschätzung\"\u003eUm extern erstellte Websites kümmert sich der Anbieter von selbst\u003c/td\u003e\n\u003ctd data-label=\"Was geprüft werden muss\"\u003eFür jeden Dienst einen Nachweis der Umsetzung anfordern\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eFühren Sie keinen im Internet gefundenen Prüfcode auf Produktivservern aus. KISA warnt vor gefälschten PoCs, die Schadsoftware enthalten. Ein PoC ist Prüfcode, der zeigt, dass eine Schwachstelle ausgenutzt werden kann. Prüfen Sie zur Feststellung der Verwundbarkeit zuerst die Version und den Patchverlauf.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#pr%C3%BCfliste-zum-abschluss-der-ma%C3%9Fnahmen-in-extern-betreuten-und-hosting-umgebungen\" class=\"anchor\" id=\"prüfliste-zum-abschluss-der-maßnahmen-in-extern-betreuten-und-hosting-umgebungen\"\u003e\u003c/a\u003ePrüfliste zum Abschluss der Maßnahmen in extern betreuten und Hosting-Umgebungen\u003c/h2\u003e\n\u003cp\u003eIm Abschlussbericht zu den Maßnahmen sollten für jeden Dienst Nachweise festgehalten werden. Die folgende Tabelle fasst die KISA-Handlungsempfehlungen zu betrieblichen Prüfpunkten zusammen. Sie ist kein gesondertes offizielles Einreichungsformular.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePrüfpunkt\u003c/th\u003e\n\u003cth\u003eBeim Anbieter oder der zuständigen Person anzufordernde Angaben\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eVollständigkeit der erfassten Systeme\u003c/td\u003e\n\u003ctd data-label=\"Beim Anbieter oder der zuständigen Person anzufordernde Angaben\"\u003ePrüfliste für Websites, Administrationsseiten und Testserver\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eBehebung der Schwachstellen\u003c/td\u003e\n\u003ctd data-label=\"Beim Anbieter oder der zuständigen Person anzufordernde Angaben\"\u003eEingespielte Version oder Paketänderungsprotokoll mit beiden CVEs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eLaufender Betrieb\u003c/td\u003e\n\u003ctd data-label=\"Beim Anbieter oder der zuständigen Person anzufordernde Angaben\"\u003eNachweis über den Neustart der Dienste oder die erneute Bereitstellung der Container\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eTatsächliche Wirksamkeit\u003c/td\u003e\n\u003ctd data-label=\"Beim Anbieter oder der zuständigen Person anzufordernde Angaben\"\u003eIm Webdienst überprüfte PHP-Laufzeitumgebung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003ePrüfung auf Kompromittierung\u003c/td\u003e\n\u003ctd data-label=\"Beim Anbieter oder der zuständigen Person anzufordernde Angaben\"\u003eZeitraum der geprüften Protokolle und festgestellte Auffälligkeiten\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eZugangsdaten\u003c/td\u003e\n\u003ctd data-label=\"Beim Anbieter oder der zuständigen Person anzufordernde Angaben\"\u003eAuszutauschende Zugangsdaten und Stand des Austauschs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Prüfpunkt\"\u003eVerbleibende Arbeiten\u003c/td\u003e\n\u003ctd data-label=\"Beim Anbieter oder der zuständigen Person anzufordernde Angaben\"\u003eServer mit ausschließlich vorläufigen Maßnahmen und Plan für nachfolgende Patches\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eAngenommen, der Anbieter hat lediglich die abgeschlossene Paketinstallation gemeldet. Fordern Sie in diesem Fall die Ergebnisse der Prüfung des Neustarts und der PHP-Laufzeitumgebung des Webdienstes an. Die Protokollprüfung und den Austausch der Zugangsdaten können Sie als gesonderte Punkte überprüfen.\u003c/p\u003e\n","tags":["Datenschutz","PHP","Sicherheitsupdates"],"faqs":[{"question":"Lässt sich PHP2Shell durch Ändern des Anmeldepassworts verhindern?","answer":"Die Schwachstelle kann ohne Anmeldung ausgenutzt werden, daher reicht eine Passwortänderung nicht aus. Ein PHP-Sicherheitsupdate ist erforderlich. Der Austausch der Zugangsdaten ist eine separate Maßnahme gegen einen möglichen Datenabfluss."},{"question":"Muss man bei PHP 8.5 auf 8.5.13 warten?","answer":"Die Originalmitteilungen von PHP und KISA nennen 8.5.13 als Version, in der die beiden Schwachstellen behoben sind. Das bedeutet nicht, dass Sie auf 8.5.13 warten müssen. Prüfen Sie bei der Installation auch die neueste offizielle Version der jeweiligen Versionsreihe."},{"question":"Ist bei Verwendung von PHP-FPM keine Überprüfung nötig?","answer":"Auch PHP-FPM muss überprüft werden. Die Voraussetzungen für einen Angriff können je nach Ausführungsart unterschiedlich sein. Beurteilen Sie die Sicherheit nicht allein anhand der Bezeichnung der Umgebung."},{"question":"Sind die Maßnahmen abgeschlossen, wenn php -v eine Version mit den Fehlerbehebungen anzeigt?","answer":"Die PHP-Version auf der Kommandozeile kann sich von der PHP-Version des Webdienstes unterscheiden. Prüfen Sie die Umgebung, die tatsächlich Webanfragen verarbeitet. Sie müssen auch prüfen, ob der laufende Dienst neu gestartet wurde."},{"question":"Ist der Patch fehlgeschlagen, wenn die Versionsnummer danach unverändert bleibt?","answer":"Pakete von Distributionen oder Herstellern können Fehlerbehebungen in bestehende Versionen übernehmen. Prüfen Sie im Änderungsprotokoll des Pakets, ob die beiden CVE-Schwachstellen behoben wurden."},{"question":"Ist die Einstellung memory_limit=-1 bei den aktuellen Gegenmaßnahmen verboten?","answer":"Diese Einstellung ist in den offiziellen vorläufigen Empfehlungen zu dieser Schwachstelle enthalten. Diese müssen von allgemeinen Betriebsempfehlungen unterschieden werden. Prüfen Sie zugleich Maßnahmen zur Begrenzung von Anfragen und zur Ressourcenverwaltung."},{"question":"Sind auch Websites ohne Datei-Upload betroffen?","answer":"Eine Website kann nicht allein deshalb als nicht betroffen eingestuft werden, weil sie keine Uploadfunktion hat. Da es sich um eine Schwachstelle in PHP selbst handelt, prüfen Sie die verwendete Version und den Patchstand. Das Blockieren unnötiger multipart-Anfragen ist eine vorläufige Maßnahme."},{"question":"Kann ich PHP 8.1 oder eine ältere Version weiterverwenden, wenn ein Patch des Anbieters vorliegt?","answer":"Patches des Anbieters müssen unabhängig vom Ende des regulären Supports geprüft werden. Auch wenn Sie einen solchen Patch vorläufig installieren, sollten Sie den Umstieg auf eine unterstützte Version planen."},{"question":"Kann ich die Zugangsdaten beibehalten, wenn die Protokolle keine Auffälligkeiten zeigen?","answer":"Allein anhand der Protokolle lässt sich nicht feststellen, dass keine Informationen abgeflossen sind. KISA empfiehlt, die Zugangsdaten von Servern auszutauschen, die vor dem Patchen aus dem Internet erreichbar waren. Bei Anzeichen einer Kompromittierung müssen Sie die Zugangsdaten unbedingt austauschen."},{"question":"Sollte ich bei Verdacht auf eine Kompromittierung zuerst ein Update durchführen?","answer":"Isolieren Sie den Server zunächst vom Netzwerk. Führen Sie das Update nach der Meldung und der Beweissicherung durch. Ein Neustart kann im Arbeitsspeicher verbliebene Angriffsspuren beseitigen."},{"question":"Was sollten Hosting-Nutzer prüfen?","answer":"Fordern Sie beim Anbieter für jeden Dienst Nachweise über die Installation der Patches an. Fordern Sie auch die Prüfergebnisse zum Neustart und zur tatsächlichen Ausführungsumgebung des Webdienstes an. Prüfen Sie separat, ob die Protokolle kontrolliert und die Zugangsdaten ausgetauscht wurden."},{"question":"Kann ich die Einstellung für den Uploadfortschritt nach dem Patchen wieder aktivieren?","answer":"Lesen Sie die zusätzliche Mitteilung von PHP vom 23. Oktober 2026. Wegen zusätzlicher Probleme bei bestimmten Einstellungskombinationen wird empfohlen, die Funktion weiterhin deaktiviert zu lassen. Entscheiden Sie erst nach Prüfung der nachfolgenden Korrekturen, ob Sie die Einstellungen wiederherstellen."}],"sources":[{"url":"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230","title":"KISA 보호나라: Sicherheitsmaßnahmen für Unternehmen im Zusammenhang mit der PHP-Sicherheitslücke (PHP2Shell), 22. Oktober 2026","type":"source"},{"url":"https://www.php.net/archive/2026.php","title":"PHP-Mitteilungen 2026: Sicherheitsupdate vom 21. Oktober und ergänzende Hinweise zu Session upload progress vom 23. Oktober","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w","title":"PHP-Sicherheitshinweis: RCE durch OOM-bedingte Speicherbeschädigung","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp","title":"PHP-Sicherheitshinweis: RCE durch veralteten globalen Zustand","type":"source"},{"url":"https://www.php.net/supported-versions.php","title":"PHP Supported Versions: offizieller Supportzeitraum","type":"data_point"},{"url":"https://www.php2shell.com/","title":"PHP2Shell: Erläuterung der Sicherheitslücke durch das Forschungsteam und Umfang der Auswirkungen","type":"source"},{"url":"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588","title":"개인정보보호위원회: Aufruf zu Maßnahmen zur Verhinderung der Offenlegung personenbezogener Daten im Zusammenhang mit der PHP-Sicherheitslücke, 22. Oktober 2026","type":"source"}],"images":[{"id":2106,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"서버실에서 여성이 랙 서버의 네트워크 포트 앞에 파란 랜 케이블 커넥터를 들고 있다.","caption":"침해가 의심되면 서버를 격리하고 재시작 전에 증거를 보존해야 합니다.","description":null},"en":{"alt":"A woman holds a blue Ethernet cable connector near a rack server’s network port in a server room.","caption":"If a compromise is suspected, isolate the server and preserve evidence before restarting.","description":null},"ja":{"alt":"サーバールームで、女性がラックサーバーのネットワークポートの前に青いLANケーブルのコネクターを持っている。","caption":"侵害が疑われる場合は、サーバーを隔離し、再起動前に証拠を保全する必要があります。","description":null},"es":{"alt":"Una mujer sostiene el conector de un cable Ethernet azul junto al puerto de un servidor en una sala de servidores.","caption":"Si se sospecha una intrusión, hay que aislar el servidor y preservar las pruebas antes de reiniciarlo.","description":null},"id":{"alt":"Seorang perempuan memegang konektor kabel Ethernet biru di dekat port jaringan server rak di ruang server.","caption":"Jika dicurigai terjadi penyusupan, isolasi server dan amankan bukti sebelum memulai ulang.","description":null},"pt":{"alt":"Uma mulher segura o conector de um cabo Ethernet azul perto da porta de um servidor em uma sala de servidores.","caption":"Se houver suspeita de invasão, isole o servidor e preserve as evidências antes de reiniciá-lo.","description":null},"zh-hant":{"alt":"一名女子在伺服器機房內，手持藍色網路線接頭，靠近機架式伺服器的網路埠。","caption":"若懷疑遭到入侵，應先隔離伺服器，並在重新啟動前保全證據。","description":null},"de":{"alt":"Eine Frau hält den Stecker eines blauen Netzwerkkabels vor den Netzwerkanschluss eines Rackservers.","caption":"Bei Verdacht auf einen Angriff muss der Server isoliert und müssen vor dem Neustart Beweise gesichert werden.","description":null}}},{"id":2107,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp","is_representative":false,"generation_method":"ai_semi","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"공장에서 중년 기술자가 열린 네트워크 장비함 옆 태블릿의 상태 화면을 확인하는 모습","caption":"PHP 실행 서비스를 재시작한 뒤 실제 웹 서비스에 패치가 반영됐는지 확인해야 합니다.","description":null},"en":{"alt":"An older technician checks a tablet status screen beside an open network equipment cabinet in a factory.","caption":"After restarting PHP services, verify that the patch has taken effect on the live web service.","description":null},"ja":{"alt":"工場で、開いたネットワーク機器盤の横にあるタブレットの状態画面を確認する年配の技術者","caption":"PHP実行サービスの再起動後、実際のWebサービスにパッチが反映されていることを確認してください。","description":null},"es":{"alt":"Un técnico mayor revisa una tableta junto a un armario abierto con equipos de red en una fábrica.","caption":"Tras reiniciar los servicios de PHP, compruebe que el parche se haya aplicado al servicio web en producción.","description":null},"id":{"alt":"Teknisi senior memeriksa layar status tablet di samping kabinet perangkat jaringan yang terbuka di pabrik.","caption":"Setelah memulai ulang layanan PHP, pastikan patch telah diterapkan pada layanan web yang beroperasi.","description":null},"pt":{"alt":"Um técnico mais velho verifica um tablet ao lado de um armário aberto com equipamentos de rede numa fábrica.","caption":"Após reiniciar os serviços PHP, confirme que a correção foi aplicada ao serviço web em produção.","description":null},"zh-hant":{"alt":"一名年長技術人員在工廠內，查看開啟的網路設備櫃旁平板電腦上的狀態畫面","caption":"重新啟動 PHP 執行服務後，應確認實際運作的網頁服務已套用修補程式。","description":null},"de":{"alt":"Ein älterer Techniker prüft ein Tablet neben einem offenen Netzwerkschrank in einer Fabrik.","caption":"Prüfen Sie nach dem Neustart der PHP-Dienste, ob der Patch im laufenden Webdienst wirksam ist.","description":null}}}],"published_at":"2026-10-24T16:09:48+09:00","updated_at":"2026-10-24T16:09:48+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/php2shell-enterprise-security-patch-response-guide"}