KI-Cybersicherheit: Marketing-Systeme sicher betreiben

Die aktuellen PHP-Sicherheitslücken zeigen mehr als die neue Leistungsfähigkeit von KI. Sie machen sichtbar, worauf es beim Betrieb digitaler Systeme ankommt: Verantwortlichkeiten, kontrollierte Zugriffe und die Fähigkeit, Erkenntnisse schnell in wirksame Änderungen zu übersetzen. Für KI-gestützte Marketing-Produktion ist das eine Gestaltungsaufgabe – nicht nur ein IT-Thema.

Der kritische Moment liegt zwischen Entdeckung und Reparatur

Eine Sicherheitslücke zu finden, ist ein Erfolg. Ein veröffentlichtes Update ebenfalls. Für ein Unternehmen entsteht der Schutz aber erst, wenn die betroffenen Systeme identifiziert, aktualisiert und überprüft sind.

Genau diese Strecke wird wichtiger, wenn KI sowohl die Suche nach Schwachstellen als auch die Entwicklung möglicher Angriffe erleichtert. Die entscheidende Frage lautet deshalb nicht nur: Wer hat das leistungsfähigere Modell? Sondern: Wer kann aus einer Warnung rechtzeitig eine überprüfte Reparatur machen?

Der PHP-Fall vom Oktober 2026 bietet dafür ein konkretes Beispiel. Und er zeigt, warum auch Marketing-Verantwortliche über die Produktionskette hinter ihren Websites, Inhalten und Agenten Bescheid wissen sollten.

Was bei PHP tatsächlich passiert ist

Am 21. Oktober veröffentlichte das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen: CVE-2026-109618 und CVE-2026-109619. Beide können die Ausführung von Code auf einem Server ohne vorherige Anmeldung ermöglichen. Die Fehler liegen im PHP-Kern – also unterhalb einer darauf laufenden Website oder Anwendung. Laut PHP besteht das höchste Risiko bei Apache mit mod_php; dort wurde ein Angriff demonstriert, der bereits vor der Ausführung des Anwendungscodes ansetzt. 1

Die Updates für diese beiden Schwachstellen erschienen in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Wer Pakete eines Linux- oder Langzeit-Support-Anbieters verwendet, muss dessen Sicherheitshinweise prüfen: Zurückportierte Korrekturen lassen sich nicht zuverlässig allein an einer öffentlich genannten PHP-Versionsnummer erkennen. Das PHP-Projekt betont, dass nur ein Update die beiden Fehler vollständig behebt; vorübergehende Schutzmaßnahmen decken lediglich bestimmte Angriffswege ab. 1

Wichtig zum Stand dieses Artikels: Am 23. Oktober folgte ein Hinweis auf einen weiteren, ungewöhnliche Konfigurationen betreffenden Angriffsweg mit der Kennung CVE-2026-115560. Am 26. Oktober wurden außerdem Windows-Pakete wegen einer separaten Brotli-Schwachstelle erneuert. Die Versionsliste vom 21. Oktober ist deshalb keine pauschale Aussage, dass damit jedes PHP-Sicherheitsproblem erledigt wäre. Maßgeblich bleiben die aktuellen Hinweise des PHP-Projekts und des jeweiligen Anbieters. 1

OpenAI beschreibt die Zusammenarbeit von Forschern, Wartungsteams und Sicherheitsanbietern im Rahmen von „Patch the Planet“. Wiz berichtet ebenfalls über die Entdeckung der Schwachstellen mithilfe fortgeschrittener KI. Die PHP-Verantwortlichen entwickelten und veröffentlichten die Korrekturen. KI war hier ein Werkzeug innerhalb koordinierter Sicherheitsarbeit – nicht deren Ersatz. 23

Die PHP Foundation liefert einen besonders aufschlussreichen Teil der Vorgeschichte: Erste Anzeichen des Speichererschöpfungsproblems hinter CVE-2026-109618 wurden bereits 2024 erkannt. Ein konkreter Angriffsweg fehlte zunächst. Verschiedene Reparaturansätze brachten Probleme mit Kompatibilität, Verfügbarkeit oder Erweiterungen mit sich; zugleich fehlten Ressourcen und eine tragfähige Entscheidungsroutine. Die Foundation bezeichnet die Verzögerung ausdrücklich als strukturelles Versagen. Das ist keine pauschale Aussage über beide Schwachstellen, sondern ihre Erklärung für den Verlauf dieses Problems. 14

Für unsere These ist gerade das wichtig: Bessere Fehlersuche löst nicht automatisch schwierige Wartungsentscheidungen. Wirksame Sicherheit braucht auch Menschen, Zeit und einen Prozess, der Reparaturen trotz Zielkonflikten ermöglicht.

Eine wichtige sprachliche Trennung: Eine veröffentlichte Schwachstelle ist noch kein belegter Einbruch in jedes betroffene System. Ein Angriffsversuch ist noch kein nachgewiesener erfolgreicher Zugriff. Diese Unterschiede sollten auch dann erhalten bleiben, wenn die Schlagzeile dramatisch ist.

Warum der Vorsprung der Verteidiger keine Garantie ist

ARK Invest leitet aus dem Fall eine optimistische These ab: Verifizierte Verteidiger könnten durch Zugang zu besonders leistungsfähigen KI-Werkzeugen einen asymmetrischen Vorteil erhalten. Initiativen wie OpenAIs Daybreak und Anthropics erweitertes Cyber Verification Program sollen fortgeschrittene Fähigkeiten für defensive Sicherheitsarbeit zugänglich machen. Anthropic hat Project Glasswing in dieses erweiterte Programm integriert. 425

Das ist ein plausibler Ansatz. Es ist aber keine Zusicherung, dass Angreifer stets später kommen.

Amazon Threat Intelligence meldete in seiner MadPot-Telemetrie einen PHP2Shell-Angriffsversuch vom 17. Oktober – vier Tage vor der öffentlichen Bekanntgabe. AWS schreibt ausdrücklich, dass unklar ist, wie der Akteur vorab an die Informationen gelangte und ob die beobachteten Versuche in realen Systemen erfolgreich gewesen wären. Die Beobachtung belegt also weder einen flächendeckenden Einbruch noch, dass KI diesen konkreten Angriff erzeugt hat. Sie zeigt aber, warum ein Unternehmen den Veröffentlichungstag nicht automatisch als Beginn seines möglichen Gefährdungszeitraums behandeln sollte. 6

Am 26. Oktober nahm CISA beide PHP-Schwachstellen in den Katalog bekannter ausgenutzter Lücken auf. Die Gefährdung ist damit nicht nur eine theoretische Möglichkeit. Auch dieser Behördenhinweis belegt aber keinen bestimmten Datendiebstahl bei einem konkret benannten Betreiber. 13

Unsere Schlussfolgerung: Ein Verteidiger-Vorsprung ist ein Zeitfenster, das organisatorisch genutzt werden muss. Wer früh informiert ist, aber keine klare Zuständigkeit für das betroffene System hat, kann diesen Vorsprung verlieren.

Mehr gemeldete Lücken bedeuten nicht automatisch mehr erfolgreiche Angriffe

Auch die Zahlen zur steigenden Zahl veröffentlichter Schwachstellen brauchen Kontext.

Epoch AI betrachtet öffentlich gemeldete Schwachstellen mit hoher oder kritischer Einstufung aus einer Auswahl von 21 Organisationen. In der aktualisierten Auswertung wurden für Juni 2026 rund 1.550 und für Juli rund 2.500 solcher Meldungen gezählt. Epoch weist darauf hin, dass Bewertungen und Datensätze nachträglich geändert werden können. Dadurch verändern sich auch historische Vergleichswerte. Zahlen aus früheren Auswertungen sind deshalb datierte Momentaufnahmen und sollten nur mit Blick auf den jeweiligen Datenstand verglichen werden. 7

Die Auswahl bildet weder alle Softwareanbieter noch sämtliche Angriffe ab. Außerdem kann eine höhere Zahl veröffentlichter Lücken mehrere Ursachen haben: bessere Suchwerkzeuge, mehr Aufmerksamkeit, intensivere Forschung oder veränderte Veröffentlichungspraxis. Die zeitliche Nähe zu neuen KI-Modellen allein beweist keinen ursächlichen Zusammenhang. Epoch benennt diese Einschränkungen selbst. 7

Für Unternehmen ist deshalb ein anderer Blick hilfreicher: Nicht nur die Zahl der Warnungen zählen, sondern prüfen, welche eigene Komponente betroffen ist, ob sie erreichbar ist, was sie darf und ob es Hinweise auf tatsächliche Ausnutzung gibt.

Warum das eine Frage für Marketing und IT gemeinsam ist

Eine moderne Marketing-Produktion endet nicht beim generierten Bild oder Text. Sie verbindet Briefings, Modelle, Vorlagen, Dateispeicher, Content-Management-Systeme, Übersetzungsdienste, Analysewerkzeuge und Veröffentlichungskanäle.

Mit Agenten kommen Systeme hinzu, die nicht nur Vorschläge machen, sondern Werkzeuge aufrufen und Aktionen auslösen können. Entscheidend ist dann nicht allein die Qualität ihrer Antwort, sondern die Reichweite ihrer Berechtigungen.

Gedankliches Beispiel – kein Davies-Meyer-Kundenfall: Ein Agent liest ein externes Briefing, erstellt daraus Beiträge und kann diese direkt veröffentlichen. In einem eingelesenen Dokument stehen versteckte Anweisungen, die den Agenten zu einer anderen Aktion bewegen sollen. Das Problem ist hier kein PHP-Fehler. Es ist eine Vertrauensgrenze: Ein Dokument darf als Arbeitsmaterial dienen, erhält dadurch aber nicht das Recht, Handlungen zu autorisieren.

OWASP beschreibt solche indirekten Prompt Injections. Auch die Einbindung eigener Wissensbestände oder zusätzliches Modelltraining beseitigt dieses Risiko nicht vollständig. Die Schutzmaßnahmen müssen deshalb über eine Anweisung wie „Ignoriere manipulative Texte“ hinausgehen. 8

Ebenso warnt OWASP vor „Excessive Agency“: zu vielen Werkzeugen, zu weitreichenden Berechtigungen oder zu viel Autonomie. Eine besonders passende Empfehlung betrifft ausgerechnet Social Media: Wenn ein KI-System Beiträge veröffentlicht, sollte die Veröffentlichungsaktion einen Freigabeprozess enthalten. Berechtigungen müssen außerdem in den angeschlossenen Systemen durchgesetzt werden – nicht nur vom Modell beurteilt werden. 9

Creative Engineering heißt auch: Befugnisse gestalten

Unser Verständnis von Creative Engineering ist, die Produktionskette hinter der Kreation als System zu gestalten. Das kreative Urteil bleibt beim Menschen; Varianten, Formate, Sprachen und Auslieferung werden zu kontrollierbaren Prozessen.

Sicherheit gehört in dieselbe Konstruktion. Ein Markenregelwerk prüft, ob eine Ausgabe zur Marke passt. Eine technische Berechtigungsprüfung entscheidet, ob ein System eine Handlung überhaupt ausführen darf. Eine menschliche Freigabe bewertet die konkrete Veröffentlichung. Diese Prüfungen erfüllen unterschiedliche Aufgaben und ersetzen einander nicht.

Für die Praxis ergeben sich daraus vier Gestaltungsprinzipien:

1. Entwurf und Veröffentlichung trennen

Ein Agent, der Texte entwirft, braucht nicht automatisch Rechte zum Veröffentlichen. Wo beides notwendig ist, sollten die Schritte getrennt und ihre Berechtigungen ausdrücklich festgelegt sein. Dass eine Ausgabe die Markenprüfung besteht, bedeutet nicht, dass sie auch veröffentlicht werden darf. 9

2. Zugänge nach Aufgabe vergeben

Ein Recherchewerkzeug braucht andere Rechte als ein Veröffentlichungssystem. Zugangsdaten gehören nicht in Briefings, Modellanweisungen oder ungeschützte Protokolle. OWASP empfiehlt unter anderem zentrale Verwaltung, eng begrenzte Zugriffe, Protokollierung und einen geregelten Lebenszyklus für Geheimnisse. Daraus folgt für die Produktionskette: Zugänge müssen zuordenbar und im Notfall widerrufbar sein. 10

3. Updates als Teil des Betriebs behandeln

NIST beschreibt Patch Management nicht als bloße Installation, sondern als Prozess aus Identifizieren, Priorisieren, Beschaffen, Installieren und Überprüfen. Ein Update ist also erst dann erledigt, wenn sein wirksamer Einsatz kontrolliert wurde. Für Marketing-Systeme heißt das: Auch alte Kampagnenseiten, kleine Automatisierungen und selten genutzte Anbindungen brauchen einen Wartungsverantwortlichen. 11

4. Freigaben nach Konsequenz gestalten

Nicht jede ungefährliche Zwischenaktion braucht einen Menschen. Bei einer öffentlichen Veröffentlichung, einem größeren Datenexport oder einer Budgetänderung sind die Folgen jedoch andere als bei einem internen Entwurf.

Unsere Empfehlung ist deshalb keine maximale Zahl an Bestätigungen, sondern eine passende Abstufung: begrenzte, reversible Arbeit automatisieren; folgenreiche Aktionen kontrolliert freigeben. Dabei muss sichtbar sein, was passieren soll, wo es passiert und welche Daten oder Inhalte betroffen sind. Eine pauschale Frage wie „Vertraust du dem Agenten?“ reicht dafür nicht.

Sieben Fragen für den nächsten CMO-CTO-Termin

1. Bestand: Welche Websites, Agenten, Modelle, Anbindungen und Softwarekomponenten gehören zur Produktionskette – einschließlich älterer Kampagnen?
2. Verantwortung: Wer überwacht Sicherheitshinweise, spielt Updates ein und überprüft deren Wirkung? Was übernimmt ein Anbieter, was bleibt bei uns?
3. Zugriff: Welche Daten kann jeder Agent lesen, ändern, exportieren oder veröffentlichen? Welche Rechte sind tatsächlich nötig?
4. Vertrauensgrenzen: Können externe Dokumente, Websites oder Assets Handlungen auslösen, zu denen sie nicht berechtigen sollten?
5. Freigabe: Welche Aktionen brauchen eine überprüfbare menschliche Entscheidung, und was sieht die freigebende Person dabei?
6. Priorisierung: Berücksichtigen wir neben dem Schweregrad auch Erreichbarkeit, Geschäftsauswirkung und Hinweise auf aktive Ausnutzung? CISA betont die Bedeutung bereits ausgenutzter Schwachstellen für die Priorisierung. Das Fehlen eines Eintrags im KEV-Katalog ist umgekehrt kein Sicherheitsnachweis. 12
7. Wiederanlauf: Können wir einen Ablauf stoppen, Zugänge widerrufen, betroffene Systeme untersuchen und unterstützte Änderungen zurücknehmen?

Die Antworten brauchen kein neues KI-Schlagwort. Sie brauchen einen gemeinsamen Blick auf den tatsächlichen Betrieb.

Die bessere KI allein macht noch kein sichereres System

Der PHP-Fall zeigt, dass KI schwierige Sicherheitsarbeit unterstützen kann. Er zeigt zugleich, wie wenig eine Entdeckung allein über den Schutz einzelner Unternehmen aussagt.

Für Marketing-Organisationen liegt die Aufgabe deshalb nicht darin, möglichst viele Sicherheitsfunktionen an ein Modell anzuhängen. Sie liegt darin, die Produktionskette zu verstehen und kontrolliert zu betreiben: mit gepflegten Komponenten, begrenzten Rechten, überprüfbaren Aktionen und klarer Verantwortung.

Der Vorteil entsteht nicht beim Alarm. Er entsteht bei der nachweislich behobenen Lücke.

Wer einen Marketing-Agenten plant, sollte deshalb nicht nur seine Fähigkeiten beschreiben, sondern auch seine Grenzen: Datenquellen, erlaubte Werkzeuge, Freigaben und Betrieb. Das ist ein sinnvoller Ausgangspunkt für ein Gespräch über einen abgegrenzten Agenten-Piloten – ohne daraus ein Sicherheitsversprechen abzuleiten.

---

Quellen und Einordnung

Anstoß: Der bereitgestellte Beitrag von ARK Invest, „The PHP (Hypertext Preprocessor) Security Scare Highlights AI’s Role On Both Sides Of Cybersecurity“, Newsletter #531, 26. Oktober 2026. Der vorliegende Artikel ist eine eigenständige Analyse mit anderer Gliederung, zusätzlichen Quellen und einer auf Marketing-Produktionssysteme bezogenen Argumentation; keine Übersetzung des ARK-Texts. ARKs Anlagethese wird nicht übernommen. Der bereitgestellte Text wurde gelesen; Newsletter und Titel wurden über den Suchabruf bestätigt. Der direkte Abruf war zugriffsbeschränkt.

1. PHP-Projekt: News Archive 2026 – Hinweise vom 21., 23. und 26. Oktober. Primärquelle für Schwachstellen, Korrekturen, Zusatzwarnungen und Anbieter-Backports.

2. OpenAI, 21. Oktober 2026: Patch the Planet: global response coordination as agents uncover critical vulnerabilities. Anbieterbericht über Forschung und Koordination; keine unabhängige Messung eines Verteidiger-Vorsprungs. Recherche über Suchabruf; direkter Abruf zugriffsbeschränkt.

3. Wiz, 21. Oktober 2026: PHP2Shell: AI uncovers critical RCE vulnerabilities. Forschungsbericht eines beteiligten Anbieters. Die plakative Aussage „70% of the Internet“ wird hier bewusst nicht als Risikostatistik übernommen.

4. ARK Invest, 26. Oktober 2026: Newsletter #531. Ausgangsimpuls und zugeschriebene Investorenperspektive.

5. Anthropic, 6. Oktober 2026: Expanding the Cyber Verification Program. Anbieterankündigung zur Zusammenführung von Zugangsprogrammen; kein allgemeiner Sicherheitsnachweis.

6. AWS, veröffentlicht am 21. Oktober 2026, aktualisiert am 22. Oktober 2026: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. Primärbericht über beobachtete Angriffsversuche; Erfolg und Herkunft der Vorabinformationen bleiben ausdrücklich unklar.

7. Epoch AI, 2026; Datentabelle aktualisiert am 3. August 2026: Serious cyber vulnerability disclosures kept climbing in July. Auswahl von 21 Organisationen, öffentliche Meldungen, nachträglich veränderbare Einstufungen; keine Zählung erfolgreicher Angriffe.

8. OWASP, Ausgabe 2025: LLM01: Prompt Injection. Risikobeschreibung und Grenzen gängiger Gegenmaßnahmen.

9. OWASP, Ausgabe 2025: LLM06: Excessive Agency. Begrenzung von Werkzeugen, Berechtigungen und Autonomie; Beispiel zur Freigabe von Social-Media-Veröffentlichungen.

10. OWASP, laufend gepflegte Orientierung: Secrets Management Cheat Sheet. Grundsätze für den Betrieb von Zugangsdaten; kein hier behauptetes Veröffentlichungsdatum.

11. NIST, April 2022: SP 800-40 Rev. 4 – Guide to Enterprise Patch Management Planning. Patch Management als überprüfte vorbeugende Wartung.

12. CISA, 3. November 2021: Reducing the Significant Risk of Known Exploited Vulnerabilities. Quelle für das Priorisierungsprinzip, nicht für aktuelle Katalogeinträge oder verbindliche Pflichten deutscher Unternehmen.

13. CISA, aktualisiert am 26. Oktober 2026: Critical Vulnerabilities in PHP Require Immediate Patching. Bestätigt die KEV-Aufnahme beider CVEs am 26. Oktober; kein opferspezifischer Incident-Bericht.

14. PHP Foundation, 21. Oktober 2026: Today’s PHP security release and how we’re strengthening PHP security. Maintainerperspektive auf Vorgeschichte, Reparaturkonflikte, Ressourcen und organisatorische Veränderungen.