PHP2Shell (CVE-2026-109618 und CVE-2026-109619): Was Unternehmen mit PHP jetzt tun sollten

Ein Techniker mit Laptop arbeitet an einem Serverschrank

Am 21. Oktober 2026 hat das PHP-Projekt PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Die Versionen beheben zwei Schwachstellen, die „eine Codeausführung aus der Ferne ohne Authentifizierung ermöglichen können“. Einfach gesagt: Wer eine HTTP-Anfrage an Ihre Website schicken kann, kann unter Umständen eigenen Code auf Ihrem Server ausführen. Ein Passwort braucht er dafür nicht, und bei manchen Setups greift der Angriff, bevor Ihre Anwendung auch nur eine Zeile ausgeführt hat. Die beiden Lücken laufen unter dem Namen PHP2Shell, und PHP bewertet beide mit 9,2 (CVSS 4.0, auf einer Skala bis 10).

Dieser Leitfaden richtet sich an alle, die jetzt handeln müssen: Inhaber von PHP-Websites und Onlineshops, IT-Verantwortliche und alle, für die ein Dienstleister PHP betreibt. Er entstand am 22. Oktober 2026, einen Tag nach dem Release, auf Grundlage der Sicherheitshinweise des PHP-Projekts, der Empfehlungen nationaler Cybersicherheitsbehörden und der Zahlen, die Anbieter veröffentlicht haben. Wo die Quellen sich widersprechen, sagen wir das.

Das Wichtigste in Kürze

Aktualisieren Sie PHP selbst und starten Sie es danach neu. Ein Update von WordPress, Drupal, Laravel oder einem Plugin behebt das Problem nicht. Die Lücke steckt in PHP, unterhalb Ihrer Anwendung.
Betroffen ist jede PHP-Installation, die Webanfragen beantwortet, laut PHP: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht PHP bei Apache mit mod_php.
Fast die Hälfte aller PHP-Websites läuft auf einem Zweig, für den das PHP-Projekt keine Releases mehr veröffentlicht (unsere Auswertung der Daten von W3Techs, siehe unten). Für diese Websites gibt es kein offizielles Paket, das man installieren könnte.
Einstellungen und Firewalls verschaffen Zeit, aber keine Sicherheit. PHP nennt Übergangsmaßnahmen und sagt dazu, dass sie „eine Installation nicht sicher machen“.
Wenn Sie heute nicht patchen können, raten die Behörden in den USA, im Vereinigten Königreich und in der EU übereinstimmend: Trennen Sie das System vom Internet, bis Sie patchen können.

Was passiert ist, der Reihe nach

19. August 2026. Forscher von Wiz finden laut ihrer Veröffentlichung die erste der beiden Lücken und melden beide am 24. August dem Sicherheitsteam von PHP. In den Sicherheitshinweisen von PHP werden außerdem Forscher mehrerer anderer Firmen genannt.
20. Oktober. Die CVE-Nummern gelangen zwei Tage vor der geplanten Offenlegung ins Netz. PHP zieht sein Release um einen Tag vor, auf den 21. Oktober um 14:00 UTC, und fordert alle auf, sich vorzubereiten.
21. Oktober, 03:02 UTC. Cloudflare aktiviert Firewall-Regeln für alle Kunden, die seine WAF nutzen, auch im kostenlosen Tarif. Später berichtet das Unternehmen, es habe „Angriffsverkehr beobachtet, der auf unsere Kunden zielte“, und gesehen, wie Angreifer „die Angriffs-Payload veränderten, um zu versuchen, unsere Schutzmaßnahmen zu umgehen“.
21. Oktober, gegen 14:00 UTC. PHP veröffentlicht die Fixes und seinen Sicherheitshinweis. Am selben Tag fordern die CISA in den USA, das britische NCSC, das CERT-EU und eine gemeinsame Erklärung der Europäischen Kommission, der ENISA, des CERT-EU, von Europol und der nationalen CSIRTs der EU übereinstimmend dazu auf, sofort zu patchen.

Wie ernst ist es?

Drei Dinge unterscheiden diesen Fall vom üblichen monatlichen Patch.

Der Angreifer braucht nichts außer einer Anfrage. Kein Login, und niemand muss auf einen Link klicken. Der Sicherheitshinweis von PHP beschreibt einen demonstrierten Exploit gegen Apache mit mod_php, „bei dem eine nicht authentifizierte Anfrage den Angriff auslösen kann, bevor irgendein Anwendungscode läuft“. Wiz hat Angriffe auf aktuelle Versionen von WordPress, Drupal und Joomla demonstriert und merkt an, dass „selbst eine einfache ‚Hello World‘-Anwendung auf einer betroffenen PHP-Version verwundbar sein kann“. Auf diesem Weg ausgeführter Code hat die Rechte des Webserver-Kontos, und das kann auf den meisten Websites die Konfiguration der Anwendung lesen: das Datenbankpasswort, API-Schlüssel, Zugangsdaten für E-Mail und Zahlungen. Für die zweite Lücke, CVE-2026-109619, bestätigt PHP außerdem eine Offenlegung von Speicherinhalten: Daten aus dem Arbeitsspeicher des Servers gelangen nach außen, auch ohne vollständige Codeausführung.

Die Verbreitung ist enorm. Laut W3Techs läuft PHP auf 69,3 % der Websites, deren serverseitige Sprache bekannt ist (Zahlen vom 22. Oktober 2026). Unit 42 von Palo Alto Networks zählt auf Basis eigener Internet-Scans über 22,6 Millionen exponierte Instanzen, die potenziell verwundbar sind, und berichtet, dass mindestens eine europäische Regierung ihre Website vorsorglich vom Netz genommen hat.

Die Arbeit an Exploits kommt schnell voran. Das CERT-EU berichtet, dass erste Proofs of Concept „zu kursieren begonnen haben“. Das Sicherheitsunternehmen watchTowr sagt, seine Honeypots hätten seit dem 21. Oktober eine Ausnutzung der Lücken erfasst. Cloudflare meldet Angriffsverkehr. Und Wiz sagt, seine Forscher hätten durchgehend KI-Modelle eingesetzt, sodass ein einzelner Forscher in einer Woche schaffte, was „ein Weltklasse-Team Monate gekostet hätte“. Angreifer, die einen Exploit an Ihre PHP-Version anpassen, haben dieselben Werkzeuge.

Der Fairness halber auch die andere Seite: Als die CISA am 21. Oktober ihre Warnung veröffentlichte, hatte sie keine Ausnutzung beobachtet, und keine der beiden Lücken stand bereits in ihrem Katalog Known Exploited Vulnerabilities (bekannte ausgenutzte Schwachstellen). Red Hat stuft das Problem als „Important“ (wichtig) und nicht als kritisch ein, weil ein Standardserver mit Red Hat Enterprise Linux PHP-FPM verwendet, wo die Ausnutzung schwieriger ist. Schwieriger heißt nicht unmöglich: PHP bestätigt, dass ein Angriffsweg für die zweite Lücke auch unter PHP-FPM funktioniert. An dem, was Sie tun sollten, ändert das alles nichts. Es ändert nur, wie viel Vorwarnung Sie bekommen werden.

Welche Version setzen Sie ein? Die Zahlen

W3Techs veröffentlicht auch, welche PHP-Versionen Websites nutzen, und zählt dabei die Websites, die ihre Version preisgeben. Legt man die beiden Tabellen vom 22. Oktober 2026 zusammen, ergibt sich folgendes Bild:

PHP-Zweig	Anteil an PHP-Websites	Fix vom PHP-Projekt
8.3, 8.4, 8.5	etwa 34 %	Ja: 8.3.36, 8.4.27, 8.5.12
8.2	etwa 18 %	Ja: 8.2.35. Aber 8.2 selbst erreicht am 31. Dezember 2026 sein Supportende
8.0, 8.1	etwa 14 %	Kein Release. 8.0 und 8.1: nur Quellcode-Backport
7.x	26,9 %	Kein Release. 7.4: nur Quellcode-Backport; 7.3 und älter: nichts
5.x und älter	7,8 %	Nichts

Etwa 48 % der PHP-Websites laufen also auf einem Zweig, für den das PHP-Projekt kein korrigiertes Release veröffentlicht, und weitere 18 % bekommen ihren Fix jetzt und verlieren in zehn Wochen den Support.

Zwei Einschränkungen. W3Techs sieht nur die Websites, die ihre Version zeigen. Und eine Linux-Distribution kann einen alten Zweig selbst gepatcht haben: Ubuntu hat das getan, wie Sie unten sehen werden. Die Versionsnummer allein sagt Ihnen nicht, ob Sie geschützt sind. Das sagt Ihnen die Version des Pakets Ihres Anbieters.

Schritt 1: Finden Sie jedes PHP, das Sie betreiben

Was Sie nicht erfasst haben, können Sie nicht patchen, und PHP versteckt sich gut. Das britische NCSC fordert Organisationen auf, jedes PHP-System zu finden, zuerst die aus dem Internet erreichbaren, und ergänzt: „Beschränken Sie die Suche nicht auf veraltete PHP-Versionen.“ Die gemeinsame Erklärung der EU warnt, dass manche Produkte „von diesen Schwachstellen betroffen sein können, auch wenn sie PHP scheinbar nicht direkt verwenden“.

Wo Sie suchen sollten:

Websites und Shops: WordPress und WooCommerce, Drupal, Joomla, Magento und Adobe Commerce, Shopware, PrestaShop, TYPO3 und alles, was auf Laravel oder Symfony aufbaut.
Die Vergessenen: Microsites für Kampagnen, eine alte Sprachversion, Staging- und Testserver, die aus dem Internet erreichbar sind, das Webmail oder Helpdesk, das jemand vor Jahren installiert hat.
Container: Jedes Image, das auf einem php-Basis-Image aufbaut, bringt sein eigenes PHP mit. Ein Update des Hosts ändert daran nichts.
Hosting-Panels: cPanel, Plesk und ähnliche Panels bringen neben dem PHP des Systems eigene PHP-Builds mit. Jede im Panel aktivierte Version muss für sich aktualisiert werden.
Produkte mit PHP im Inneren: Appliances, Monitoring-Tools, CRM-Systeme, Helpdesks und Administrationsoberflächen von Anbietern. Das niederländische NCSC führt eine öffentliche Liste solcher Produkte mit ihrem Status, Anbieter für Anbieter.
Dienstleister: Ihr Hosting-Anbieter, Ihre Agentur, jeder Dienst, bei dem Sie wissen, dass PHP darunterliegt. Fragen Sie schriftlich nach, welche PHP-Versionen auf Ihren Systemen laufen und wann sie gepatcht werden.

Halten Sie für jedes System fest: die PHP-Version, wie PHP läuft (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, ein Container), ob es aus dem Internet erreichbar ist und wer es patchen kann.

Schritt 2: Patchen, in der richtigen Reihenfolge

Beginnen Sie mit allem, was aus dem Internet erreichbar ist, und darunter zuerst mit Setups aus Apache und mod_php.

Auf einem unterstützten Zweig (8.2 bis 8.5). Aktualisieren Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf das Paket Ihrer Distribution, das den Fix enthält. Laut PHP haben die Linux-Distributionen die Patches vorab erhalten. Bisher bestätigt:

Ubuntu: korrigierte Pakete für jedes Release von 14.04 bis 26.10. Unter 22.04 und neuer kommen sie mit den normalen Updates; unter 20.04 und älter setzen sie ein Abonnement für Ubuntu Pro voraus, das für bis zu fünf Rechner kostenlos ist (Mitteilung von Canonical).
Debian: php8.4 8.4.27 für Debian 13 (DSA-6574-1) und php8.2 8.2.35 für Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: Das Sicherheitsbulletin RHSB-2026-013 von Red Hat listet die Pakete je Release auf.
Das Remi-Repository, auf Systemen der Red-Hat-Familie weit verbreitet für neuere PHP-Versionen: Am 21. Oktober stellte das CERT-EU fest, dass es am Tag des Releases keine Pakete hatte, und riet, auf Pakete der Distribution umzusteigen oder aus dem Quellcode zu bauen. Prüfen Sie, ob es inzwischen nachgezogen hat, bevor Sie sich darauf verlassen.

Auf PHP 7.4, 8.0 oder 8.1. Das PHP-Projekt veröffentlicht für diese Zweige kein Release. Sein Sicherheitsteam hat für die drei Zweige minimale Backports im Quellcode erstellt, die helfen, wenn Sie PHP selbst kompilieren. Andernfalls muss der Fix von Ihrem Anbieter kommen (Ubuntu Pro deckt zum Beispiel PHP 7.4 unter Ubuntu 20.04 ab) oder aus einem Upgrade von PHP. Der Rat der CISA an alle mit 8.1 oder älter, die nicht aktualisieren können, ist unmissverständlich: Nehmen Sie das System vom Netz, bis es gepatcht ist oder ein Upgrade erhalten hat.

Auf PHP 7.3 oder älter. Vom PHP-Projekt kommt nichts. Sofern nicht ein Anbieter Ihren Build noch patcht, bleibt nur die Wahl zwischen einem Upgrade und dem Abschalten des Systems.

Nach dem Update neu starten. Die Installation eines Pakets ersetzt nicht das PHP, das bereits läuft. Die Mitteilung von Ubuntu sagt es klar: Die Anwendung „müsste wahrscheinlich neu gestartet werden“. Starten Sie PHP-FPM, Apache, LiteSpeed oder den Container auf jedem Server neu. Prüfen Sie dann die Version, die der Webserver tatsächlich ausführt, und nicht nur php -v auf der Kommandozeile, denn das kann ein anderer Build sein.

Container: Bauen Sie Ihre Images aus einem gepatchten Basis-Image neu und deployen Sie sie erneut. Ein gepatchter Host, auf dem ein altes Image läuft, bleibt angreifbar.

Managed Hosting: Fragen Sie Ihren Anbieter nach Datum und Version, und prüfen Sie dann selbst nach.

Schritt 3: Wenn Sie heute nicht patchen können

Der Sicherheitshinweis von PHP nennt Übergangsmaßnahmen und leitet sie mit einer Warnung ein: Sie „verringern die Angriffsfläche für bestimmte Angriffswege, machen eine Installation aber nicht sicher“. Kurz zusammengefasst, für alle, die Ihre Server betreiben:

Für CVE-2026-109618: Setzen Sie memory_limit=-1 so, dass die Anwendung den Wert nicht überschreiben kann (zum Beispiel mit php_admin_value im PHP-FPM-Pool oder in der Apache-Konfiguration); setzen Sie post_max_size auf einen niedrigen Wert (PHP schlägt 8M ohne Datei-Uploads vor, 32M mit Datei-Uploads); begrenzen Sie Anfragegröße, Anzahl der Felder und Multipart-Teile am Webserver oder Proxy; und verwenden Sie ein Speicherlimit über Container oder cgroup, niemals RLIMIT_AS oder RLIMIT_DATA.
Für CVE-2026-109619: Setzen Sie session.upload_progress.enabled=0 in der php.ini oder in der Serverkonfiguration (nicht mit ini_set() oder einer .user.ini-Datei) und starten Sie jeden Worker neu. Unter PHP 8.5 setzen Sie zusätzlich fatal_error_backtraces=0.

Zwei Warnungen. Die Session-Einstellung, die sich am 20. Oktober weit verbreitet hat, schließt nur Angriffswege der zweiten Lücke, wie ein Mitglied des PHP-Sicherheitsteams klargestellt hat; gegen die erste bewirkt sie nichts. Und memory_limit=-1 hebt die eigene Speichergrenze von PHP auf, sodass eine einzige aufwendige Anfrage jetzt den gesamten Speicher des Servers aufbrauchen kann. Kombinieren Sie die Einstellung deshalb mit dem Limit über Container oder cgroup.

Eine Web Application Firewall hilft, ein wenig. Die Regeln von Cloudflare sind in jedem Tarif mit WAF standardmäßig aktiv, auch im kostenlosen, und Palo Alto Networks und andere Anbieter haben eigene Schutzmaßnahmen veröffentlicht. Cloudflare fordert seine Kunden trotzdem auf, PHP „auch mit WAF-Schutz“ zu patchen, und hat beobachtet, wie Angreifer ihre Payloads veränderten, um an den Regeln vorbeizukommen. Eine WAF schützt außerdem nur den Verkehr, der durch sie hindurchläuft. Wenn Ihr Server unter seiner eigenen IP-Adresse antwortet, kann ein Angreifer sie umgehen.

Wenn sich nichts davon schnell umsetzen lässt, weisen CISA, CERT-EU, das NCSC und die gemeinsame Erklärung der EU in dieselbe Richtung: Nehmen Sie das System aus dem öffentlichen Internet, bis es behoben ist. Eine Wartungsseite für einen Tag kostet weniger als ein neu aufgesetzter Server.

Schritt 4: Prüfen Sie, ob Sie bereits getroffen wurden

Das Zeitfenster öffnete sich am 20. Oktober mit dem Leak, und Angriffsverkehr wurde am nächsten Morgen gemeldet. War ein System in diesem Zeitfenster erreichbar und ungepatcht, schließt das Patchen die Tür, sagt Ihnen aber nicht, ob vorher schon jemand hereingekommen ist. Das NCSC fordert alle, die nicht sofort patchen konnten, dazu auf, nach Anzeichen einer Kompromittierung und nach Backdoors zu suchen.

Worauf Sie achten sollten, nach den veröffentlichten Empfehlungen und der üblichen Praxis bei Sicherheitsvorfällen:

PHP-Prozesse, die Dinge tun, die PHP nie tut, etwa eine Shell starten oder Werkzeuge herunterladen (CISA).
Ungewöhnliche Multipart-Anfragen, gefolgt von Fehlern wegen des Speicherlimits oder wiederholten Antworten mit HTTP 500, PHP-Worker, die ohne erkennbaren Grund neu starten, und ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies in Antworten (Wiz).
Neue oder geänderte PHP-Dateien in Upload-Ordnern, Cache-Ordnern oder im Webroot, neue Administratorkonten in Ihrem CMS und geplante Aufgaben, die niemand angelegt hat.

Saubere Logs sind kein Beweis. Der Sicherheitshinweis von PHP zur zweiten Lücke warnt genau davor, und Wiz merkt an, dass Anwendungslogs möglicherweise wenig Kontext enthalten.

Wenn Sie etwas finden, behandeln Sie es als Sicherheitsvorfall und nicht als Patch-Aufgabe. Isolieren Sie den Server, sichern Sie die Beweise, ziehen Sie einen Dienstleister für Incident Response hinzu und ändern Sie jedes Secret, das der Webserver lesen konnte: Datenbankpasswörter, API-Schlüssel, Zugangsdaten für Zahlungen und E-Mail, Signaturschlüssel. Weil die zweite Lücke Speicherinhalte offenlegen kann, sollten Sie erwägen, die sensibelsten dieser Secrets auf jedem Server auszutauschen, der tagelang exponiert und ungepatcht war, auch ohne Anzeichen eines Eindringens.

Schritt 5: Was Sie möglicherweise melden müssen

Eine Schwachstelle allein ist kein meldepflichtiger Vorfall. Eine ausgenutzte Schwachstelle kann es sein.

NIS2: Wenn Ihre Organisation erfasst ist und eine Kompromittierung ein erheblicher Sicherheitsvorfall ist, ist die Frühwarnung an Ihr nationales CSIRT innerhalb von 24 Stunden fällig. Mehr dazu in unserem NIS2-Leitfaden.
DSGVO: Wenn auf personenbezogene Daten zugegriffen wurde, muss die Aufsichtsbehörde innerhalb von 72 Stunden, nachdem Ihnen die Datenschutzverletzung bekannt geworden ist, benachrichtigt werden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für Personen. Mehr dazu in unserem DSGVO-Leitfaden.
Cyber Resilience Act: Wenn Sie Software oder ein Gerät mit PHP im Inneren verkaufen, sind Sie nach dem CRA dessen Hersteller. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten über die zentrale CRA-Meldeplattform melden, woran die gemeinsame Erklärung der EU erinnert. Mehr dazu in unserem CRA-Leitfaden.
Ihre Kunden: Wenn Sie PHP für Kunden hosten oder betreiben, werden diese nachfragen. Eine kurze schriftliche Notiz (was Sie betreiben, wann gepatcht wurde, was Sie geprüft haben) beantwortet die meisten Fragen, und es ist dieselbe Notiz, die ein Auditor oder ein Cyberversicherer sehen will.

Nach dem Notfall: Was Sie ändern sollten

Auf den meisten gut geführten Servern wird PHP2Shell innerhalb von Tagen gepatcht sein. Was der Fall über Ihr Setup gezeigt hat, gilt auch danach noch.

Wissen Sie, wie lange ein Patch bei Ihnen dauert. Vom Sicherheitshinweis, bis jeder Server neu gestartet ist: Stunden, Tage oder Wochen? Wenn die ehrliche Antwort lautet „Da müssten wir die Agentur fragen“, beheben Sie das vor dem nächsten Mal. Wenn Forscher sagen, KI habe ihre Arbeit an einem Exploit von Monaten auf eine Woche verkürzt, gehen Sie davon aus, dass Angreifer genauso schnell sein können.
Behalten Sie das Inventar, das Sie gerade aufgebaut haben. Es war der schwierigste Teil der Reaktion, und es veraltet in dem Moment, in dem niemand dafür zuständig ist.
Steigen Sie von PHP-Versionen ohne Support um. Eine Website auf 7.4 oder 8.1 brauchte diesmal einen Anbieter oder einen Quellcode-Backport; beim nächsten Mal gibt es vielleicht keins von beidem. PHP 8.2 erreicht am 31. Dezember 2026 sein Supportende, eine Website, die 8.1 verlässt, sollte also direkt auf 8.3 oder neuer wechseln. Ein Wechsel der PHP-Version bedeutet oft, auch die Anwendung zu aktualisieren: Unser Artikel zum Supportende von Drupal, Umbraco und Kentico zeigt, was das bei einem CMS bedeutet.
Bevorzugen Sie PHP-FPM gegenüber mod_php, wo es geht. Diesmal war es das Setup mit dem geringeren Risiko.
Lassen Sie Upload Progress ausgeschaltet, wenn Sie es nicht nutzen. Der Sicherheitshinweis von PHP empfiehlt, session.upload_progress.enabled auch nach dem Patchen ausgeschaltet zu lassen, wenn die Anwendung es nicht braucht.
Schreiben Sie Patch-Zeiten in Ihre Verträge. Fragen Sie Ihren Hosting-Anbieter und Ihre Agentur, wie schnell sie kritische PHP-Fixes einspielen, und lassen Sie sich die Antwort schriftlich geben.

Eine Checkliste für diese Woche

Erfassen Sie jede PHP-Installation, einschließlich Containern, Hosting-Panels, Produkten von Anbietern und Staging-Servern.
Patchen Sie zuerst die aus dem Internet erreichbaren Systeme, beginnend mit Apache mod_php.
Starten Sie jeden PHP-Prozess neu und prüfen Sie die Version, die der Webserver meldet.
Bauen Sie Container-Images neu und deployen Sie sie erneut.
Wo Sie heute nicht patchen können, setzen Sie die Übergangseinstellungen von PHP um, leiten Sie den Verkehr über eine WAF oder nehmen Sie das System vom Netz.
Fragen Sie Dienstleister und Hosting-Anbieter schriftlich nach ihrer PHP-Version und ihrem Patch-Datum.
Prüfen Sie Logs und Dateiänderungen auf allen Systemen, die seit dem 20. Oktober exponiert und ungepatcht waren.
Entscheiden Sie, ob eine Meldepflicht (NIS2, DSGVO, CRA) greift.
Planen Sie den Umstieg weg von PHP 8.1 und älter, und weg von 8.2 vor dem 31. Dezember.

Wobei wir helfen können

Den meisten Unternehmen fehlt nicht der Wille zum Patchen. Was ihnen fehlt, ist ein klares Bild davon, was sie betreiben, oder die Leute, die die Arbeit diese Woche erledigen. Diesen Teil übernehmen wir:

Inventar und Patchen, innerhalb von Tagen. Wir finden Ihre PHP-Installationen auf Servern, in Containern, in Hosting-Panels und bei Dienstleistern, patchen sie, starten neu, prüfen nach und hinterlassen Ihnen eine schriftliche Dokumentation darüber, was wann erledigt wurde. Diese Dokumentation ist zugleich Ihre Antwort an Kunden und Auditoren.
Weg von altem PHP. Anwendungen, die auf PHP 7.x, 8.0 oder 8.1 festhängen, weil der Code auf nichts Neuerem läuft: Wir portieren sie im Rahmen unserer Wartung von Bestandssystemen auf eine unterstützte Version.
Härtung und eine Patch-Routine, damit der nächste Sicherheitshinweis ein geplanter Auftrag ist und kein Notfall.

Wenn Sie Anzeichen eines Einbruchs finden, rufen Sie zuerst einen Dienstleister für Incident Response an. Den Neuaufbau und das Upgrade können wir parallel dazu übernehmen.

Schreiben Sie an office@c9group.dev, was Sie betreiben, und wir antworten Ihnen, was wir als Erstes tun würden.

Quellen

Geprüft am 22. Oktober 2026. Die Lage entwickelt sich weiter: Vor allem der Stand der Ausnutzung und die Pakete der Anbieter können sich seitdem geändert haben.

PHP-Projekt

Behörden

Forscher, Anbieter und Daten