Aktualisiert am 57 Min. Lesezeit
Sébastien Nobour
Gründer von DEVEDANOS
PHP ist eine Programmiersprache. Ihre Entwickler beschreiben sie als vielseitige Skriptsprache, die sich besonders für das Web eignet: Auf dem Server erzeugt sie jede Seite einer Website in dem Moment, in dem ein Besucher sie aufruft. Laut W3Techs, einem Dienst, der misst, welche Technologien Websites verwenden, wird PHP im Oktober 2026 von 69,3 % der Websites verwendet, deren serverseitige Sprache bekannt ist. WordPress, Drupal, Magento, PrestaShop, Laravel und Symfony sind in PHP geschrieben.
Am 21. Oktober 2026 hat das PHP-Team außerplanmäßig neue Versionen der Sprache veröffentlicht. Sie schließen zwei kritische Sicherheitslücken, die ihre Entdecker PHP2Shell getauft haben. Mit wenigen Anfragen, ohne Konto und ohne Passwort, kann ein Angreifer den Server, auf dem eine Website gehostet wird, seinen eigenen Code ausführen lassen. Und das alles geschieht, noch bevor der Code der Website überhaupt ausgeführt wird. Die Lücken reichen bis PHP 5.4 zurück, erschienen am 1. März 2012. Angriffe wurden bereits vor der Veröffentlichung des Patches gemeldet.
Am selben Tag haben auch GitLab und Node.js Patches für schwere Sicherheitslücken veröffentlicht. GitLab, eine Plattform, die den Code von Software hostet und dessen Tests und Deployment automatisiert, hat eine Lücke (CVE-2026-110264) geschlossen, die mit 10 von 10 bewertet ist und es ohne Konto und unter bestimmten Bedingungen erlaubte, Code auf selbst betriebenen Installationen auszuführen. Sie betraf alle Versionen seit 7.0. GitLab.com, die von GitLab gehostete Version, war bereits gepatcht.
Node.js, die Software, die JavaScript auf Servern ausführt, hat Versionen veröffentlicht, die vier Lücken mit hohem Schweregrad schließen; eine davon, in der Dekomprimierung von Daten im Brotli-Format, erlaubt es, Code aus der Ferne auszuführen. Diese Versionen aktualisieren außerdem die Liste der vertrauenswürdigen Zertifikate, nachdem eine Zwischenzertifizierungsstelle von eMudhra kompromittiert wurde.
Betreibt Ihr Unternehmen GitLab selbst, oder nutzen seine Anwendungen Node.js, stellt sich für diese Software dieselbe Frage: Welche Version verwenden wir, und wann wird sie auf eine gepatchte Version umgestellt?
Medien haben diese Patches und weitere Vorfälle der Woche unter dem Namen „Black October“ zusammengefasst. Der Name tauchte, soweit wir wissen, zum ersten Mal in einem Beitrag auf X auf, den der Entwickler Muzzammil in der Nacht vom 21. auf den 22. Oktober veröffentlichte, und wurde wenige Stunden später von Axios und von 404 Media aufgegriffen. SecurityToday, eine deutsche Nachrichtenseite zur IT-Sicherheit, sieht darin vor allem eine Häufung von Veröffentlichungen: Viele der in diesen Tagen bekannt gewordenen Angriffe hatten Wochen oder Monate früher begonnen.
Wenn Ihre Website oder Ihre Anwendung auf PHP beruht, ist die Frage, die Sie noch heute Ihrem Hosting-Anbieter oder Ihrem Dienstleister stellen sollten, einfach: Welche PHP-Version verwenden wir, und wann wird sie auf eine gepatchte Version umgestellt? Die Schritte, in der richtigen Reihenfolge, finden Sie im Abschnitt „WordPress-Website gehackt oder Sicherheitslücke entdeckt: Was tun, Schritt für Schritt“.
Der Rest gilt für jede Anwendung, in welcher Sprache sie auch geschrieben ist. Diese Lücke ist nicht die erste dieses Ausmaßes, und nichts deutet darauf hin, dass sie die letzte sein wird. Auf eine Lücke kann man sich in drei Punkten vorbereiten: was sie einem Angreifer zugänglich macht, wie lange es dauert, sie zu bemerken, und wie lange, sie zu beheben.
Die technischen Details stehen in den Abschnitten mit dem Titel „Für Ihr technisches Team“.
Auf einem Webserver ist PHP das Programm, das den Code einer Website ausführt: den von WordPress, eines PrestaShop-Shops oder einer individuell entwickelten Anwendung. Die beiden Lücken mit den Kennungen CVE-2026-109618 und CVE-2026-109619 stecken in keiner dieser Anwendungen und in keinem Plugin. Sie stecken in PHP selbst.
Das PHP-Team beschreibt sie so. Die erste wird ausgelöst, wenn PHP mitten in einer Anfrage der Speicher ausgeht: Halb vorbereitete Daten werden danach als gültig behandelt. Die zweite lässt im Speicher des Servers Informationen aus einer abgeschlossenen Anfrage zurück, die eine nachfolgende Anfrage wiederverwenden kann. Das Team bewertet sie mit einem Schweregrad von 9,2 von 10 (Skala CVSS 4.0). Laut Calif, einem Unternehmen für Sicherheitsforschung, dessen Forscher dem PHP-Team die ersten Lücken gemeldet haben, sind sie in den Standardkonfigurationen ausnutzbar.
Laut dem von Calif veröffentlichten Zeitplan stammt die erste Meldung an das PHP-Team vom 11. August 2026. Das Forschungsteam von Wiz, einem Unternehmen für Cloud-Sicherheit, legt einen abweichenden Zeitplan vor: Entdeckung am 19. August, Meldung an das PHP-Team am 24. August. Calif zählt OpenAI, den Anbieter von KI-Modellen, zu den Entdeckern. Das PHP-Team, Calif, OpenAI und Wiz bereiteten eine koordinierte Offenlegung (Coordinated Disclosure) vor, also die Lücke an dem Tag bekannt zu geben, an dem der Patch verfügbar ist, um Angreifern so wenig Zeit wie möglich zu lassen. Am 20. Oktober sickerten Details vor dem geplanten Veröffentlichungstermin durch (Patchstack). Das PHP-Team zog die Veröffentlichung um einen Tag vor (CyberScoop). Die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erschienen am 21. Oktober gegen 16 Uhr Pariser Zeit. Das PHP-Team lässt keinen Zweifel: „Es gibt keine vollständige Abhilfe, das Update ist die einzige sichere Wahl.“
Frühe Angriffe wurden am Morgen des 21. Oktober gemeldet, vor der Veröffentlichung des Patches. Cloudflare, ein Anbieter von Schutz- und Beschleunigungsdiensten für Websites, beobachtete Angriffe auf seine Kunden zwischen dem Leak und der offiziellen Veröffentlichung. Am 21. Oktober um 5:02 Uhr Pariser Zeit schaltete das Unternehmen Filterregeln für alle Kunden frei, auch im kostenlosen Tarif, und forderte sie zugleich auf, den Patch trotzdem einzuspielen. Patchstack, das die Sicherheitslücken im WordPress-Ökosystem verfolgt, berichtet, dass ihm Partner-Hoster am selben Morgen Ausnutzungen gemeldet haben. Gegen 16 Uhr Pariser Zeit erfassten seine eigenen Sensoren noch ausschließlich Erkundungsversuche, ohne Beleg für ein Eindringen. watchTowr, das Angriffe mithilfe eines Netzes von Köderservern verfolgt, gibt an, am 21. Oktober Ausnutzungen beobachtet zu haben. Laut dem Threat-Intelligence-Team von Amazon haben dessen Köderserver sogar schon am 17. Oktober einen Ausnutzungsversuch erfasst, vier Tage vor der Veröffentlichung. Der Chef von Cloudflare veröffentlichte, wie die Zahlen anstiegen (The Register): Tausende Ausnutzungsversuche (keine bestätigten Einbrüche) in seinem Netz in den zehn Stunden vor der Ankündigung, Zehntausende in den 45 Minuten danach, dann Millionen. In Japan forderte die Premierministerin die Betreiber von Websites noch am selben Tag auf, zu prüfen, ob sie PHP einsetzen, und den Patch in der Nacht einzuspielen, oder andernfalls ihre Websites vom Netz zu nehmen. Banken, Verkehrsunternehmen und Behörden in Japan und Europa setzten einen Teil ihrer Dienste aus. Am 21. Oktober standen diese Lücken laut watchTowr nicht im Katalog der ausgenutzten Schwachstellen der CISA, der US-Behörde für Cybersicherheit.
In Frankreich hat das CERT-FR, das Zentrum für die Reaktion auf Sicherheitsvorfälle der ANSSI, der nationalen Cybersicherheitsbehörde Frankreichs, noch am selben Tag eine Warnmeldung veröffentlicht. Darin empfiehlt es, die betroffenen Systeme zu isolieren und dann, sobald der Patch verfügbar ist, auf eine gepflegte und aktuelle Version umzusteigen. Das CERT-EU, sein Gegenstück für die Institutionen der Europäischen Union, rät, sofort zu patchen, und, falls das nicht möglich ist, zu erwägen, die exponierten Anwendungen vom Internet zu trennen, bis der Patch eingespielt und überprüft ist. In den USA fordert die CISA, PHP-Systeme vom Netz zu nehmen, die sich nicht sofort aktualisieren lassen oder noch mit PHP 8.1 oder älter laufen; die Cyber-Abteilung des FBI hat am 21. Oktober dieselbe Anweisung veröffentlicht.
session.upload_progress.enabled=0 (mit php_admin_flag für PHP-FPM); Calif stellt klar, dass diese Einstellung keinen Patch ersetzt. Das CERT-FR schlägt vor, Anfragen vom Typ multipart auf Ebene einer Web Application Firewall zu blockieren oder zumindest zu überwachen, und betont, dass es diese Umgehungen nicht selbst geprüft hat. Nach einer Änderung der Einstellung alle PHP-Prozesse neu starten (Patchstack); die Änderung selbst wird wie jede andere über die Pipeline oder vom Hoster eingespielt.Um das zu verstehen, muss man wissen, was PHP tut, wenn eine Anfrage eintrifft. Sendet ein Besucher ein Formular oder eine Datei, leitet der Webserver seine Anfrage an PHP weiter. PHP bereitet sie zunächst vor: Es zerlegt die empfangenen Daten, reserviert Speicher, bereitet die Session des Besuchers vor. Erst danach startet es den Code der Website, der prüft, wer angemeldet ist und was er tun darf.
PHP2Shell wird während dieser Vorbereitung ausgelöst. Laut Calif laufen beide Angriffswege ab, „bevor die angefragte PHP-Datei ausgeführt wird“. Wiz ergänzt, dass der Angriff auch dann funktioniert, wenn die Anwendung nie eine Session verwendet. Calif gibt an, dass mit PHP-FPM zusätzliche Bedingungen gelten (siehe den technischen Kasten weiter oben).
Vereinfacht läuft der Mechanismus in drei Schritten ab.
Zu diesem Zeitpunkt wurden weder die Anmeldeseite noch die Zugriffsregeln der Anwendung ausgeführt.
Der Code des Angreifers wird dann sehr wahrscheinlich mit den Rechten des PHP-Prozesses ausgeführt, also des Systembenutzers, der PHP auf dem Server ausführt (php.net). Das ist nicht automatisch der Administrator der Maschine. Aber dieser Benutzer kann alles lesen, was PHP braucht, damit die Website funktioniert. Und auf einem System, das selbst nicht aktuell ist, erlauben andere bekannte Lücken, von diesem Benutzer zum Administrator der Maschine aufzusteigen: So war es bei PwnKit und Baron Samedit, von denen weiter unten die Rede ist.
Hier ein plausibles Szenario, das verknüpft, was diese Lücken ermöglichen und was Angreifer bereits gegen PHP-Websites getan haben. Bislang wurde kein Angriff dieser Art mit PHP2Shell beschrieben.
Das Datenbankpasswort lesen. Eine Website muss sich mit ihrer Datenbank verbinden, und das Passwort steht meist in einer Konfigurationsdatei. Bei WordPress ist das die Datei wp-config.php, die laut der WordPress-Dokumentation „die Grundkonfiguration Ihrer Website, etwa die Zugangsdaten zur Datenbank“ enthält. Der Sicherheitsleitfaden von WordPress rät, das Lesen dieser Datei auf ihren Eigentümer „und den Webserver“ zu beschränken. Wird PHP jedoch vom selben Systembenutzer ausgeführt wie der Webserver, was von der Konfiguration abhängt, kann der Code des Angreifers diese Datei lesen. Passwörter in Konfigurationsdateien zu suchen ist eine katalogisierte Technik von MITRE ATT&CK, der maßgeblichen Wissensdatenbank über Angriffstechniken.
Sich an den Daten bedienen. Mit diesem Passwort verbindet sich der Angreifer mit der Datenbank, wie es die Anwendung tun würde: Kundenkonten, Bestellungen, Adressen. Darf das Datenbankkonto auch Tabellen löschen oder ändern, kann er weit mehr als nur lesen.
Sich einnisten, um zurückzukommen. Der Angreifer kann eine Web Shell ablegen: eine kleine Datei auf dem Webserver, mit der er den Server später aus seinem Browser heraus steuern kann (MITRE ATT&CK). Diese Datei bleibt nach dem PHP-Update bestehen. Das Schließen der Lücke entfernt die Datei nicht.
Zahlungen abgreifen. In einem Onlineshop kann der Angreifer in die Bezahlseite Code einfügen, der die von den Kunden eingegebenen Kartennummern kopiert. Genau das haben die Angreifer von CosmicSting getan, wie weiter unten beschrieben.
Den Speicher des Servers lesen, ohne Code auszuführen. Laut Wiz erlauben diese Lücken auch, einen Teil des Speichers der PHP-Prozesse zu lesen, in dem sich „Passwörter, Authentifizierungstoken, API-Schlüssel und Zertifikate“ befinden können.
Zwei jüngere Angriffe zeigen, was aus solchen Lücken wird, sobald sie öffentlich sind. Im Juni 2024 war eine PHP-Lücke unter Windows (CVE-2024-4577) in den 24 Stunden nach ihrer Veröffentlichung Ziel zahlreicher Ausnutzungsversuche, so das Forschungsteam von Akamai, einem Unternehmen für Sicherheits- und Content-Delivery-Dienste im Internet. Die Angreifer installierten darüber Fernsteuerungswerkzeuge, Software, die auf Kosten des Servers Kryptowährung schürft, und die Software eines Botnetzes. Laut Help Net Security, das sich auf das Unternehmen Imperva beruft, diente dieselbe Lücke dazu, Ransomware zu verbreiten, zwei Tage nach der Veröffentlichung des Patches.
Im selben Jahr traf CosmicSting (CVE-2024-34102) Magento und Adobe Commerce, zwei in PHP geschriebene Lösungen für Onlineshops. Laut Sansec, einem auf die Sicherheit von Onlineshops spezialisierten Unternehmen, haben sieben Angreifergruppen 4.275 Shops gehackt. Sie stahlen den geheimen Verschlüsselungsschlüssel des Shops, verschafften sich damit Zugang zu seiner Programmierschnittstelle und fügten dann in die Bezahlseite Code ein, der die Kartendaten kopierte. Als die Angreifer begannen, nach diesen Schlüsseln zu suchen, hatten 75 % der Installationen den Patch nicht eingespielt. Und laut Sansec, zitiert von The Hacker News, blieben selbst gepatchte Shops verwundbar, solange sie ihren Schlüssel nicht ersetzt hatten: Ein vor dem Patch gestohlener Schlüssel funktionierte auch danach. Den Patch einzuspielen beendet den Vorfall also nicht.
Zuerst die Content-Management-Systeme. Laut W3Techs wird WordPress im Oktober 2026 allein von 39,6 % aller Websites verwendet. Joomla (2,4 %), Drupal (0,6 %), PrestaShop (0,5 %), Bitrix, TYPO3 und OpenCart (jeweils 0,3 bis 0,4 %) sind ebenfalls in PHP geschrieben.
Dann die individuell entwickelten Anwendungen. Laravel und Symfony sind Frameworks, also Sammlungen von Komponenten, auf deren Grundlage man individuelle Anwendungen in PHP entwickelt. Symfony gibt an, dass Drupal, PrestaShop und Laravel auf seinen Komponenten beruhen. Bei Unternehmenssoftware ist Dolibarr, ein freies ERP- und CRM-System für kleine wie große Unternehmen, in PHP geschrieben.
Calif gibt an, die Ausnutzung auf WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, phpMyAdmin, Roundcube und WHMCS bestätigt zu haben, ebenso auf Laravel und Symfony. Und andere Produkte enthalten PHP, ohne es zu zeigen: Das CERT-EU warnt, dass Produkte, die PHP integrieren, betroffen sein können, auch wenn sie es nicht direkt exponieren. Palo Alto Networks hat das am 21. Oktober bestätigt: Alle Versionen von PAN-OS, dem Betriebssystem seiner Firewalls, und seiner Managementkonsole Panorama sind betroffen, und zwar über die Management-Oberfläche. Zu diesem Zeitpunkt gibt es noch keine korrigierte Version; der Hersteller rät, den Zugriff auf diese Oberfläche auf vertrauenswürdige interne Adressen zu beschränken. Das NCSC-NL, das nationale Cybersicherheitszentrum der Niederlande, führt eine Liste der Software, die von PHP abhängt: Sie ist der beste Ausgangspunkt, um herauszufinden, welche davon Sie einsetzen.
Wie viele Websites verwenden eine Version, die das PHP-Team nicht mehr pflegt? Im Oktober 2026 sind es nach unseren Berechnungen auf Basis der Zahlen von W3Techs fast die Hälfte der PHP-Websites mit bekannter Version: etwa 35 % verwenden PHP 7 oder älter, etwa 14 % PHP 8.0 oder 8.1 (Verteilung nach Version, Details zu PHP 8). Diese Zahl ist mit Vorsicht zu genießen: Manche Linux-Distributionen patchen alte Versionen selbst, ohne ihre Versionsnummer zu ändern, und eine alte Version ist daher nicht immer eine verwundbare Version. Laut einer Schätzung von Forschern, über die CyberScoop am 21. Oktober 2026 berichtete, könnten mehr als 1,3 Millionen aus dem Internet erreichbare Server verwundbar sein. Prüfen Sie also die PHP-Version Ihrer Website, oder fragen Sie Ihren Hoster danach. Gehört sie nicht mehr zu den Versionen, die das PHP-Team pflegt, erscheint für sie keine neue offizielle Version, die PHP2Shell behebt. Das PHP-Team hat zwar minimale Patches als Quellcode für PHP 7.4, 8.0 und 8.1 veröffentlicht (technischer Kasten oben), doch die meisten Websites erhalten sie nur über ihre Linux-Distribution oder ihren Hoster. Andernfalls müssen Sie auf eine gepflegte Version umsteigen.
Dass zwischen dem Schreiben eines Codes und der Entdeckung seiner Lücke vierzehneinhalb Jahre liegen, wirkt enorm. Es kommt jedoch häufig vor, auch bei einigen der schwersten Lücken der letzten Jahre.
| Lücke | Betroffene Software | Vorhanden seit | Öffentlich bekannt | Dauer |
|---|---|---|---|---|
| Shellshock | Bash, der Kommandozeileninterpreter von Unix- und Linux-Systemen | 1989 | September 2014 | etwa 25 Jahre (D. A. Wheeler) |
| PwnKit | pkexec, ein Werkzeug von polkit, mit dem sich unter Linux ein Befehl mit anderen Rechten ausführen lässt | Mai 2009 | Januar 2022 | etwa zwölfeinhalb Jahre (Qualys) |
| Baron Samedit | sudo, der Befehl, mit dem man unter Linux als Administrator handelt | Juli 2011 | Januar 2021 | etwa neuneinhalb Jahre (Qualys) |
| Heartbleed | OpenSSL, eine Verschlüsselungsbibliothek | März 2012 | April 2014 | etwa 2 Jahre (heartbleed.com) |
| PHP2Shell | PHP | März 2012 | Oktober 2026 | etwa vierzehneinhalb Jahre (php.net) |
Forscher hatten schon 2006 gemessen, wie lange Lücken verborgen bleiben. Andy Ozment und Stuart Schechter, zwei Forscher für IT-Sicherheit, verfolgten die Lücken von OpenBSD, einem freien Betriebssystem, das für seine Sicherheit bekannt ist, über siebeneinhalb Jahre und fünfzehn Versionen. 62 % der während der Studie gemeldeten Lücken waren zu deren Beginn bereits vorhanden, und die Hälfte der Lücken im ursprünglichen Code blieb mindestens 2,6 Jahre verborgen, bevor sie entdeckt wurde (USENIX Security 2006).
Bei PHP2Shell gab es vor der Entdeckung sogar Anzeichen. Laut Calif war schon 2004 ein erstes PHP-Problem im Zusammenhang mit dem Speicherlimit gefunden worden, 2020 ein verwandter Bug gemeldet worden, und ein Audit von 2024 hatte ein ähnliches Problem festgestellt, ohne nachweisen zu können, dass es ausnutzbar war.
Diese Lücken haben eines gemeinsam: Sie steckten in Code, der Jahre zuvor geschrieben worden war und auf dem sehr viele Systeme beruhen.
Mandiant, das Threat-Intelligence-Team von Google Cloud, misst jedes Jahr die Zeit zwischen der Veröffentlichung einer Lücke und ihrer ersten beobachteten Ausnutzung. Im Durchschnitt betrug diese Zeit 63 Tage in den Jahren 2018 und 2019, 44 Tage zwischen 2020 und Anfang 2021, 32 Tage in den Jahren 2021 und 2022 und dann nur noch 5 Tage im Jahr 2023 (Mandiant). In seinem Bericht M-Trends 2026 schätzt Mandiant, dass die erste Ausnutzung der Veröffentlichung der Lücke im Durchschnitt um sieben Tage vorausgeht. Die Ausnutzung findet häufig „noch vor der Veröffentlichung eines Patches“ statt (M-Trends 2026).
VulnCheck, ein Unternehmen, das Sicherheitslücken beobachtet, hat nur die Lücken betrachtet, deren Ausnutzung belegt ist. Im ersten Halbjahr 2026 wurden 23,43 % davon am Tag ihrer Veröffentlichung oder davor ausgenutzt. Content-Management-Systeme wie WordPress und seine Plugins (so heißen die Erweiterungen bei WordPress) sind die am stärksten angegriffene Kategorie: ein Drittel dieser Lücken (VulnCheck). Für die am häufigsten ausgenutzten WordPress-Lücken hat Patchstack, das Schutz gegen diese Angriffe verkauft, für 2025 eine mediane Zeit von fünf Stunden bis zur ersten Ausnutzung gemessen (Patchstack). Und laut dem Jahresbericht von Verizon über Datenschutzverletzungen, Ausgabe 2026, beginnen 31 % der Verletzungen mit einer Softwarelücke, noch vor gestohlenen Passwörtern (Verizon DBIR 2026).
PHP2Shell ist ein Beispiel dafür: ein erster Versuch, den Amazon schon am 17. Oktober erfasste, ein Leak am 20., Angriffe, die Cloudflare und watchTowr am Morgen des 21. meldeten, der Patch am Nachmittag des 21.
Diese Zahlen erklären, was folgt. Wenn der Angriff beginnen kann, bevor der Patch veröffentlicht ist, reicht es nicht, ihn einzuspielen. Drei Dinge bleiben vorzubereiten: dass die Lücke am Tag ihrer Ausnutzung dem Angreifer nicht alle Türen öffnet; dass man sofort alarmiert wird; dass der Patch, sobald er veröffentlicht ist, noch am selben Tag in Produktion geht.
Die Forscher von Calif berichten, dass sie den Quellcode von PHP mit Unterstützung eines Sprachmodells durchgesehen haben. KI-Agenten verfolgten die Codepfade nach, und ein Modell verallgemeinerte die erste Lücke zu einer Suchmethode, mit der sich eine zweite finden ließ. Nach eigener Aussage brauchten sie weder ein besonderes Werkzeug noch Zugang zu einem nicht öffentlichen Modell; ihr Wissen über die Geschichte der PHP-Lücken war dabei von Bedeutung. Wiz wiederum warnt, dass Sprachmodelle helfen können, einen Angriff an verschiedene PHP-Versionen, Konfigurationen und Speicherlayouts anzupassen, und dass „dies die Hürde für Angriffe in großem Maßstab deutlich senkt“.
Es ist nicht der erste Fall. 2024 fand Big Sleep, ein KI-Agent von Google, in SQLite, einer Datenbank, die in sehr vielen Anwendungen steckt, eine ausnutzbare Lücke, die behoben wurde, bevor sie in eine veröffentlichte Version gelangte (Google Project Zero). Im August 2025, beim Finale des Wettbewerbs AIxCC der DARPA, der Forschungsbehörde des US-Verteidigungsministeriums, fanden KI-Systeme 54 für den Wettbewerb eingebaute Lücken und behoben 43 davon, im Durchschnitt in 45 Minuten pro Patch. Sie fanden außerdem 18 echte Lücken, die nicht für den Wettbewerb eingebaut worden waren (DARPA).
Am 21. Oktober haben zwei Projekte Lücken geschlossen, die mit KI-Werkzeugen gefunden wurden: PHP, laut den Entdeckern seiner Lücken, und Node.js bei einer seiner Lücken (CVE-2026-111497), die sein Team OpenAI Codex Security und zwei Forschern zuschreibt. Die Lücke in GitLab wurde von einem Forscher gemeldet, und GitLab erwähnt kein KI-Werkzeug.
Am 21. Oktober beschrieb Microsoft eine Kampagne, die mit ARTEX geführt wurde, und zwar von Storm-0940, einem Akteur, der laut Microsoft dem chinesischen Staat nahesteht. Microsoft beschreibt ARTEX als quelloffenes Framework für Penetrationstests, das die Schritte eines Angriffs KI-Agenten überlässt. Laut Microsoft nutzte Storm-0940 es, um Angriffe auf Hunderte Organisationen zu automatisieren. Nachdem der Akteur ConnectWise kompromittiert hatte, einen Softwareanbieter für IT-Dienstleister, versuchte er, sich in mehr als 2.250 Microsoft-365-Umgebungen von dessen Kunden anzumelden. Die Agenten übernahmen die Aufklärung, Änderungen an Anmeldedaten von Anwendungen und Versuche, Berechtigungen zu ändern, um ihren Zugriff auszuweiten oder zu verlängern. Microsoft stellt klar, dass die meisten dieser Versuche gescheitert sind.
Am 19. Oktober berichtete Reuters, dass ein chinesischsprachiger Cyberkrimineller KI-Agenten genutzt hat, um in die Websites von mehr als 100 Unternehmen einzudringen, für rund 5.000 Dollar an KI-Nutzung. Die Agentur konnte nicht feststellen, in welchem Umfang Daten abgeflossen sind. Reuters stützt sich auf den Bericht eines Forschers, Snorre Fagerland vom Unternehmen NorForge; von den genannten Unternehmen geben zwei an, einen Vorfall auf einer Website bearbeitet zu haben.
Amazon beschreibt einen allgemeinen Trend: KI-gestützte Analyse macht es weniger aufwendig, aus einem Patch oder einem Sicherheitshinweis einen funktionierenden Angriff zu machen, und mehr Angreifer können in den Stunden, ja Minuten handeln, nachdem die Details einer Lücke veröffentlicht wurden. Amazon sagt nicht, dass die Angreifer von PHP2Shell KI genutzt haben, und gibt an, nicht zu wissen, wie der Angreifer schon vor der Veröffentlichung an Informationen über die Lücke gelangt ist.
Big Sleep und AIxCC zeigen, dass KI-Systeme Lücken in realem Code finden; laut Wiz kann ein Modell helfen, einen Angriff anzupassen; und laut Microsoft führen KI-Agenten bereits Angriffe auf Organisationen aus. Die KI dient also denen, die Lücken schließen, ebenso wie denen, die sie ausnutzen. Wir sehen darin eine Hypothese: Die Zeit zwischen der Entdeckung einer Lücke und den ersten Angriffen könnte sich weiter verkürzen.
Die Sicherheitsbehörden sind sich in einem Punkt einig: Die KI verkürzt die Zeit, die denen bleibt, die Patches einspielen. Im Februar 2026 schrieb das CERT-FR in seiner Lageübersicht zur Bedrohung durch generative KI, dass diese „es böswilligen Akteuren ermöglicht, schneller und damit in größerem Maßstab zu handeln“. Im Mai kündigte das NCSC, das nationale Cybersicherheitszentrum des Vereinigten Königreichs, eine Welle von Updates für Lücken aller Schweregrade an, weil die KI in fähigen Händen erlaubt, die in Software angesammelten Schwächen „in großem Maßstab und in hohem Tempo“ auszunutzen. Im Juni änderte die CISA die Fristen, die sie den US-Bundesbehörden für das Einspielen von Patches setzt: Sie hängen nun vom Risiko ab (Erreichbarkeit aus dem Internet, belegte Ausnutzung, Auswirkung). Die kürzeste Frist beträgt drei Tage. Sie begründet diese Änderung mit der Nutzung von KI durch Angreifer, die die Zeit, die den Verteidigern bleibt, „noch weiter verkürzen könnte“. Daraus leiten wir eine Regel ab: Ein kritischer Patch wird noch am Tag seiner Veröffentlichung eingespielt (siehe die Zeiten bis zur Ausnutzung weiter oben), und das gelingt mit einer Auslieferung, bei der jede Änderung bereits die Pipeline durchläuft.
Die KI dient auch dazu, Code zu schreiben, und mehrere dieser Behörden empfehlen, ihn zu kontrollieren. Im März 2026 warnte der Leiter des NCSC, dass unsichere Software, die „ohne menschliche Prüfung“ entsteht, Lücken verbreiten könnte. Die ANSSI und das BSI, ihr deutsches Gegenstück, sehen in ihrem Bericht über KI-Programmierassistenten das Risiko, dass man sich zu sehr auf diese Werkzeuge verlässt und den von ihnen erzeugten Code ungeprüft übernimmt, besonders bei unerfahrenen Entwicklern. Sie empfehlen, dass der erzeugte Code in der Regel von den Entwicklern geprüft wird, mit einem kritischen Blick auf Fehler des Werkzeugs und auf Sicherheitsrisiken. Das CERT-FR weist auf eine weitere Falle hin: Ein KI-Assistent kann den Namen einer Komponente erfinden, die nicht existiert, und Angreifer registrieren diese Namen, um darunter bösartige Versionen zu veröffentlichen. Für KI-Agenten gilt derselbe Grundsatz wie für den PHP-Prozess: nur die nötigsten Rechte (Details weiter unten).
Konkret raten wir einem Team, das mit KI entwickelt, jede Zeile, die das Werkzeug schreibt, gegenzulesen und sie wie den übrigen Code durch die Tests der Pipeline laufen zu lassen; vor dem Hinzufügen einer von der KI vorgeschlagenen Komponente zu prüfen, ob sie existiert und wer sie veröffentlicht; und einem Agenten nur die Rechte zu geben, die seine Aufgabe braucht. Für eine mit KI erstellte Anwendung beschreibt unser Artikel „Kann man mit KI eine App erstellen?“, was das Werkzeug allein schafft.
Ein KMU oder ein Start-up braucht keine Sicherheitsforscher im Team. Eine Lücke wie PHP2Shell zu finden erfordert Spezialisten, und ihre Suche fand vor der Veröffentlichung statt: Acht bis zehn Wochen liegen zwischen der ersten Meldung und dem Patch, nach den Zeitplänen von Wiz und Calif. Für den Rest versammelt der Leitfaden zur IT-Hygiene der ANSSI in der Ausgabe von 2017 insgesamt 42 Maßnahmen. Die Behörde schreibt darin, dass der Großteil der Angriffe, bei denen sie eingegriffen hat, hätte verhindert werden können, wenn diese Maßnahmen angewandt worden wären. Wem das Fachwissen fehlt, dem rät sie, für eine Bestandsaufnahme einen Spezialisten hinzuzuziehen und im Unternehmen einen Sicherheitsbeauftragten zu benennen.
Dave Farley ist der Erfinder der Deployment-Pipeline, die oft CI/CD-Pipeline genannt wird. Continuous Delivery bedeutet, die Software jederzeit bereit für die Produktion zu halten, durch kleine, automatisch geprüfte Änderungen. Die Deployment-Pipeline ist die automatische Kette, die jede Codeänderung aufnimmt, testet, speichert und bereit macht, in Produktion zu gehen. Dave Farley hat zusammen mit Jez Humble das Buch Continuous Delivery geschrieben und ist Autor von Modern Software Engineering (Modernes Software-Engineering). In Continuous Delivery Pipelines schreibt er, dass Sicherheit den Rat von Spezialisten erfordern kann, aber „in der Verantwortung jedes Einzelnen im Team“ liegt. Die Spezialisten beraten; sie sollen keine „Gatekeeper“ sein, die jedes Deployment in die Produktion freigeben.
Was das Team, das die Anwendung entwickelt und wartet, tun kann, lässt sich in vier Zielen zusammenfassen, und keines davon verlangt, nach Lücken zu suchen:
Die Abschnitte „Begrenzen, was ein Angreifer über eine Lücke erreicht“ und „Sofort alarmiert werden“ behandeln die ersten beiden Ziele. Die Abschnitte über die Abhängigkeiten, über die Updates und über die Art der Auslieferung behandeln das dritte, der Abschnitt „WordPress-Website gehackt oder Sicherheitslücke entdeckt“ das vierte.
Laut M-Trends 2026 beträgt die mediane Zeit zwischen dem Eindringen eines Angreifers in ein System und seiner Entdeckung 14 Tage. In dieser Zeit handelt der Angreifer: Die ersten beiden Ziele verringern, was er erreichen kann und wie lange er unbemerkt bleibt.
Ein digitaler Dienst ist mehr als eine Website. Eine typische Webanwendung besteht aus mehreren Teilen: einem Eingangspunkt, der die Anfragen aus dem Internet empfängt und weiterleitet, dem Server, der den Code ausführt, einer Datenbank, Backups und den Konten der Personen, die das Ganze verwalten. Jeder dieser Teile lässt sich so einstellen, dass eine Lücke in einem davon nicht Zugang zu allen anderen verschafft. Das nennt man gestaffelte Verteidigung (Defense in Depth).
Jedem Programm nur die nötigsten Rechte geben. Der PHP-Prozess muss weder Administrator der Maschine sein noch den Code der Website ändern können. Das Konto, mit dem er sich mit der Datenbank verbindet, muss laut dem Sicherheitsleitfaden von WordPress nur Daten lesen und schreiben; die Rechte, zu löschen, die Struktur zu ändern oder Rechte zu vergeben, können ihm entzogen werden. Jez Humble und Dave Farley sagen es in Continuous Delivery: Die Standardeinstellungen von Betriebssystemen und Datenbanken eignen sich nicht für eine Anwendung in Produktion; es braucht Firewalls, deaktivierte unnötige Dienste und Datenbankbenutzer mit passend eingestellten Rechten.
Der Code darf sich über die Website nicht ändern lassen. Kann der PHP-Prozess nicht in die Verzeichnisse des Codes schreiben, kann ein Angreifer, der ihn übernimmt, dort nicht so leicht eine Web Shell ablegen. WordPress sieht das vor: Nur das Verzeichnis für hochgeladene Inhalte (wp-content) muss für den Webserver beschreibbar sein, und der in die Verwaltung integrierte Code-Editor, laut WordPress oft „das erste Werkzeug, das ein Angreifer verwendet, wenn es ihm gelingt, sich anzumelden“, lässt sich deaktivieren.
Abschotten. Die Datenbank hat keinen Grund, aus dem Internet erreichbar zu sein: Nur der Anwendungsserver muss sich mit ihr verbinden können. Die ANSSI empfiehlt, das Netzwerk zu segmentieren, die aus dem Internet sichtbaren Dienste vom Rest des Systems abzuschotten und die Server über ein eigenes Netzwerk zu administrieren (Maßnahmen 19, 23 und 28 ihres Leitfadens).
Vorgelagert filtern und die Grenzen des Filters kennen. Eine Web Application Firewall (WAF) prüft die Anfragen, bevor sie den Server erreichen, und blockiert diejenigen, die einem bekannten Angriff ähneln. Der Sicherheitsleitfaden von WordPress empfiehlt, eine zu installieren. Sie hat ihre Grenzen: Cloudflare fordert selbst dazu auf, den Patch einzuspielen, auch mit seinen Regeln gegen PHP2Shell, und das CERT-FR stellt klar, dass es die vorgeschlagene Blockierung nicht selbst geprüft hat. Eine Web Application Firewall verschafft Zeit; sie ersetzt den Patch nicht.
Secrets aus dem Code holen. Passwörter und Zugangsschlüssel zu anderen Diensten (Zahlung, E-Mail-Versand, Speicher) sollten nicht in den Dateien des Codes stehen. MITRE ATT&CK empfiehlt eine Regel, die verbietet, Passwörter in Dateien zu speichern. In den Umgebungsvariablen des Servers oder in einem Secrets-Tresor bleiben sie für PHP lesbar, während es ausgeführt wird: Das schützt sie nicht, wenn der PHP-Prozess übernommen wird. Was man dadurch gewinnt, ist aus unserer Sicht, dass sie weder in der Historie des Codes noch in dessen Backups liegen und dass man sie ändern kann, ohne den Code anzufassen. Das zählt an dem Tag, an dem man sie alle ersetzen muss.
Die Konten der Menschen schützen. Ein Angreifer braucht nicht immer eine Lücke: Ein wiederverwendetes Passwort genügt ihm. Die ANSSI empfiehlt, Passwörter zu schützen, voreingestellte Passwörter zu ändern und eine starke Authentifizierung zu bevorzugen (Maßnahmen 11 bis 13). Konkret empfehlen wir einen Passwortmanager, damit jeder für jeden Dienst ein anderes Passwort hat, und eine Zwei-Faktor-Authentifizierung für die Konten, die Zugang zur Produktion, zum Hosting und zum Code geben.
Manuelle Änderungen in der Produktion verbieten. In Continuous Delivery Pipelines setzt Dave Farley ein Ziel: „jeden menschlichen Schreibzugriff auf Produktionssysteme entfernen“. Jede Änderung läuft über die Deployment-Pipeline. In Continuous Delivery fügen die beiden Autoren hinzu, dass die Produktion für Außenstehende wie für Mitarbeitende des Unternehmens gesperrt sein muss, Betriebsteams eingeschlossen. Ohne das weiß niemand mehr, wer was wann getan hat, wenn etwas schiefgeht.
Offline-Backups aufbewahren und testen. Ein Backup, das vom kompromittierten Server aus erreichbar ist, kann zusammen mit dem Rest verschlüsselt oder gelöscht werden. Die ANSSI empfiehlt eine Backup-Richtlinie, die Offline-Kopien und Wiederherstellungstests vorsieht, mit mindestens einer Wiederherstellungsübung pro Jahr (Maßnahme 37). Ein Backup, das nie wiederhergestellt wurde, hat nicht bewiesen, dass es funktioniert.
user festlegt (php.net). Mit php_admin_value und php_admin_flag gesetzte Einstellungen lassen sich nicht durch ini_set() ändern. PHP-FPM nicht auf einer von außen erreichbaren Adresse anbieten.expose_php = Off, display_errors = Off, allow_url_fopen = Off, allow_url_include = Off, open_basedir, disable_functions (system, exec, shell_exec, passthru, proc_open…) sowie Session-Cookies mit secure, httponly und use_strict_mode. Die PHP-Dokumentation warnt jedoch selbst, dass disable_functions „umgangen werden kann“ und dass open_basedir nur „ein zusätzliches Sicherheitsnetz, bei Weitem nicht vollständig“ ist, das den Zugriff auf Unix-Sockets nicht einschränkt. Diese Einstellungen erschweren den weiteren Verlauf eines Angriffs; sie verhindern ihn nicht, und PHP2Shell wird ausgelöst, bevor die Anwendung ausgeführt wird.DROP, ALTER und GRANT können entzogen werden, wobei manche Updates das Schema ändern); wp-config.php mit den Berechtigungen 400 oder 440; DISALLOW_FILE_EDIT; Web Application Firewall, wobei ModSecurity als die verbreitetste freie Option genannt wird.Steht die Verteidigung, muss man noch gewarnt werden, wenn sie überwunden wird. Das Ziel ist dreifach: wissen, dass etwas Ungewöhnliches passiert, den Zugang kappen und dann herausfinden, woher der Angriff kommt. In Continuous Delivery verlangen Jez Humble und Dave Farley, dass die Betriebsteams bei einem Vorfall „sofort informiert“ werden und über die Werkzeuge verfügen, seine Ursache zu finden. Sie nennen auch einen häufigen Fehler: Fehler zu ignorieren, statt sie zu protokollieren, wodurch man sie nicht erkennen kann.
Eine Monitoring-Lösung überwacht bestimmte Signale, und ihre Logs liegen getrennt vom überwachten Server. Die Betriebsteams verfolgen den Zustand der Server ständig auf Dashboards wie Grafana oder Kibana, die Messwerte und Logs zusammenführen und einen Alarm auslösen, wenn ein Schwellenwert überschritten wird. Diese Signale sollten einen Alarm auslösen:
Der Webserver startet ein Programm. Ein Webserver liefert Seiten aus; er hat keinen Grund, einen Kommandozeileninterpreter oder ein Download-Werkzeug zu starten. Tut er es doch, wird oft eine Web Shell benutzt (MITRE ATT&CK).
Der Server verbindet sich mit unbekannten Adressen. Software, die Kryptowährung schürft, ein Fernsteuerungswerkzeug oder ein Datenabfluss brauchen alle ausgehende Verbindungen. Wir empfehlen, ausgehende Verbindungen des Servers standardmäßig zu blockieren, außer zu den Diensten, die die Anwendung braucht: Das schränkt auch den Einsatz dieser Werkzeuge ein.
Eine Codedatei ändert sich. In der Produktion ändert sich der Code nur bei einem Deployment. Eine neue .php-Datei in den Verzeichnissen der Website außerhalb eines Deployments ist ein Zeichen für ein Eindringen. WordPress empfiehlt, die Integrität der Dateien zu überwachen, und erinnert daran, dass ein Angriff „immer Spuren hinterlässt, in den Logs oder in den Dateien“.
Ein neues Administratorkonto taucht auf. Die ANSSI empfiehlt, das Verzeichnis der privilegierten Konten aktuell zu halten (Maßnahme 5). Ein Administratorkonto, das außerhalb jedes Verfahrens angelegt wurde, ist ein Signal, dem man nachgehen muss.
Die Fehler häufen sich. Die ANSSI sieht vor, die Fehler der Webdienste zu protokollieren, und nennt dabei die Fehler 403, 404 und 500 sowie unerwartete Abstürze (Maßnahme 36).
Die Logs außerhalb des Servers aufbewahren. Ein Angreifer, der den Server kontrolliert, kann seine Spuren in den dort liegenden Logs löschen. Die ANSSI empfiehlt daher, die Logs auf einem anderen System zu zentralisieren und die Sicherheitsereignisse mindestens ein Jahr lang aufzubewahren.
Einige freie Werkzeuge, als Beispiel genannt:
/etc ab (Falco-Dokumentation).Eine Anwendung wird nicht vollständig von denen geschrieben, die sie entwickeln. Sie stützt sich auf Komponenten, die andere veröffentlichen: die Abhängigkeiten. Werkzeuge installieren und aktualisieren sie, Composer für PHP, npm oder pnpm für JavaScript. Und sie wird in einer Umgebung ausgeführt, PHP selbst, die das System des Servers, der Hoster oder das Image bereitstellt, mit dem sie deployt wird.
In Continuous Delivery sind Jez Humble und Dave Farley unmissverständlich: Ein Projekt muss immer „die genaue Version der externen Bibliotheken“ angeben, die es verwendet. Ohne das, schreiben sie, lässt sich nicht exakt nachbauen, was in Produktion ist. Aus unserer Sicht weiß man dann auch nicht, ob man einer Lücke ausgesetzt ist.
Akzeptiert ein Projekt „jede Version ab dieser“, gelangt eine neu veröffentlichte Version beim nächsten Update in die Anwendung, ohne dass jemand sie ausgewählt hätte. Das ist derzeit die Standardeinstellung von npm (npm), und Composer empfiehlt es für Bibliotheken, die von anderen Projekten wiederverwendet werden sollen (Composer). Die Details der Schreibweise stehen im Kasten „Für Ihr technisches Team“ weiter unten.
Nicht alle neuen Versionen werden gleich behandelt. Der Patch für eine schwere Lücke wird installiert, sobald er veröffentlicht ist: Abwarten heißt, die Tür offen zu lassen. Die anderen neuen Versionen können ein paar Tage warten, denn bösartiger Code gelangt über gerade erst veröffentlichte Versionen hinein. 2018 übernahm ein Angreifer die Pflege des Pakets event-stream und fügte Code hinzu, der es auf die Bitcoin-Wallets der Anwendung Copay abgesehen hatte (npm). Im September 2025 wurde das Konto des Maintainers von chalk, debug und rund zwanzig weiteren JavaScript-Paketen mit einer gefälschten E-Mail zum Zurücksetzen des Passworts gekapert; laut StepSecurity, einem Unternehmen für IT-Sicherheit, wurden diese Pakete damals milliardenfach pro Woche heruntergeladen (StepSecurity). Wenige Tage später hatte der Wurm Shai-Hulud, der sich selbstständig von Paket zu Paket verbreitete, mehr als 500 davon kompromittiert; die CISA empfahl daraufhin, die Abhängigkeiten auf sichere Versionen festzulegen, die vor dem 16. September 2025 veröffentlicht wurden (CISA).
Daraus ergeben sich vier Praktiken.
Die exakte Version eintragen, in der Datei, die die Abhängigkeiten deklariert. Die Anwendung erhält dann eine neue Version, wenn jemand es entscheidet, nicht wenn sie veröffentlicht wird. Mit einem Lockfile, das zusammen mit dem Code versioniert wird (nächste Praxis), wirkt ein Versionsbereich nur im Moment eines Updates. Er ist also an sich keine Lücke: Die exakte Version ist eine Teamregel, die jedes Update zu einer bewussten Entscheidung macht.
Das Lockfile aufbewahren, zusammen mit dem Code. Diese Datei hält die exakte Version jeder installierten Komponente fest, einschließlich der Komponenten, von denen Ihre Komponenten abhängen, und die Dokumentation von Composer empfiehlt, sie zusammen mit dem Code des Projekts zu versionieren (Composer).
Aus dieser Datei installieren und nur nach Entscheidung aktualisieren. Die Pipeline installiert genau die Versionen aus dem Lockfile. Ein Update wird Komponente für Komponente entschieden und getestet.
Abwarten, bevor man eine gerade erst veröffentlichte Version übernimmt. Der Paketmanager pnpm bietet diese Wartezeit an, seit seiner Version 11 derzeit standardmäßig auf einen Tag eingestellt, „um das Risiko zu verringern, kompromittierte oder fehlerhafte Pakete zu installieren“. Seine Dokumentation gibt an, dass bösartige Versionen in der Regel in weniger als einer Stunde entdeckt und entfernt werden (pnpm). Der Patch für eine schwere Lücke unterliegt dieser Wartezeit nicht: Er wird installiert, sobald er veröffentlicht ist, nachdem geprüft wurde, dass er tatsächlich vom Hersteller oder vom CERT-FR angekündigt wurde.
Das umgekehrte Risiko gibt es auch: seine Versionen festlegen und sie nie wieder aktualisieren. Nach unseren Berechnungen auf Basis der Zahlen von W3Techs verwendete im Oktober 2026 fast die Hälfte der PHP-Websites eine Version, die das PHP-Team nicht mehr pflegt. Eine exakte Version schützt nur, wenn die Updates folgen, oft, eines nach dem anderen und geprüft. Jez Humble und Dave Farley machen daraus ein allgemeines Prinzip: „Wenn es wehtut, tun Sie es öfter, und gehen Sie die Schwierigkeit früher an.“ Ein Update, das jede Woche gemacht wird, ändert wenig auf einmal; ein Update, das zwei Jahre lang aufgeschoben wird, wird zur Großbaustelle.
Jeden Tag werden neue Lücken in Code veröffentlicht, der sich selbst nicht verändert hat. Eine Prüfung, die nur bei einer Änderung gestartet wird, übersieht die Lücken, die in der Zwischenzeit veröffentlicht wurden. Composer, das Werkzeug, das die Komponenten einer PHP-Anwendung verwaltet, kann die installierten Komponenten mit den Sicherheitshinweisen abgleichen, die auf Packagist, dem wichtigsten Repository für PHP-Komponenten, veröffentlicht werden, und meldet auch aufgegebene Komponenten (Composer). Täglich von einem geplanten Job der Pipeline gestartet, meldet diese Prüfung eine Lücke, sobald ihr Sicherheitshinweis veröffentlicht ist. In Continuous Delivery Pipelines fordert Dave Farley, dass Sicherheit in der Pipeline getestet wird, ab der ersten Stage, und nicht als separate Kontrolle behandelt wird.
Einmal pro Woche listet eine weitere Prüfung die Komponenten auf, für die es eine neue Version gibt. Diese Erinnerung verhindert den Rückstand von zwei Jahren.
Nicht jede Warnung verlangt dieselbe Reaktion. Zwei Angaben entscheiden über die Dringlichkeit. Zuerst der Schweregrad: Die meisten Sicherheitshinweise geben einen CVSS-Wert von 0 bis 10 an, den FIRST, die internationale Organisation, die diese Skala herausgibt, in fünf Stufen einteilt: keine (0), niedrig (0,1 bis 3,9), mittel (4 bis 6,9), hoch (7 bis 8,9) und kritisch (9 bis 10) (CVSS 4.0). Die Lücken von PHP2Shell sind mit 9,2 bewertet: kritisch. Dieser Wert vergleicht den Schweregrad einer Lücke mit dem der anderen; er misst nicht das Risiko für Ihr Unternehmen.
Dann die Ausnutzung: Eine bereits ausgenutzte Lücke geht einer schwereren vor, die noch nicht ausgenutzt wird. Die CISA führt die Liste der ausgenutzten Lücken: Sie setzt den US-Bundesbehörden Fristen, um sie zu beheben, und empfiehlt jeder Organisation, sie vorrangig zu beheben. FIRST veröffentlicht täglich das EPSS, eine Schätzung der Wahrscheinlichkeit, dass eine Lücke innerhalb von dreißig Tagen ausgenutzt wird. In Frankreich unterscheidet das CERT-FR seine Warnmeldungen, die „vor einer unmittelbaren Gefahr warnen sollen“, von seinen Hinweisen, die über Lücken und Möglichkeiten zum Schutz davor informieren. Zu PHP2Shell gab es eine Warnmeldung.
In der Praxis wird eine kritische Lücke, die bereits ausgenutzt wird oder zu der das CERT-FR eine Warnmeldung herausgegeben hat, noch am Tag der Veröffentlichung des Patches behoben. Die anderen folgen dem normalen Rhythmus der Updates, eines nach dem anderen.
Diese Werkzeuge haben eine Grenze, und PHP2Shell zeigt sie. Sie prüfen die Bibliotheken, die die Anwendung deklariert, nicht die Sprache, die sie ausführt. Eine Prüfung der Komponenten ohne Warnung sagt nichts über PHP2Shell aus. Die PHP-Version wird gesondert überwacht: Das PHP-Team veröffentlicht die Liste der unterstützten Versionen und einen Feed seiner Releases; das CERT-FR veröffentlicht seine Warnmeldungen, und die ANSSI empfiehlt, sich über diesen Kanal über neue Lücken zu informieren (Maßnahme 34). Die ANSSI empfiehlt auch, das Ende der Wartung von Software vorauszuplanen (Maßnahme 35): PHP 8.2 erhält nach dem 31. Dezember 2026 keine mehr.
Eine composer.json mit exakten Versionen (Komponentennamen als Beispiel):
{
"require": {
"vendor/component-a": "2.3.1",
"vendor/component-b": "5.0.4"
}
}
Statt "^2.3.1", das jede Version von 2.3.1 bis ausschließlich 3.0.0 akzeptieren würde (Composer). Derzeit trägt npm standardmäßig ^ ein: ^1.2.3 akzeptiert jede Version ab 1.2.3 und vor 2.0.0 (node-semver). Bei npm sorgt save-exact=true in .npmrc dafür, dass standardmäßig die exakte Version eingetragen wird (npm).
Ein Beispiel für eine GitLab-Pipeline, zur Veranschaulichung und an Ihr Projekt anzupassen: eine Prüfung bei jedem Push, ein täglicher und ein wöchentlicher Job, jeder durch einen eigenen GitLab-Zeitplan ausgelöst (Zeitpläne, Regeln).
# Beispiel zur Veranschaulichung, an Ihr Projekt anzupassen
stages: [commit, audit]
.php:
# Image Ihres Projekts mit PHP und Composer, per Digest festgelegt
image: registry.example/php-composer@sha256:<digest>
commit:
extends: .php
stage: commit
script:
# Prüft, ob composer.json und composer.lock zueinander passen
- composer validate --strict
# Schlägt fehl, wenn eine Komponente, ob für Produktion oder Entwicklung, einen Sicherheitshinweis hat
- composer audit --locked
# Installiert genau die Versionen aus dem Lockfile
- composer install --no-interaction --prefer-dist
rules:
- if: $CI_PIPELINE_SOURCE == "push"
daily-audit:
extends: .php
stage: audit
script:
# Dieselbe Prüfung jeden Tag, ohne Codeänderung; schlägt auch bei aufgegebenen Komponenten fehl
- composer audit --locked --abandoned=fail
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "daily"
weekly-reminder:
extends: .php
stage: audit
script:
# Listet verfügbare neue Versionen auf, ohne die Pipeline fehlschlagen zu lassen: Das ist die Erinnerung
- composer outdated --direct
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "weekly"
composer.lock, bei npm package-lock.json) wird zusammen mit dem Code versioniert. Die Pipeline führt composer install aus, das genau die Versionen aus dieser Datei installiert; composer update berechnet die Versionen neu und schreibt die Datei um: Es dient nur einem beschlossenen Update, zum Beispiel composer update vendor/component-a (Composer).minimumReleaseAge bei pnpm, min-release-age bei npm (Namen der Einstellungen im Oktober 2026). Bei Composer raten wir, diese Wartezeit über eine Teamregel einzuhalten oder über das Werkzeug, das die Updates vorschlägt.composer audit gibt einen Exit-Code ungleich null zurück, wenn eine Komponente von einem Hinweis betroffen ist: Der Job wird rot, und das ist der Alarm. --locked liest das Lockfile, auch ohne vendor-Verzeichnis (Composer): Das Beispiel führt die Prüfung deshalb vor composer install aus, und der Job bricht ab, bevor eine Komponente mit Sicherheitshinweis installiert wird. Das Beispiel prüft auch die Entwicklungskomponenten: Sie werden in der Pipeline ausgeführt, die Zugriff auf den Code und die Secrets für das Deployment hat.php enthalten, daher das Image des Projekts im Beispiel.@sha256:…): Laut der Docker-Dokumentation erhält man dann immer dasselbe Image, und sie warnt, dass das Image keine Updates mehr erhält, „die Sicherheitspatches enthalten können“ (Docker). Das Festlegen ist daher nur sinnvoll, wenn der Digest regelmäßig aktualisiert und von der Pipeline getestet wird.integrity), und die Installation schlägt fehl, wenn das heruntergeladene Paket nicht passt. Bei einem Skript oder einem Stylesheet, das von einer anderen Domain geladen wird, sorgt das Attribut integrity (Subresource Integrity) dafür, dass der Browser eine veränderte Datei ablehnt (MDN); die ANSSI empfiehlt diese Prüfung für interne wie externe JavaScript- und CSS-Ressourcen, insbesondere für die eines CDN (Empfehlungen R11 und R12). Die OWASP empfiehlt, die Prüfung der Hashes und Signaturen heruntergeladener Pakete zu aktivieren. Renovate oder Dependabot können diese Updates als Merge Requests vorschlagen; sie deployen selbst nichts (Renovate, Dependabot).https://www.php.net/feed.atom) und die Warnmeldungen des CERT-FR. OSV-Scanner von Google liest derzeit composer.lock und in einem Container-Image die Pakete von Alpine sowie von Debian oder Ubuntu: Es kann ein PHP erkennen, das vom System des Images installiert wurde.Das NCSC fordert alle Organisationen auf, „Software-Updates so schnell wie möglich einzuspielen, idealerweise automatisch“, weil Angreifer oft eine geschlossene Lücke untersuchen, um einen Angriff zu schreiben, der sie ausnutzt; laut Amazon, weiter oben zitiert, macht die KI diese Arbeit weniger aufwendig. Das NCSC erinnert daran, dass der Hersteller seine Updates selbst testet, verlangt aber zugleich, sie auch auf den eigenen Systemen zu testen und schrittweise auszurollen. Für Software, die man installiert und unverändert nutzt (Windows, macOS, ein Smartphone, ein Browser, eine Office-Anwendung), raten wir daher, die automatischen Updates dieser Software zu aktivieren. Bei einem Onlinedienst spielt sein Anbieter die Patches ein. Eine WordPress-Website fällt in keine dieser beiden Kategorien: Ihr Betreiber entwickelt die Software nicht und nutzt sie auch nicht unverändert; er setzt sie zusammen und konfiguriert sie. Für eine Website oder Anwendung, die man zusammensetzt, vertreten wir eine andere Position.
WordPress wird im Oktober 2026 von fast vier von zehn Websites verwendet, und der Großteil seiner Lücken steckt nicht in WordPress selbst. Laut Patchstack wurden 2025 im WordPress-Ökosystem 11.334 neue Lücken gefunden: 91 % in Plugins, 9 % in Themes und nur 6 im Kern von WordPress. Und 46 % dieser Lücken hatten zum Zeitpunkt ihrer Veröffentlichung keinen Patch von ihrem Entwickler erhalten (Patchstack). Diese Zahlen stammen von einem Unternehmen, das Schutz gegen solche Lücken verkauft.
Unsere Position ist folgende: Wir raten von automatischen Updates von PHP, Plugins und Themes ab. Wir bevorzugen festgelegte Versionen und ein Update nach dem anderen, getestet, bevor es die Produktion erreicht: durch die Deployment-Pipeline bei einer individuell entwickelten Anwendung, auf einer Kopie der Website bei einer WordPress-Website, wenn möglich durch automatisierte Tests überprüft. Wir stehen mit dieser Position nicht allein. In Continuous Delivery fordern Jez Humble und Dave Farley, die exakte Version jeder externen Bibliothek anzugeben und jede Änderung auf einer produktionsähnlichen Umgebung zu prüfen. Die OWASP empfiehlt in ihrer Rangliste 2025 der kritischsten Risiken für Webanwendungen, „die Version jeder Abhängigkeit bewusst zu wählen und nur bei Bedarf zu aktualisieren“, und „Updates nicht auf allen Systemen gleichzeitig auszurollen“. Ihre Rangliste der Risiken speziell für CI/CD-Pipelines empfiehlt, die Werkzeuge nicht so zu konfigurieren, dass sie immer die neueste Version eines Pakets beziehen. Der Grund liegt in der Natur des Ökosystems. Eine WordPress-Website setzt sich aus dem WordPress-Kern, einer PHP-Version sowie Plugins und Themes zusammen, die Autoren unabhängig voneinander geschrieben haben. Nichts garantiert, dass die neue Version eines Plugins mit der Version eines anderen zusammenarbeitet, oder mit der PHP-Version des Servers. Ein automatisches Update installiert die neue Version trotzdem in der Produktion, ohne dass ein Test geprüft hätte, ob die Website noch funktioniert.
WordPress vertritt standardmäßig die umgekehrte Position. Derzeit (Oktober 2026) werden seit WordPress 3.7 kleinere Updates des Kerns standardmäßig automatisch installiert (WordPress). Bei Plugins und Themes sind automatische Updates seit WordPress 5.5 einzeln zu aktivieren, und WordPress führt sie dann zweimal täglich aus. Dieselbe WordPress-Seite beginnt mit diesem Satz: „Um Ihre WordPress-Website sicher zu halten, sollten Sie Ihre Plugins und Themes immer auf die neueste Version aktualisieren“ (WordPress). Das ist ein echter Vorteil automatischer Updates: Bei einer für 2025 gemessenen medianen Zeit von fünf Stunden zwischen der Veröffentlichung einer stark ausgenutzten Lücke und ihrer ersten Ausnutzung ist ein automatisches Update, das zweimal täglich eingespielt wird, schneller als ein manuelles Update einmal im Monat.
Unsere Position setzt also jemanden voraus, der die Wartung übernimmt. Automatisiert werden die Alarme: ein Alarm, wenn eine Lücke die eingesetzten Versionen betrifft, ein Alarm, wenn auf dem Server etwas Ungewöhnliches passiert, ein Zeichen, dass eine Lücke vielleicht gerade ausgenutzt wird. Ein Mensch entscheidet, wann aktualisiert wird, und tut es dann sofort, ohne zu warten. Das Update selbst wird automatisiert: Der Administrator startet es mit einem Klick, und es wird getestet, bevor es die Produktion erreicht, durch die Pipeline bei einer individuellen Anwendung, auf einer Kopie der Website bei WordPress, in den Stunden danach. Ohne diese Organisation lassen festgelegte Versionen die Website länger ungeschützt als ein automatisches Update.
Zwei weitere Hebel zählen ebenso viel. Da 2025 fast die Hälfte der Plugin-Lücken am Tag ihrer Veröffentlichung keinen Patch hatte, deckt an diesem Tag keine Update-Strategie sie ab, ob automatisch oder manuell. Weniger installierte Plugins bedeuten weniger mögliche Lücken: Die OWASP, die maßgebliche Stiftung für die Sicherheit von Webanwendungen, empfiehlt, unnötige Abhängigkeiten zu entfernen, und die ANSSI, die Abhängigkeiten zwischen Softwareprodukten zu begrenzen. Und ein Plugin, das sein Autor aufgegeben hat, erhält keinen Patch mehr: Es wird ersetzt.
Schließlich aktualisieren die WordPress-Updates nur WordPress. Keines davon betrifft PHP. PHP wird vom Hoster oder vom System des Servers bereitgestellt: Deshalb verweist das PHP-Team auf die Linux-Distribution oder den Anbieter, der PHP langfristig pflegt. PHP wird für eine WordPress-Website also beim Hoster aktualisiert, oder in der Umgebung, mit der die Website deployt wird.
Bei einer WordPress-Website zwingt nichts dazu, diese Wartung selbst zu übernehmen. Cybermalveillance.gouv.fr stellt seine bewährten Verfahren für die Sicherheit einer Website als Maßnahmen dar, „die man selbst ergreift oder von seinem Dienstleister umsetzen lässt“. Auf WordPress spezialisierte Hoster übernehmen die Aktualisierung der Serversoftware, darunter PHP, und automatische Backups. Der Sicherheitsleitfaden von WordPress beschreibt den vertrauenswürdigen Hoster: Er „stellt die neuesten stabilen Versionen aller Serversoftware bereit“, bietet „zuverlässige Methoden für Backup und Wiederherstellung“ und spricht bereitwillig über die Sicherheitsmaßnahmen, die er anbietet. Fragen Sie ihn vor der Wahl, ob er PHP selbst aktualisiert, ob er die Updates auf einer Kopie der Website testet, bevor er sie einspielt, und wie man ein Backup wiederherstellt.
Auch eine individuell entwickelte Anwendung wird nach Entscheidung aktualisiert. Der Anforderungskatalog Cyber Essentials des NCSC nimmt die individuell entwickelten Komponenten von Webanwendungen von seinem Geltungsbereich aus und empfiehlt für sie „gründliche Entwicklung und Tests“. Jedes Update, von PHP wie von einer Komponente, durchläuft die Deployment-Pipeline und ihre automatisierten Tests und geht dann noch am Tag seiner Veröffentlichung in Produktion.
Anders sieht es aus, sobald man den Code anfassen muss. Die erste Regel von WordPress gilt für alle: „Fassen Sie den WordPress-Kern nicht an“, weil jedes Update dessen Dateien überschreibt; was man hinzufügen oder ändern will, kommt in ein Plugin. Bei einem Theme erlaubt ein Child-Theme, es zu ändern, ohne seinen Code anzufassen, und weiterhin seine Updates zu erhalten. Dieser individuell geschriebene Code, Child-Theme oder Plugin, ist Software, die man entwickelt. In Continuous Delivery verlangen Jez Humble und Dave Farley, alles, was zum Bauen und Deployen der Software dient, unter Versionsverwaltung zu halten und jede Änderung durch die Deployment-Pipeline laufen zu lassen. Konkret liegt dieser Code in einem Git-Repository und geht über die Pipeline in Produktion, nie von Hand auf den Server kopiert.
Niemand muss den WordPress-Kern ändern. Was einer klassischen Installation fehlt, liegt woanders. Plugins werden über die Verwaltung installiert, ohne dass ihre Versionen irgendwo deklariert sind, und die Konfiguration steckt in einer einzigen Datei, für alle Umgebungen dieselbe. Man kann also die Website, die in Produktion ist, nicht exakt auf einer Testumgebung nachbauen, was Jez Humble und Dave Farley jedoch fordern. Diesen Mangel behebt Bedrock von Roots. Es ändert den WordPress-Kern nicht: Es umhüllt ihn. WordPress, seine Plugins und Themes werden darin zu Abhängigkeiten, die Composer in einer bestimmten Version installiert und in composer.lock festschreibt. Die Konfiguration ändert sich je nach Umgebung (Entwicklung, Abnahme, Produktion) über Umgebungsvariablen. Das Git-Repository enthält nur noch den individuell geschriebenen Code, die Konfiguration und die Liste der Abhängigkeiten, und laut Roots lassen sich Kern und Plugins außerhalb der Entwicklungsumgebung nicht mehr ändern. Roots versteht diese Organisation als Anwendung der Methode „The Twelve-Factor App“ (die Zwölf-Faktoren-App) auf WordPress; diese Methode beschreibt, wie man Webanwendungen baut, die sich leicht deployen und warten lassen. Updates erfolgen dann im Code, ein Plugin nach dem anderen, und durchlaufen anschließend die Pipeline. Die Standardkonfiguration von Bedrock deaktiviert derzeit automatische Updates und die Installation von Plugins über die Verwaltung (config/application.php).
Aus unserer Sicht lohnt sich Bedrock, sobald eine WordPress-Website wie Software gepflegt wird: individueller Code, mehrere Umgebungen, ein Entwicklungsteam, eine Pipeline. Für eine Website, die man konfiguriert und der man ein Child-Theme oder ein Plugin hinzufügt, ist es nicht nötig. Und Bedrock organisiert das Projekt, mehr nicht: Die Qualität des individuell geschriebenen Codes bleibt Sache derer, die ihn entwickeln.
// config/application.php von Bedrock, Standardkonfiguration
// Deaktiviert die automatischen Updates von WordPress
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
// Deaktiviert den Datei-Editor der Verwaltung
Config::define('DISALLOW_FILE_EDIT', true);
// Verbietet, Plugins über die Verwaltung zu installieren oder zu aktualisieren
Config::define('DISALLOW_FILE_MODS', true);
# Mit Bedrock: ein einzelnes Plugin im Code aktualisieren, dann die Pipeline durchlaufen
composer update wp-plugin/plugin-name
Ohne Bedrock rät der WordPress-Leitfaden zur Härtung der Sicherheit, den Datei-Editor der Verwaltung zu deaktivieren, mit dem sich standardmäßig der PHP-Code von Plugins und Themes ändern lässt; er stellt klar, dass das nicht alles verhindert, aber manche Angriffe stoppen kann (WordPress):
// In wp-config.php: deaktiviert den Datei-Editor der Verwaltung
define( 'DISALLOW_FILE_EDIT', true );
Um ein Plugin nach dem anderen zu aktualisieren, behält man mit WP-CLI, dem Kommandozeilenwerkzeug von WordPress, die Kontrolle: wp plugin update akzeptiert --version, um eine bestimmte Version anzusteuern, --patch, um nur die Fehlerbehebungen zu übernehmen, und --dry-run, um zu sehen, was aktualisiert würde, ohne etwas zu ändern (WP-CLI). Die WordPress-Dokumentation selbst nennt Anpassungen und vorheriges Testen auf einer Abnahmeumgebung als Gründe, automatische Updates zu deaktivieren, und setzt vor ihrer Aktivierung für Plugins voraus, zur vorherigen Version der Website zurückkehren zu können.
Alles Vorangegangene beruht auf derselben Fähigkeit: einen Patch noch am selben Tag in Produktion zu bringen, ohne etwas kaputt zu machen. Diese Fähigkeit lässt sich am Tag der Warnmeldung nicht improvisieren. Sie hängt davon ab, wie die Software im Alltag ausgeliefert wird.
Erfahrungsgemäß kommt eine kritische Lücke in einer Organisation, in der jedes Deployment in die Produktion selten ist (ein Abend pro Quartal, Tests von Hand, mehrere Personen im Einsatz), außer der Reihe. Man muss außerhalb des Zeitplans eine Notfallkorrektur aufsetzen, die Personen zusammenholen, die deployen können, die Tests von Hand wiederholen, ein Wartungsfenster reservieren, manchmal die Zustimmung eines Gremiums einholen. Der Patch wird zum Projekt, und in der Zwischenzeit bleibt die Anwendung ungeschützt. Dieser Auslieferungsrhythmus verleitet dazu, direkt auf dem Server von Hand zu korrigieren. In Continuous Delivery lehnen Jez Humble und Dave Farley diese Abkürzung unumwunden ab: Bei einem kritischen Fehler „umgehen Sie unter keinen Umständen Ihren Prozess“. Sie erinnern auch daran, dass es manchmal besser ist, zur vorherigen Version zurückzukehren, als eine Korrektur zu deployen. Eine von Hand in der Produktion vorgenommene Korrektur ist nicht getestet, kann das Problem verschlimmern und wird oft nirgends festgehalten.
Mit Continuous Delivery, praktiziert im Rahmen eines adaptiven Ansatzes, bei dem die Software laufend anhand ihrer Nutzung angepasst wird, ist derselbe Patch eine Änderung wie jede andere. Jez Humble definiert Continuous Delivery als „die Fähigkeit, Änderungen aller Art, einschließlich neuer Funktionen, Konfigurationsänderungen, Bugfixes und Experimente, sicher, schnell und nachhaltig in Produktion oder in die Hände der Nutzer zu bringen“ (continuousdelivery.com). Dave Farley stellt klar, dass die Deployment-Pipeline „der EINZIGE Weg in die Produktion“ ist: Jede Änderung durchläuft sie, das PHP-Update wie die neue Funktion. Die Änderung durchläuft dieselben automatisierten Tests und geht dann in Produktion. Da jede Änderung diesen Weg nimmt, ist das Verfahren bereits erprobt, wenn ein Patch kommt.
Diese Disziplin verändert auch die Art, das Projekt zu steuern. Eine kritische Lücke wird nicht für das Ende der Woche eingeplant: Sie hat Vorrang vor allem anderen, noch am selben Tag. Ein Team, das die Disziplin von Continuous Delivery einhält, kann seine Prioritäten innerhalb eines Tages ändern, je nachdem, was eintrifft, weil nichts von dem, was gerade in Arbeit ist, die Auslieferung des Patches in die Produktion blockiert.
DORA (DevOps Research and Assessment), das Forschungsprogramm von Google Cloud zur Entwicklung und Auslieferung von Software, misst, was diese Praxis verändert. DORA misst die Zeit bis zum Einspielen eines Patches nicht direkt. Die nächstliegende Kennzahl ist die Durchlaufzeit einer Änderung, von dem Moment, in dem sie in den Code eingecheckt wird, bis zu dem Moment, in dem sie in Produktion ist. In Modern Software Engineering stellt Dave Farley eine verwandte Frage: Wie lange dauert es, bis eine Änderung von einer einzigen Zeile von der Idee zur funktionierenden Software gelangt? Aus unserer Sicht ist diese Zeit auch die Zeit, die es braucht, um den nächsten Sicherheitspatch einzuspielen. Die Forschung von DORA zeigt regelmäßig, dass „Geschwindigkeit und Stabilität keine Zielkonflikte sind“ (DORA). Laut einer Zusammenfassung des Berichts 2024, veröffentlicht von Octopus Deploy, einem Anbieter von Deployment-Werkzeugen, bringen die leistungsstärksten Teams eine Änderung in weniger als einem Tag in Produktion und erholen sich von einem fehlgeschlagenen Deployment in weniger als einer Stunde (Octopus Deploy).
Gremien zur Freigabe von Änderungen gleichen eine langsame Auslieferung nicht aus. In Modern Software Engineering zitiert Dave Farley die im Buch Accelerate veröffentlichten Forschungsergebnisse: „Die Freigabe durch eine externe Instanz, etwa einen Vorgesetzten oder ein Change Advisory Board, erhöht die Stabilität der Produktionssysteme schlicht nicht […] Sie ist sogar schlechter, als überhaupt keinen Freigabeprozess für Änderungen zu haben.“
Die maßgeblichen Stellen der IT-Sicherheit setzen nicht dieselbe Frist. Die ANSSI fordert in ihrem Leitfaden von 2017, Sicherheitspatches „innerhalb des Monats nach ihrer Veröffentlichung durch den Hersteller“ einzuspielen, und sieht eine mögliche Qualifizierung der Patches und ein schrittweises Ausrollen vor (Maßnahme 34). Die OWASP warnt in ihrer Rangliste 2025 der zehn kritischsten Risiken für Webanwendungen vor diesem Rhythmus: Die Exposition „tritt häufig in Umgebungen auf, in denen das Einspielen von Patches eine monatliche oder vierteljährliche Aufgabe unter Änderungskontrolle ist, was Organisationen tage- oder monatelang für bereits behobene Lücken angreifbar lässt“. Die Frist von einem Monat stammt aus dem Jahr 2017, bevor die Zeit bis zur Ausnutzung auf wenige Tage fiel, und versteht sich als Höchstgrenze. Bei Angriffen, die manchmal beginnen, bevor der Patch veröffentlicht ist, reicht sie als Ziel nicht mehr aus. Die Prüfung der Patches, die die ANSSI vorsieht, zwingt nicht dazu, einen Monat zu warten: Automatisierte Tests in der Pipeline leisten sie bei jeder Änderung.
Vor dem Economic Club of Chicago hat Jamie Dimon, Vorstandschef von JPMorgan Chase, laut Business Insider vom 16. Oktober auf zwei Risiken hingewiesen: KI-Agenten, die auf den Bankkonten ihrer Nutzer handeln, und KI-Werkzeuge, die Lücken früher aufdecken. Um anstelle ihrer Nutzer zu bezahlen, brauchen diese Agenten deren Bankzugangsdaten: „Wenn sie Zahlungen für Sie ausführen können, müssen Sie ihnen Ihre Bankzugangsdaten geben […] Sie gehen davon aus, dass sie in Ihrem Namen richtig handeln, und das ist vielleicht nicht der Fall“. Am Vortag, bei der Vorstellung der Quartalszahlen der Bank, hatte er gewarnt, dass JPMorgan nicht „jeden beliebigen externen Agenten ins Unternehmen lassen“ werde. Derzeit hindert JPMorgan externe KI-Agenten daran, auf den Konten seiner Privatkunden zu handeln, und lässt ihnen nur Lesezugriff. Laut Benzinga warnte er außerdem, dass KI-Werkzeuge Hunderte schwerer Lücken in Open-Source-Code aufdecken, was ganze Branchen „völlig schutzlos“ lasse.
Bei den Lücken, die die KI früher aufdeckt, setzt Continuous Delivery bei der Dauer bis zum Einspielen des Patches an. Schon 2010 verlangten Jez Humble und Dave Farley in Continuous Delivery, schnell eine neue Version veröffentlichen zu können, „falls kritische Fehler oder Sicherheitslücken entdeckt werden“. Sie verlangten auch, dass die Produktion „vollständig gesperrt“ ist, damit nur die Deployment-Pipeline dort Änderungen vornehmen kann. Mit diesen Praktiken und denen aus dem Abschnitt über die Art der Auslieferung geht der Patch für eine von einer KI gefundene Lücke wie jede andere Änderung in Produktion. Aus unserer Sicht verkürzt Continuous Delivery die Zeit, in der eine Lücke, für die es bereits einen Patch gibt, bei Ihnen ausnutzbar bleibt; Lücken zu finden und Angriffe zu stoppen ist Sache der übrigen Praktiken, die dieser Artikel beschreibt.
Das andere Risiko, das Jamie Dimon beschreibt, ist eine Frage der Zugriffsrechte: ob ein Agent tatsächlich für die Person handelt, die ihn autorisiert hat, bei einer Bank wie bei jeder anderen Anwendung. Die OWASP zählt „übermäßige Autonomie“ zu den Risiken von KI-Anwendungen, und das NCSC fordert, auf Agenten das Prinzip der minimalen Rechte anzuwenden. Wenn Ihre Anwendung KI-Agenten für Ihre Nutzer handeln lässt, raten wir wie die OWASP, ihnen nur die nötigsten Rechte zu geben, sie im Kontext des betreffenden Nutzers handeln zu lassen und Aktionen mit großer Tragweite von einem Menschen freigeben zu lassen.
An dem Tag, an dem eine Lücke Ihre Software betrifft, umfasst das Vorgehen acht Schritte. Es stützt sich auf vier öffentliche Dokumente: den Leitfaden „Was tun bei einem Cyberangriff?“ von cybermalveillance.gouv.fr, dem staatlichen französischen Hilfsdienst für Opfer von Cyberangriffen, geschrieben für Geschäftsführer; sein Merkblatt zum Defacement von Websites; den Hygiene-Leitfaden der ANSSI; das Merkblatt mit Sofortmaßnahmen des CERT-FR, auf das seine Warnmeldung zu PHP verweist. Es ist besser, diese Schritte vor diesem Tag gelesen zu haben und zu wissen, wer was tut.
1. Wissen, ob Sie betroffen sind. Welche Websites und welche Anwendungen verwenden die betroffene Komponente, in welcher Version, auf welchen Servern, bei welchem Hoster? Bei PHP2Shell gilt die Frage auch für Produkte, die PHP enthalten, ohne es zu zeigen. Wenn ein Dienstleister oder ein Hoster Ihre Website betreut, ist das die erste Frage an ihn. Ein Protokoll jeder durchgeführten Maßnahme führen und es außerhalb des betroffenen Systems aufbewahren, wie es das CERT-FR verlangt.
2. Aktualisieren oder isolieren. Vollständigen Schutz bietet das Update: bei PHP2Shell PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, eine neuere Version desselben Zweigs oder der Patch Ihrer Distribution. Da die Unterstützung von PHP 8.2 am 31. Dezember 2026 endet, ist ein Umstieg auf PHP 8.3 oder neuer besser. Ist das Update nicht sofort möglich, die aus dem Internet erreichbaren Anwendungen isolieren, bis es möglich ist, wie es das CERT-FR und das CERT-EU raten.
Achtung, eine Falle: Bei PHP2Shell schützt der Wartungsmodus einer WordPress-Website oder einer Laravel-Anwendung nicht vor dieser Lücke. Die Lücke wird ausgelöst, während PHP die Anfrage vorbereitet, bevor der Code der Website ausgeführt wird. Die Blockierung muss vor PHP erfolgen: auf dem Webserver oder dem Reverse Proxy, der eine statische Seite zurückgibt, oder auf Netzwerkebene.
Scheint der Server kompromittiert, nennt die ANSSI den richtigen Reflex: die Maschine vom Netzwerk trennen, sie aber eingeschaltet lassen und nicht neu starten, um die für die Analyse nützlichen Informationen nicht zu verlieren (Maßnahme 40).
3. Nach Spuren eines Eindringens suchen. Amazon rät, mindestens bis zum 17. Oktober zurück zu suchen, nicht erst ab dem Tag der Veröffentlichung. Bei PHP2Shell: ungewöhnliche Datei-Upload-Anfragen, gefolgt von Speicherfehlern oder wiederholten 500-Fehlern, ungewöhnlich lange oder fehlerhafte Session-Cookies, unerklärliche Neustarts von PHP (Patchstack). Allgemeiner die Signale aus dem Abschnitt über das Monitoring: neue Dateien in den Verzeichnissen der Website, vom Webserver gestartete Programme, unbekannte ausgehende Verbindungen, neue Administratorkonten. Patchstack empfiehlt, einen angegriffenen Server als möglicherweise kompromittiert zu behandeln.
4. Beweise sichern, bevor man aufräumt. Cybermalveillance.gouv.fr empfiehlt, die Logs der Firewall, des Reverse Proxys und der betroffenen Server zu sichern und eine vollständige Kopie der angegriffenen Maschine und ihres Arbeitsspeichers anzufertigen. Der Leitfaden für Geschäftsführer rät, „vor jeder Maßnahme zur Behebung“ Anzeige zu erstatten. Wer vor dieser Kopie eine saubere Version neu deployt, löscht genau das, was helfen würde zu verstehen, was passiert ist.
5. Alle Secrets ändern, die auf dem Server lagen. Wir raten, die Datenbankpasswörter zu ändern, die Schlüssel der Anwendung (Schlüssel und Salts von WordPress, APP_KEY von Laravel, Verschlüsselungsschlüssel von Magento), die Zugangsschlüssel zu Drittdiensten (Zahlung, E-Mail-Versand, Speicher), die Konten für den Nachrichtenversand, die auf dem Server vorhandenen Deployment-Token, die privaten Schlüssel der Zertifikate und die Administratorkonten, und die offenen Sessions zu beenden. Die neuen Secrets werden in einer sauberen Umgebung erzeugt und nur auf dem Server deployt, der im nächsten Schritt neu aufgebaut wird, nie auf dem noch kompromittierten Server. Das CERT-FR fordert, „die möglicherweise kompromittierten Secrets zu ändern“, cybermalveillance.gouv.fr, vor jeder Wiederinbetriebnahme alle Passwörter zu ändern. CosmicSting hat es gezeigt: Ein vor dem Patch gestohlener Schlüssel bleibt danach gültig, und Sansec empfiehlt, den Verschlüsselungsschlüssel zu ersetzen und den alten ungültig zu machen. Ändert man den Schlüssel der Anwendung, werden alle Nutzer abgemeldet; das ist so gewollt. Vorsicht dagegen bei Daten, die mit dem alten Schlüssel verschlüsselt wurden: Sie werden unlesbar, es sei denn, der alte Schlüssel bleibt zum Entschlüsseln verfügbar oder die Daten werden mit dem neuen neu verschlüsselt. Laravel erlaubt es, frühere Schlüssel zum Entschlüsseln zu behalten (APP_PREVIOUS_KEYS), und Adobe stellt für Magento ein Verfahren zum Schlüsselwechsel und einen Befehl zum Neuverschlüsseln der Daten bereit.
6. Wurde der Server kompromittiert, aus einer sauberen Quelle neu aufbauen. Wir raten davon ab, das alte Server-Image oder den alten Code wiederherzustellen, die die Web Shell enthalten können. Mit einer Pipeline baut man den Server und die Anwendung aus dem Code-Repository neu auf, in einer sauberen Version, mit dem Patch. Die Daten werden aus unserer Sicht aus einem Backup wiederhergestellt, das älter ist als der früheste mögliche Zeitpunkt des Eindringens. Hier machen die getesteten Offline-Backups den Unterschied. Cybermalveillance.gouv.fr sieht danach eine schrittweise Wiederinbetriebnahme vor, nachdem sichergestellt ist, dass die Lücke behoben ist.
7. Melden. Wenn personenbezogene Daten eingesehen, verändert oder vernichtet werden konnten, muss der Vorfall innerhalb von 72 Stunden der CNIL, der französischen Datenschutzbehörde, gemeldet werden, erinnert cybermalveillance.gouv.fr. Melden Sie den Schaden auch Ihrer Versicherung. Für Unterstützung rät die ANSSI, einen qualifizierten Dienstleister für die Reaktion auf Sicherheitsvorfälle hinzuzuziehen (Maßnahme 40 ihres Leitfadens). In Frankreich erreichen Sie im Notfall Polizei und Gendarmerie unter der 17.
8. Lehren ziehen. Die Frage stellen, die cybermalveillance.gouv.fr an den letzten Schritt seines Leitfadens setzt: Was haben wir gelernt? Wie lange hat es gedauert, den Patch einzuspielen, und warum? Für diese Zeit misst DORA die nächstliegende Kennzahl, weiter oben vorgestellt: Je kürzer sie im Alltag ist, desto früher nach seiner Veröffentlichung wird der nächste Patch eingespielt. Was hat es ermöglicht, oder hätte es ermöglicht, den Angriff zu bemerken?
Ein Sicherheitspatch ist eine Änderung wie jede andere: Er durchläuft dieselbe Pipeline wie der Rest. Wir suchen nicht nach Lücken; diese Suche ist Sache der Forscher. Unsere Aufgabe ist es, zu begrenzen, was ein Angreifer über die nächste Lücke erreichen kann, alarmiert zu werden, sobald sie ausgenutzt wird, und ihren Patch einzuspielen, sobald er veröffentlicht ist.
Dasselbe Team entwickelt, testet, deployt und wartet Ihre Software laufend, in derselben Pipeline. Jedes Produktions-Deployment durchläuft eine Deployment-Pipeline: Sicherheit, Performance, Barrierefreiheit, alles wird automatisch geprüft, bevor es die Produktion erreicht. Wir bringen eine Änderung nach der anderen in Produktion, nachdem die Pipeline sie geprüft hat. Bei einem Vorfall kehren wir zur vorherigen Version zurück.
Für die Anwendungen, die wir entwickeln, setzen wir mit einer Deployment-Pipeline Folgendes um. Jede Abhängigkeit ist mit ihrer exakten Version eingetragen. Eine gerade erst veröffentlichte Version wird erst nach drei Tagen übernommen, außer dem Patch für eine schwere Lücke, der installiert wird, sobald er veröffentlicht ist. Jeden Morgen prüft ein geplanter Job, ob eine bekannte Lücke die eingesetzten Komponenten betrifft. Wir richten auch das Monitoring der Server ein, mit Alarmen für die weiter oben beschriebenen Signale. Ein Update von PHP oder einer Komponente durchläuft dieselbe Pipeline wie der Rest.
Bei der Entwicklung individueller Software arbeiten wir mit einem festen Budget, das am Ende jedes Monats für die geleistete Arbeit abgerechnet wird. Ihre Anwendung ist innerhalb eines Monats nutzbar, mit einigen wesentlichen Funktionen: Ihre Nutzer arbeiten sofort damit, und wie sie sie nutzen, bestimmt, welche Funktionen als Nächstes entwickelt werden. Die Wartung ist inbegriffen, einschließlich der adaptiven Wartung: Abhängigkeitsaktualisierungen, Sicherheitspatches, Browser-Kompatibilität. Und damit das, was im letzten Monat funktioniert hat, auch in diesem Monat noch funktioniert, gilt unsere Null-Regressions-Garantie: Jede Regression wird behoben und durch einen automatisierten Test abgesichert, damit sie nicht wiederkehrt, ohne Aufpreis.
Außerdem bieten wir Audits der Software-Produktionskette und Schulungen für technische Teams an. Das Audit prüft, ob die in diesem Artikel beschriebenen Praktiken in Ihrer Deployment-Pipeline und in Ihrer Software verankert sind, und was noch umzusetzen ist.
Ein Sicherheitsupdate erreicht die Produktion noch am Tag seiner Veröffentlichung, wenn jede Änderung dort bereits in kleinen Schritten ankommt. Unser Artikel über Continuous Delivery und Continuous Deployment erklärt, wie das funktioniert, und unser Artikel über den prädiktiven oder adaptiven Ansatz, warum diese Art der Auslieferung zu einem adaptiven Ansatz gehört.
Wenn Sie eine Anwendung übernehmen möchten, deren PHP-Version nicht mehr gepflegt wird, erklärt unsere Seite zur Übernahme und Modernisierung von Anwendungen, wie wir vorgehen.
Sie möchten eine Anwendung entwickeln lassen oder wieder in den Griff bekommen? Sprechen wir darüber?
DISALLOW_FILE_EDIT).config/application.php.save-prefix, save-exact, min-release-age).
GTA 6 zweimal verschoben, The Line infrage gestellt, Akon City aufgegeben, öffentliche IT-Projekte über Budget: warum sich das noch nie Dagewesene nicht verlässlich schätzen lässt, und wie man Kathedralen baute.
Continuous Delivery und Continuous Deployment unterscheiden sich nur in einem Schritt. Warum eine kleine, häufige Änderung weniger riskant ist als eine große, mit Quellen belegt.
Was ist ein Feature Flag? Vier Arten von Toggles, was Sie versuchen sollten, bevor Sie einen hinzufügen, und sieben Anti-Patterns, durch die nie getesteter Code läuft.