---
title: "PHP2Shell: Unternehmensserver absichern"
locale: de
category: how_to
category_name: "Anleitungen"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/php2shell-enterprise-security-patch-response-guide
published_at: 2026-10-24T16:09:48+09:00
---

# PHP2Shell: Unternehmensserver absichern

> 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.

## 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.

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.

Die Angaben zu Versionen und Einstellungen beruhen auf der KISA-Mitteilung vom 22. Oktober 2026 und der ergänzenden PHP-Mitteilung vom 23. Oktober.

## Was für eine Schwachstelle ist PHP2Shell?

PHP2Shell 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.

| Kategorie | Kennung | Art des Problems |
| --- | --- | --- |
| Problem bei der Behandlung von Speichermangel | CVE-2026-109618 | Verarbeitung unvollständiger interner Daten bei Speichermangel |
| 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 |

KISA 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.

KISA 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&menuNo=205020&nttId=72230), [Erläuterungen des Forschungsteams zu PHP2Shell](https://www.php2shell.com/)

## Reihenfolge der Maßnahmen je nach Situation

Die 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.

| Aktueller Zustand | Zuerst zu erledigen | Anschließend zu erledigen |
| --- | --- | --- |
| Ö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 |
| Webshell oder verdächtige Verbindung entdeckt | Vom Netzwerk isolieren und Vorfall melden | Nach der Beweissicherung Wiederherstellungsmaßnahmen durchführen |
| Server, der nicht sofort aktualisiert werden kann | Offizielle vorläufige Einstellungen anwenden und Anfragen auf vorgeschalteten Systemen begrenzen | Patchtermin festlegen und Patch einspielen |
| 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 |
| 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 |

Der 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.

## So erfassen Sie den PHP-Einsatz

Prü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.

1. Erstellen Sie eine Liste der im Internet öffentlich zugänglichen Websites und Systeme.
2. Prüfen Sie extern erstellte und ältere Websites.
3. Prüfen Sie Server für Veranstaltungen und Tests sowie Administrationsseiten.
4. Prüfen Sie, ob Verwaltungsoberflächen von Geräten und Softwarelösungen PHP enthalten.
5. Prüfen Sie Container-Images und laufende Container.
6. Dokumentieren Sie für jede Umgebung die PHP-Version und die zuständige Person.

Wenn 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.

## Korrigierte PHP-Versionen und Kriterien zum Supportende

Die 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.

| Verwendete Versionsreihe | Korrigierte Version für beide Schwachstellen | Maßstab für die Maßnahmen |
| --- | --- | --- |
| PHP 8.5 | 8.5.13 oder höher | Aktuelle Sicherheitsversion der jeweiligen Reihe prüfen |
| PHP 8.4 | 8.4.27 oder höher | Aktuelle Sicherheitsversion der jeweiligen Reihe prüfen |
| PHP 8.3 | 8.3.36 oder höher | Aktuelle Sicherheitsversion der jeweiligen Reihe prüfen |
| PHP 8.2 | 8.2.35 oder höher | Neben dem Patch den Wechsel zu einer höheren Versionsreihe vorbereiten |
| PHP 8.1 und älter | Regulärer Sicherheitssupport beendet | Zu einer unterstützten Versionsreihe wechseln oder Patches des Anbieters prüfen |

Die 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)

Der 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)

Fü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.

## So führen Sie Update und Neustart durch

Nach 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.

1. Prüfen Sie, wie sich der Patch auf bestehende Funktionen auswirkt.
2. Prüfen Sie in einer Testumgebung die Kompatibilität des Dienstes.
3. Spielen Sie die korrigierten Pakete zuerst auf den im Internet öffentlich zugänglichen Servern ein.
4. Starten Sie alle Dienste neu, die PHP ausführen.
5. Stellen Sie Container-Umgebungen mit korrigierten Images erneut bereit.
6. Prüfen Sie, ob die Änderungen bei dem PHP wirksam sind, das die tatsächlichen Webanfragen verarbeitet.

Zu 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.

`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.

## Vorgaben für vorläufige Einstellungen vor dem Update

Vorlä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.

### Wie wird memory_limit eingestellt?

Die 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.

Durch 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)

| Parameter | Offizielle vorläufige Maßnahme | Bei der Anwendung zu prüfen |
| --- | --- | --- |
| `memory_limit` | Auf `-1` setzen | Administratoreinstellung verwenden, damit die Anwendung den Wert nicht ändern kann |
| `session.upload_progress.enabled` | Auf `0` setzen | Eine Konfigurationsstelle verwenden, die vor der Anfrageverarbeitung wirksam wird |
| `post_max_size` | `8M` als Beispiel, wenn keine Uploads benötigt werden | Tatsächliche Dienstanforderungen und vorgeschaltete Begrenzungen gemeinsam prüfen |
| `upload_max_filesize` | Kleiner als `post_max_size` festlegen | Auswirkungen auf die Datei-Upload-Funktion prüfen |
| `fatal_error_backtraces` | Unter PHP 8.5 auf `0` setzen | Nicht pauschal auf andere Versionsreihen anwenden |

Die 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.

1. Begrenzen Sie die Anfragegröße in der Web Application Firewall, im Webserver und im Proxy.
2. Prüfen Sie, ob die Begrenzungen auch für Anfragen ohne Größenangabe gelten.
3. Blockieren Sie multipart-Anfragen auf vorgeschalteten Systemen, wenn keine Uploads benötigt werden.
4. Prüfen Sie die aktuellen Blockierregeln der Web Application Firewall.
5. Wenden Sie die Einstellungen in `php.ini`, im PHP-FPM-Pool oder an vergleichbarer Stelle an.
6. Prüfen Sie, ob Beweise gesichert werden müssen, und starten Sie anschließend die PHP-Prozesse neu.

Wenden 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)

### Was Sie in der ergänzenden Mitteilung vom 23. Oktober prüfen sollten

PHP 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.

Zu 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)

## So prüfen Sie Protokolle und tauschen Zugangsdaten aus

KISA 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.

| Prüfbereich | Zu suchende Spuren |
| --- | --- |
| Webserver-Protokolle | Wiederholte HTTP-500-Fehler |
| PHP-Ausführungsprotokolle | Unerwartete Abbrüche und segfault |
| Web-, Upload- und temporäre Verzeichnisse | Neu angelegte oder geänderte PHP-Dateien |
| Protokolle zur Prozessausführung | Ausführung von sh, bash oder Download-Werkzeugen durch den Webserver |
| Netzwerkverbindungen | Spuren neuer Verbindungen zu unbekannten externen Adressen |
| Website und Administrationsseiten | Heimlich hinzugefügte externe Skripte |

Fehler 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:

> 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.
>
> KISA „Sicherheitsmaßnahmen für Unternehmen zu PHP-Sicherheitslücken (PHP2Shell)“

Fü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.

Prü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&mCode=C010010000&nttId=12588)

## Vorgehen bei Verdacht auf eine Kompromittierung

Schalten 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.

1. Sperren Sie auf Netzwerkebene die externen Verbindungen des Servers.
2. Unternehmen in Korea melden den Vorfall über das Menü zur Meldung von Sicherheitsvorfällen auf 보호나라.
3. Sichern Sie Protokolle und die Liste der laufenden Programme.
4. Sichern Sie auch die Informationen zu den aktuellen Netzwerkverbindungen.
5. Führen Sie nach der Beweissicherung das Update und den Neustart durch.
6. Entfernen Sie Webshells und tauschen Sie Zugangsdaten aus.

Die Beratungsstelle in Korea ist KISA 118. Der Menüpfad für die Meldung lautet 보호나라 > Sicherheitsvorfall melden > Meldung einreichen. Wenn Sie im Ausland tätig sind, prüfen Sie die zuständige örtliche Meldestelle.

## Häufige Fehleinschätzungen im Vergleich

Um 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.

| Häufige Einschätzung | Was geprüft werden muss |
| --- | --- |
| Wenn sich `php -v` geändert hat, ist alles erledigt | Das vom Webdienst tatsächlich verwendete PHP prüfen |
| Mit der Paketinstallation ist alles erledigt | Neustart der PHP-ausführenden Dienste bestätigen |
| Wenn die Versionsnummer unverändert ist, wurde nichts unternommen | Im Änderungsprotokoll der Distribution prüfen, ob die CVEs behoben wurden |
| Mit einer Web Application Firewall kann auf den Patch verzichtet werden | Aktuelle Regeln prüfen und zugleich PHP aktualisieren |
| Wenn die Protokolle unauffällig sind, gab es keinen Datenabfluss | Auch eine mögliche Offenlegung von Zugangsdaten prüfen |
| Um extern erstellte Websites kümmert sich der Anbieter von selbst | Für jeden Dienst einen Nachweis der Umsetzung anfordern |

Fü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.

## Prüfliste zum Abschluss der Maßnahmen in extern betreuten und Hosting-Umgebungen

Im 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.

| Prüfpunkt | Beim Anbieter oder der zuständigen Person anzufordernde Angaben |
| --- | --- |
| Vollständigkeit der erfassten Systeme | Prüfliste für Websites, Administrationsseiten und Testserver |
| Behebung der Schwachstellen | Eingespielte Version oder Paketänderungsprotokoll mit beiden CVEs |
| Laufender Betrieb | Nachweis über den Neustart der Dienste oder die erneute Bereitstellung der Container |
| Tatsächliche Wirksamkeit | Im Webdienst überprüfte PHP-Laufzeitumgebung |
| Prüfung auf Kompromittierung | Zeitraum der geprüften Protokolle und festgestellte Auffälligkeiten |
| Zugangsdaten | Auszutauschende Zugangsdaten und Stand des Austauschs |
| Verbleibende Arbeiten | Server mit ausschließlich vorläufigen Maßnahmen und Plan für nachfolgende Patches |

Angenommen, 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.

## FAQ

### Lässt sich PHP2Shell durch Ändern des Anmeldepassworts verhindern?
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.

### Muss man bei PHP 8.5 auf 8.5.13 warten?
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.

### Ist bei Verwendung von PHP-FPM keine Überprüfung nötig?
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.

### Sind die Maßnahmen abgeschlossen, wenn php -v eine Version mit den Fehlerbehebungen anzeigt?
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.

### Ist der Patch fehlgeschlagen, wenn die Versionsnummer danach unverändert bleibt?
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.

### Ist die Einstellung memory_limit=-1 bei den aktuellen Gegenmaßnahmen verboten?
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.

### Sind auch Websites ohne Datei-Upload betroffen?
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.

### Kann ich PHP 8.1 oder eine ältere Version weiterverwenden, wenn ein Patch des Anbieters vorliegt?
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.

### Kann ich die Zugangsdaten beibehalten, wenn die Protokolle keine Auffälligkeiten zeigen?
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.

### Sollte ich bei Verdacht auf eine Kompromittierung zuerst ein Update durchführen?
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.

### Was sollten Hosting-Nutzer prüfen?
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.

### Kann ich die Einstellung für den Uploadfortschritt nach dem Patchen wieder aktivieren?
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

- [KISA 보호나라: Sicherheitsmaßnahmen für Unternehmen im Zusammenhang mit der PHP-Sicherheitslücke (PHP2Shell), 22. Oktober 2026](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230)
- [PHP-Mitteilungen 2026: Sicherheitsupdate vom 21. Oktober und ergänzende Hinweise zu Session upload progress vom 23. Oktober](https://www.php.net/archive/2026.php)
- [PHP-Sicherheitshinweis: RCE durch OOM-bedingte Speicherbeschädigung](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
- [PHP-Sicherheitshinweis: RCE durch veralteten globalen Zustand](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
- [PHP Supported Versions: offizieller Supportzeitraum](https://www.php.net/supported-versions.php)
- [PHP2Shell: Erläuterung der Sicherheitslücke durch das Forschungsteam und Umfang der Auswirkungen](https://www.php2shell.com/)
- [개인정보보호위원회: Aufruf zu Maßnahmen zur Verhinderung der Offenlegung personenbezogener Daten im Zusammenhang mit der PHP-Sicherheitslücke, 22. Oktober 2026](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## Images

![Eine Frau hält den Stecker eines blauen Netzwerkkabels vor den Netzwerkanschluss eines Rackservers.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp)
![Ein älterer Techniker prüft ein Tablet neben einem offenen Netzwerkschrank in einer Fabrik.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp)