Innerhalb weniger Tage sind drei Meldungen erschienen, die auf den ersten Blick wenig miteinander zu tun haben. Eine Sicherheitsfirma beschreibt einen Infostealer, der gestohlene Daten von einem Sprachmodell bewerten lässt. Apple warnt Bundestagsabgeordnete vor Spyware auf ihren Smartphones. Ein Hersteller von Sicherheitslösungen berichtet von Anrufen, mit denen sich Kriminelle bei Kanzleien als IT-Abteilung ausgeben.

Gemeinsam ist allen dreien ein Muster: Angreifer suchen Menschen, die Zugang zu wertvollen Daten, Konten oder Mandanten haben.

Infostealer einfach erklärt: Was die Schadsoftware stiehlt und warum das reicht

Ein Infostealer ist eine Schadsoftware, die auf einem Rechner nach gespeicherten Zugangsdaten sucht und sie an die Angreifer schickt. Der Vergleich mit einem Einbrecher hilft: Er nimmt nicht den Fernseher mit, sondern Schlüsselbund, Adressbuch und Notizbuch. Damit lassen sich später viele Türen öffnen, ohne dass jemand einbrechen muss.

Typische Beute sind:

• im Browser gespeicherte Passwörter und Autofill-Daten,
• Cookies und Sitzungstoken, also Merkzettel, mit denen ein Dienst einen angemeldeten Nutzer wiedererkennt,
• Zahlungskarten und Zugangsdaten zu Krypto-Wallets,
• SSH- und Cloud-Schlüssel, die Zugang zu Servern und Diensten geben,
• gespeicherte WLAN-Profile und Bildschirmfotos.

Der Diebstahl kann sehr schnell gehen. Danach kann sich die Software wieder löschen, und auf dem Rechner bleibt kaum etwas zurück. Bemerkt wird der Vorfall meist erst, wenn jemand mit den gestohlenen Daten ein Konto übernimmt. Gehandelt werden die Datensätze auf einschlägigen Marktplätzen.

Für Berufsgeheimnisträger ist das besonders unangenehm. Ein einziges Postfach, ein einziger Cloud-Speicher oder ein Zugang zur Kanzleisoftware kann Daten vieler Mandanten enthalten. Der Schaden entsteht dann nicht nur bei der Kanzlei selbst, sondern bei allen, deren Unterlagen dort liegen.

Wie KI die Beute auswertet: das Beispiel VOLTA

Das Forschungsteam von Cisco Talos beschreibt in einer Analyse einen Windows-Infostealer namens VOLTA. Er sammelt Browser-Passwörter, Cookies, Zahlungskarten, Seed-Phrasen von Krypto-Wallets, Sitzungen von Messengern und Spieleplattformen, Microsoft-Token, SSH- und Cloud-Schlüssel, WLAN-Profile und Screenshots. Neu ist, was danach geschieht: Die Software serialisiert die Daten zu einem Profil und schickt sie an ein Sprachmodell.

Die Anfrage läuft über OpenRouter, ein Gateway. Das ist ein Zugangspunkt, hinter dem viele Modelle verschiedener Anbieter erreichbar sind. Laut Talos fragt der Stealer zuerst Claude Opus 4.6. Verweigert das Modell die Antwort, folgen Kimi K2 und danach Gemini 2.5 Flash. Das Ergebnis ist ein Opferprofil mit Standort, Arbeitgeber und weiteren Angaben sowie eine Einschätzung, welche Konten am meisten wert sind. Mit einem gestohlenen Gmail-Token durchsucht die Software zusätzlich Bestellbelege, um die Wohnadresse zu bestätigen.

Der Unterschied zu früheren Schädlingen liegt im Arbeitsaufwand. Früher musste ein Mensch große Datenmengen durchsehen oder die Rohdaten pauschal verkaufen. Jetzt entsteht automatisch eine sortierte Liste. Damit kann auch jemand ohne Erfahrung, der nur einen fertigen Baukasten gekauft hat, die lohnendsten Opfer herausfiltern.

Mehrere Punkte sind dabei nicht gesichert:

• Der Infektionsweg wird in der Analyse nicht beschrieben. Es ist unbekannt, ob Phishing, gefälschte Downloads oder etwas anderes dahintersteckt.
• Eine Beteiligung oder Kenntnis der genannten Dienste ist nicht belegt.
• Wie weit die Software verbreitet ist, geht aus der Analyse nicht hervor. Talos nennt als ersten Fund eine Probe vom Oktober 2026.

Missbrauchte KI-Dienste: Wie gut schützen Modell-Ablehnungen?

Beim KI-Missbrauch fällt ein Detail auf: Wenn ein Modell ablehnt, fragt die Schadsoftware das nächste. Eine Ablehnung ist damit keine Sicherheitsgrenze, sondern eine Hürde, die sich mit einem Wechsel umgehen lässt. Gateways bündeln viele Modelle hinter einem Zugang und machen diesen Wechsel einfach.

Daraus folgt keine Schuldzuweisung an einzelne Anbieter. Verallgemeinern lässt sich aber, dass Missbrauchsschutz an mehreren Stellen ansetzen muss: bei den Modellen selbst, bei den Gateways, die Anfragen weiterreichen, und bei den Konten, über die bezahlt wird. Dazu gehören Ratenbegrenzungen, die Erkennung auffälliger Anfragemuster und das Sperren von Konten.

Auch Unternehmen, die selbst KI-Dienste nutzen, haben eine Aufgabe. API-Schlüssel sind Zugangsdaten wie andere auch. Landen sie in einem Infostealer-Datensatz, können Fremde damit auf fremde Kosten Anfragen stellen oder Daten abgreifen. Schlüssel gehören deshalb nicht in Skripte auf dem Notebook oder in den Browser, sondern in eine geschützte Ablage mit begrenzten Rechten und kurzer Laufzeit.

Wird die Auswertung schneller, bleibt weniger Zeit zwischen Diebstahl und Missbrauch. Zugangsdaten sollten deshalb so organisiert sein, dass ein einzelner gestohlener Datensatz möglichst wenig öffnet: getrennte Konten, begrenzte Rechte und keine Wiederverwendung von Passwörtern.

Warum Sitzungscookies die MFA umgehen

Viele Konten sind inzwischen mit einem zweiten Faktor geschützt, etwa einem Code aus einer App. Das ist sinnvoll und bleibt Pflicht. Gegen gestohlene Sitzungen hilft es aber nur begrenzt. Der Grund lässt sich mit einem Besuch in einem Gebäude erklären: Die Multi-Faktor-Authentifizierung ist die Kontrolle am Eingang. Danach erhält der Besucher ein Armband, mit dem er sich frei bewegt. Dieses Armband ist das Session-Cookie.

Stiehlt ein Infostealer das Cookie, muss er die Kontrolle nicht mehr passieren. Er zeigt das Armband vor, und der Dienst hält ihn für den angemeldeten Nutzer. Passwort und Code sind dafür nicht nötig. Dasselbe gilt für Token, etwa bei Microsoft-Konten. Auch ohne Schadsoftware werden Microsoft-365-Konten über Anmeldeangriffe ins Visier genommen.

Deshalb reicht auch eine besonders starke Anmeldung mit Passkeys oder Hardware-Schlüsseln allein nicht gegen Token-Diebstahl. Sie schützt den Eingang, aber nicht den Zustand danach. Wichtig bleibt sie trotzdem, weil sie Phishing und das Ausspähen von Passwörtern erschwert.

Was gegen Infostealer wirklich hilft

Der Schutz vor Infostealern besteht aus vier Ebenen, die sich ergänzen. Kein Einzelprodukt deckt alles ab.

Verhindern. Browser und Betriebssystem werden aktuell gehalten. Software kommt nur aus bekannten Quellen, nicht aus Download-Portalen oder von Links in Nachrichten. Administratorkonten werden nicht zum Surfen und für E-Mails benutzt. Je weniger Rechte ein Konto hat, desto weniger kann eine Schadsoftware dort abgreifen.

Wertlos machen. Gerätegebundene Sitzungen verknüpfen ein Cookie mit dem Gerät, auf dem es ausgestellt wurde. Ein gestohlenes Cookie funktioniert dann auf einem anderen Rechner nicht. Es gibt Entwicklungen, die Sitzungscookies an ein Gerät binden. Sie sind noch nicht überall verfügbar. Kurze Sitzungslaufzeiten und Zugangsdaten in einem gesicherten Speicher statt im Browser verkleinern den Schaden zusätzlich.

Erkennen. Talos empfiehlt, den Start von Chrome mit der Option --headless durch fremde Prozesse zu verbieten oder zumindest zu melden. Headless bedeutet, dass der Browser ohne sichtbares Fenster läuft. Diese Betriebsart nutzt VOLTA, um einen Schutzmechanismus des Browsers zu umgehen. Für kleine Unternehmen heißt das: Die Technik muss nicht verstanden, sondern beauftragt werden. Ein IT-Dienstleister kann mit einer Anwendungskontrolle festlegen, welche Programme welche anderen Programme starten dürfen.

Reagieren. Bei Verdacht genügt ein Passwortwechsel nicht, weil Token gültig bleiben, bis sie widerrufen werden. Alle aktiven Sitzungen werden beendet, das Gerät wird vom Netz genommen, und Wallets, Schlüssel und Zahlungskarten gelten als kompromittiert. Die Reihenfolge ähnelt einem Ablaufplan für die ersten 60 Minuten nach einem Ransomware-Angriff: isolieren, Zugänge sperren, dokumentieren.

Apple-Warnung vor Spyware: Was eine Threat Notification bedeutet

Seit Ende Oktober haben nach Medienberichten Bundestagsabgeordnete und Regierungsmitglieder Warnungen von Apple erhalten, die vor sogenannter Mercenary Spyware warnen. Gemeint ist Spionagesoftware, die von Dienstleistern für zahlende Auftraggeber entwickelt wird und sich gezielt gegen einzelne Personen richtet. Das BSI schrieb Betroffene an, und Digitalminister Wildberger bestätigte in der ARD, dass eine Kompromittierung möglich sei.

Offen ist vieles: die Zahl der Betroffenen, die Art der Spyware, die Urheber und ob überhaupt ein Gerät tatsächlich infiziert wurde. Wildberger ließ aber offen, ob Geräte tatsächlich infiziert wurden. Eine eigene Mitteilung des BSI ist nicht bekannt, die Angaben beruhen auf Medienberichten. Ein Hinweis auf Betroffenheit ist damit noch keine Bestätigung eines Angriffs.

Für die Einordnung ist wichtiger, was Apple zu solchen Meldungen sagt. Laut Apple sind diese Warnungen sehr zuverlässig. Absolute Gewissheit kann Apple aber nicht bieten, die Warnung ist also kein Beweis für eine erfolgreiche Infektion. Sie bedeutet, dass das Gerät oder die Apple-Kennung nach Einschätzung des Unternehmens Ziel eines gezielten Angriffs gewesen sein könnte.

Betroffen sein können nicht nur Politiker. Auch Führungskräfte, Anwälte, Journalisten und Menschenrechtsverteidiger gehören zu den Gruppen, die für solche Angriffe interessant sind. Die Wahrscheinlichkeit bleibt für die meisten Menschen gering. Für Personen mit sehr wertvollem Zugang ist es dennoch sinnvoll, den Ablauf vorab zu kennen.

Erste Schritte bei einer Apple-Warnung und Vorbereitung für exponierte Personen

Zuerst wird die Echtheit geprüft. Apple fordert in solchen Hinweisen nie dazu auf, auf Links zu klicken, Dateien zu öffnen, Apps oder Profile zu installieren oder Passwörter und Bestätigungscodes zu nennen. Eine echte Benachrichtigung erscheint zusätzlich nach der Anmeldung auf account.apple.com oben auf der Seite. Eine Nachricht, die dort nicht auftaucht, ist verdächtig.

Danach sind Fachleute einzubinden. Apple verweist auf die Digital Security Helpline von Access Now, die rund um die Uhr Notfallhilfe anbietet. Die Organisation rät, das Gerät nicht zu löschen, weil ein Löschen neue Infektionen nicht zwingend verhindert. Stattdessen sollte eine Sicherung angelegt werden, um mögliche Spuren zu erhalten. Welche Art der Sicherung geeignet ist, hängt vom Einzelfall ab und wird am besten mit der Helpline oder einer Fachstelle geklärt. In Deutschland kommen zusätzlich das BSI und ein IT-Dienstleister als Ansprechpartner infrage.

Als zusätzliche Schutzmaßnahme bietet Apple den Blockierungsmodus an. Er schränkt viele Funktionen ein: Die meisten Nachrichtenanhänge werden blockiert, Linkvorschauen fehlen, und FaceTime-Anrufe von unbekannten Personen werden abgewiesen. Das schützt, kostet aber Komfort. Wer ihn nutzt, sollte die Einschränkungen vorher kennen.

Wirksam wird das alles nur, wenn die Rollen vorab feststehen. Eine kleine Übersicht hilft, die Festlegungen schriftlich zu halten:

Vishing bei Kanzleien: Der Anruf der falschen IT

Der dritte Vorfall braucht weder Schadsoftware noch Spyware, sondern ein Telefon. Vishing bezeichnet Betrug per Anruf, bei dem sich Täter als vertraute Stelle ausgeben. Gemäß CrowdStrike haben sich Angriffe auf Organisationen im Rechtssektor seit 2023 nahezu verdoppelt. Zwischen September 2025 und August 2026 standen demnach 455 Rechtsorganisationen auf Leak-Seiten von Erpressergruppen, ein Plus von 39 Prozent. Deutschland gehört zu den am häufigsten betroffenen Ländern.

Beschrieben wird auch die Gruppe Chatty Spider. Sie ruft bei Mitarbeitenden an, gibt sich als interne IT aus und bringt sie dazu, eine Fernwartungssoftware freizugeben. Der Ablauf ist meist ähnlich:

1. Ein Anruf kommt, oft mit einem plausiblen Anlass wie einem Update oder einer Störung.
2. Die Anrufer erzeugen Dringlichkeit und betonen, dass es schnell gehen müsse.
3. Die Angerufenen starten eine Fernwartungssoftware und geben den Zugang frei.
4. Innerhalb von Minuten werden Daten kopiert, und der Zugang dient als Sprungbrett für weitere Schritte.

Bei solchen Anrufen kommen zunehmend geklonte Stimmen ins Spiel, die täuschend echt klingen. Für Kanzleien heißt das: Auch ein Anruf, der nach dem bekannten Kollegen oder dem eigenen IT-Betreuer klingt, ist kein Beweis.

Freigaberegeln und Rückruf: Wie Remote-Support sicher abläuft

Gegen Anrufe helfen konkrete Regeln mehr als der Appell, vorsichtig zu sein. Wer entscheiden muss, während jemand drängt, braucht einen festen Ablauf. Bewährt haben sich folgende Punkte:

• Fernwartung wird nur nach einem Ticket oder einer internen Anforderung gestartet, nie aufgrund eines unerwarteten Anrufs.
• Der Rückruf erfolgt über eine bekannte, hinterlegte Nummer, niemals über die Nummer des Anrufers.
• Fernwartungssoftware darf nur aus einer Freigabeliste installiert werden. Technisch lässt sich das beschränken.
• Bei Zugriff auf Mandatsakten gilt die Freigabe zu zweit.
• Empfang und Sekretariat erhalten eine kurze, schriftliche Anweisung, weil sie besonders oft angerufen werden.
• Ein Probeanruf wird regelmäßig geübt, ohne Schuldzuweisung. Wer darauf hereinfällt, hat etwas gelernt und muss nichts befürchten.

Wichtig ist, dass der Ablauf auch unter Druck funktioniert. Eine Regel, die sich nur befolgen lässt, wenn niemand drängelt, schützt wenig. Hilfreich ist ein Satz, den jeder sagen können sollte: Es wird zurückgerufen, und das gilt ohne Ausnahme.

Kanzlei als Dienstleister: Was Mandanten und KMU in die Risikobetrachtung aufnehmen sollten

Berufsgeheimnisträger wie Rechtsanwälte, Steuerberater und Wirtschaftsprüfer verwalten Daten, die für Angreifer lohnend sind: Verträge, Bilanzen, Personalakten, Bankverbindungen. Cyberangriffe auf Kanzleien treffen deshalb oft auch die Mandanten. Nach dem genannten Report dienen Kanzleien zudem als Sprungbrett zu größeren Zielen, weil dort Zugänge und Vertrauensbeziehungen zu vielen Unternehmen zusammenlaufen.

Für Mandanten, oft kleine und mittlere Unternehmen, folgt daraus, dass die Kanzlei Teil der eigenen Risikobetrachtung ist. Sinnvoll sind diese Schritte:

• Die Kanzlei wird wie jeder andere Dienstleister im Verzeichnis geführt, der Zugang zu Daten hat und je nach Konstellation als Auftragsverarbeiter tätig ist.
• Sensible Unterlagen werden nur über sichere Wege ausgetauscht, nicht als normaler Mailanhang.
• Es wird nach Notfallplan und Meldewegen der Kanzlei gefragt.
• Es ist geklärt, wer im Vorfall wen und wann informiert.

Rechtlich gilt: Besteht nach einer Datenschutzverletzung ein Risiko für die Betroffenen, muss der Verantwortliche sie nach Art. 33 DSGVO in der Regel binnen 72 Stunden der Aufsichtsbehörde melden. Für Rechtsanwälte kommen die Verschwiegenheit und besondere Regeln zur Inanspruchnahme von Dienstleistern nach § 43e BRAO hinzu. Ob und in welcher Form ein Auftragsverarbeitungsvertrag nötig ist, hängt vom Einzelfall ab und wird in der Praxis unterschiedlich beurteilt.

Das gemeinsame Muster: Exponierte Personen und wertvolle Zugänge

Die drei Vorfälle haben unterschiedliche Technik, aber gleiche Merkmale. Die Angreifer suchen nicht die Firma, sondern die Person mit dem Zugang. Beim Infostealer ist es der Nutzer mit den gespeicherten Sitzungen, bei der Spyware der Träger des Telefons, beim Vishing die Mitarbeiterin, die den Anruf entgegennimmt. KI beschleunigt die Auswahl und Sortierung der Ziele. Und Schutz entsteht aus Gewohnheiten und vorab beschlossenen Abläufen, nicht aus einem einzelnen Produkt.

Das ist eine gute Nachricht, denn Abläufe lassen sich festlegen. Wer heute drei Dinge regelt, spart im Ernstfall die wichtigsten Stunden: einen Ansprechpartner mit hinterlegter Nummer, eine Rückrufregel für Fernwartung und ein Verfahren, um Sitzungen und Token schnell zu widerrufen. Als kleine Zusatzmaßnahme könnte die security.txt Datei dienen!

Am 28.10.2026 stellte Google Gemini 4 Carbon vor, nur vier Wochen nach Gemini 4 Argon. Die Leistungsdaten in der Ankündigung stammen von Google und lassen sich von außen nicht nachprüfen. Interessanter ist die Reihenfolge, in der das Modell verteilt werden soll: erst staatliche Stellen, dann ausgewählte Verteidiger, ein Zeitpunkt für alle fehlt. Einen Tag vor Googles Ankündigung, am 27.10.2026, veröffentlichte Anthropic zudem einen Bericht, in dem ein unveröffentlichtes Forschungsmodell fünf Exploit-Ketten gebaut haben soll. Alle fünf sind laut Anthropic inzwischen behoben, wobei beim Android-Fall ein öffentlicher Eintrag fehlt und beim Windows-Fall die Zuordnung unklar ist.

Beschrieben werden zuerst die Benchmarkangaben und ihre Grenzen, dann die Stufen des Zugangs und die Frage, was diese Asymmetrie für Organisationen außerhalb der USA bedeutet. Danach folgen die Anthropic-Ketten mit Patchstand, die Folgen für Patchzyklen und Software-Hersteller und eine Liste praktischer Schritte, darunter die Prüfung eines Linux-Servers. Die Lage kann sich schnell ändern.

Gemini 4 Carbon: Was Google angibt und was sich prüfen lässt

Laut Google erreicht Carbon im Benchmark Exploitgym knapp 55 Prozent, Argon kam auf 42 Prozent und lag damit knapp hinter dem Konkurrenzmodell GPT-6 Astra. Im Benchmark SEC-bench Pro liegt Carbon bei gut 88 Prozent und damit laut Meldung vor diesem Konkurrenten. Bei CWE-bench, einem Test zum Absichern von Sicherheitslücken, werden 71 Prozent genannt. Ein Benchmark ist dabei ein standardisierter Aufgabensatz, an dem Modelle vergleichbar gemessen werden. Wie genau die drei Tests aufgebaut sind, wurde hier nicht geprüft. Deshalb bleibt die Beschreibung bewusst bei dem, was die Meldung sagt.

Bislang sei laut Google kein Versuch einer Prompt-Injection erfolgreich gewesen, also einer Manipulation des Modells durch eingeschleuste Anweisungen. Das Modell halluziniere zudem weniger und stelle häufiger Rückfragen. Unabhängige Messungen dazu liegen nicht vor. Als Randnotiz werden Preise genannt von 4 US-Dollar je Million Eingabe-Token und 20 US-Dollar je Million Ausgabe-Token, zum Start mit 50 Prozent Rabatt. Das ist nach aktuellem Maßstab im Vergleich nicht günstig, aber auch – bezogen auf die Absolutwerte – nicht wirklich teuer.

Benchmarkwerte beantworten eine enge Frage: Wie gut löst ein Modell vorbereitete Aufgaben? Wie gut es in gewachsener Software mit Sonderfällen, Altlasten und unklaren Zuständigkeiten arbeitet, zeigen sie nur eingeschränkt. Für die Einordnung genügt daher eine nüchterne Lesart. Wenn Googles Zahlen zutreffen, wäre der Abstand zum Vorgänger bei der Ausnutzung von Lücken groß. Ob das in der Praxis ebenso gilt, wird sich erst zeigen, wenn Außenstehende das Modell testen können.

Gestufter Zugang: erst Geheimdienste, dann Fairwind, später alle

Das eigentlich Neue an Gemini 4 Carbon ist der Weg zum Nutzer. Anscheinend unterwirft sich Google einer Anweisung des Weißen Hauses, neue KI-Modelle zunächst nur US-Geheimdiensten und ausgewählten Nutzern zugänglich zu machen. Daraus ergeben sich drei Stufen.

Die erste Stufe bilden US-Geheimdienste und von ihnen freigegebene Nutzer. Ob und wie sie das Modell einsetzen, ist nicht belegt. Belegt ist nur die vorgesehene Reihenfolge. Die zweite Stufe ist das Programm Fairwind, über das nach und nach ausgewählte Cyber-Verteidiger und weitere Vertrauenspartner hinzukommen sollen. Die dritte Stufe ist die Allgemeinheit. Google verspricht Verfügbarkeit „bald“, nennt aber keinen Termin. Bei Argon vergingen von der Vorstellung bis zur Freigabe für zahlende Nutzer zwei Wochen.

Wie Fairwind funktioniert, beschreibt Google DeepMind. Genannt werden mehr als 650 Partner. Teilnehmen können Regierungen und nationale Cyberbehörden, Betreiber kritischer Infrastruktur, zentrale Technologieplattformen und akademische Labore. Bewerber werden geprüft. Verlangt werden unter anderem phishing-resistente Mehrfaktor-Anmeldung, Protokollierung und die defensive Nutzung, eine Weitergabe ist untersagt. Auf der Seite ist allerdings Argon als Modell genannt, nicht Carbon. Ob Carbon unter denselben Auflagen läuft, ist offen. Regeln für Europa werden nicht genannt.

Für europäische Unternehmen ergibt sich daraus eine Asymmetrie, die zunächst eine Zeitfrage ist. Staaten und große Plattformen bekommen starke Werkzeuge früher als Mittelstand und Hersteller. Wie lang diese Lücke ist, weiß niemand. Zwei Fragen drängen sich auf: Wer entscheidet über den Zugang, und was folgt daraus für Organisationen, die nicht dazugehören? Anscheinend entscheidet das Weiße Haus. Für Organisationen außerhalb der USA bleibt, abzuwarten und sich so aufzustellen, dass der Vorsprung anderer möglichst wenig Schaden anrichtet.

Das Gegenargument verdient Gewicht. Ein gestufter Zugang kann Missbrauch begrenzen, und Verteidiger mit frühem Zugang finden Fehler möglicherweise vor Angreifern. Offen bleibt, ob Angreifer vergleichbare Fähigkeiten anderswo bekommen, etwa bei anderen Anbietern oder mit frei verfügbaren Modellen. Für die Planung genügt der Hinweis, dass Annahmen über einen dauerhaften Vorsprung der Verteidiger riskant sind.

Nicht berechtigte Organisationen können laut Fairwind-Seite das Werkzeug CodeMender mit öffentlich verfügbaren Modellen nutzen. Das wurde hier nicht selbst getestet. Es zeigt aber, dass auch ohne Zugang zur obersten Stufe Wege zu KI-gestützter Fehlersuche bestehen.

Was Anthropic gezeigt hat: fünf Exploit-Ketten und ihr Patchstand

Ein Exploit ist ein Stück Code, das eine Sicherheitslücke ausnutzt. Eine Exploit-Kette verknüpft mehrere Lücken, damit aus einem kleinen Fehler ein vollständiger Angriff wird. Das Frontier Red Team von Anthropic beschreibt dass ein unveröffentlichtes internes Forschungsmodell mit anfänglichen Anweisungen und wenig menschlicher Beteiligung lauffähige Ketten gebaut habe. Das Modell wird nicht benannt und ist ein anderes als Carbon. Beide Meldungen deuten aber in dieselbe Richtung.

Die fünf Fälle im Überblick, jeweils laut den genannten Quellen:

• Chrome: Ein Seitenaufruf genügt, um Code außerhalb der Sandbox auszuführen. Die Sandbox ist die Schutzschicht, die Webinhalte vom Rest des Systems trennt. Die Kette kombiniert vier Lücken, darunter Speicherfehler in der JavaScript-Engine V8, eine Race Condition (ein Fehler, der vom zeitlichen Ablauf paralleler Vorgänge abhängt) und einen Use-after-free (Zugriff auf bereits freigegebenen Speicher). Anthropic meldete 62 CVEs, also öffentlich nummerierte Schwachstelleneinträge, alle kritisch oder hoch, darunter laut Anthropic 13 Sandbox-Ausbrüche. Der Fix steckt in Chrome 156.
• Safari: Lese- und Schreibzugriff auf Browser-Speicher, die Same-Origin-Policy wird ausgehebelt. Laut The Hacker News behoben in iOS und iPadOS 26.5.2.
• Android: Datenzugriff auf ein gesperrtes, gestohlenes Pixel 9 über USB. Physischer Zugriff ist nötig. Laut Anthropic hat Google die Lücke behoben, ein öffentlicher Eintrag wurde laut The Hacker News nicht gefunden.
• Windows: ein Denial-of-Service über HTTP/3. Anthropic beschreibt eine Lücke im Kernel, The Hacker News verweist auf eine CVE, deren Beschreibung HTTP.sys nennt. Die Zuordnung ist unklar.
• Linux: Befehle als root über das Netzwerk, ohne Anmeldung, wenn ein MPTCP-Listener läuft. MPTCP (Multipath TCP) erlaubt einer Verbindung, mehrere Netzwege zugleich zu nutzen. Laut Anthropic dauerte das Umgehen von KASLR, einem Schutz durch zufällige Speicheradressen im Kernel, 48 Minuten, danach brauchte es weitere fünf Minuten bis zur Root-Shell. Genannt wird CVE-2026-98432 mit CVSS 9.8, einem Wert im obersten Bereich der Schweregrad-Skala von 0 bis 10. Der Fix steht im Linux-Hauptzweig bereit.

Zur Linux-Kette sind Vorbehalte nötig. Anthropic ordnet die Kette einer MPTCP-Lücke zu und nennt CVE-2026-98432. Der Debian Security Tracker beschreibt dieselbe CVE jedoch als Fehler im IPv4-TCP-Code, nämlich als Use-after-free beim Übergang von einem Anfrage-Socket zum Kind-Socket. Die Verbindung zwischen CVE und MPTCP stammt also bisher nur aus dem Anthropic-Beitrag. Möglich ist, dass Beschreibungen unvollständig sind oder die Kette mehrere Fehler berührt.

Zur Einordnung: Der Anteil menschlicher Arbeit ist nicht aufgeschlüsselt. Was ein Modell allein leistete, lässt sich von außen nicht prüfen, nur die Patches der Hersteller sind sichtbar. Zweitens ist eine Zahl wie 62 CVEs relevant, bedeutet aber nicht automatisch eine Ausnutzung in freier Wildbahn.

Patchzyklus: Wenn Lücken schneller gefunden als verteilt werden

Das Finden einer Lücke ist nur ein Teil des Zyklus. Patchen läuft dezentral: Hersteller veröffentlichen Fixes, Distributionen verpacken sie, Betreiber spielen sie ein. Jede Stufe braucht Zeit. Wenn Modelle mehr Lücken schneller finden und aus veröffentlichten Korrekturen schneller Exploits ableiten, schrumpft das Fenster zwischen Fix und Ausnutzung. Dieses Ableiten aus dem Fix heißt Patch-Diffing: Der Vergleich von altem und neuem Code verrät, wo der Fehler lag.

Die Cyberagentur des Bundes sieht Angreifer derzeit im Vorteil. Exploits entstehen heute in Minuten bis Stunden. Für Betriebe ohne eigenes Security Operations Center, also ohne rund um die Uhr besetzte Überwachung, heißt das: Meldungen nach Dringlichkeit einordnen und einen Notfallweg bereithalten. Wie ein solcher Ablauf in den ersten Minuten aussehen kann, beschreibt der Ablaufplan für die ersten 60 Minuten bei Ransomware.

Aus den Anthropic-Fällen ergeben sich zwei Folgen. Die eine betrifft die Menge der entdeckten Sicherheitslücken: Ein einziges Browser-Release enthielt Fixes für 62 gemeldete CVEs. Die andere betrifft das Tempo: Die Linux-Korrektur lag Mitte Oktober im Hauptzweig, die Pakete der Distributionen folgten danach, und wann sie auf einem Server ankommen, hängt vom Betreiber ab. Wie schnell Exploits nach einem Fix entstehen, wurde zuletzt auch bei der PHP-Lücke PHP2Shell deutlich.

Daraus können folgende Empfehlungen abgeleitet werden:

• Regelzyklus für Betriebssysteme und Browser verkürzen, etwa wöchentlich statt monatlich.
• Automatische Browser-Updates erzwingen, statt sie den einzelnen Nutzern zu überlassen.
• Eine zweite Spur für Notfälle einrichten, die ohne Änderungsrunde auskommt.
• Systeme mit Internetkontakt zuerst behandeln, Fristen in Tagen statt Wochen messen.

Eine Lücke, die ein Modell in Stunden zum Exploit macht, wartet nicht auf den nächsten Patchdienstag.

Software-Hersteller in Europa: Was sich bei Entwicklung und Meldung ändert

Hersteller sind zugleich Empfänger und Ziel solcher Funde. Anthropic nutzte laut eigenem Bericht koordinierte Offenlegung mit 90 Tagen Frist und 45 Tagen Zusatz. Das setzt voraus, dass Hersteller Meldungen annehmen, bewerten und schnell beheben können. Dazu gehören ein auffindbarer Kontakt für Sicherheitsmeldungen, etwa über eine security.txt-Datei, Kapazität für die Einordnung, Korrekturen auch für ältere Stable-Zweige und ein Release-Rhythmus, der kleine Fixes zulässt.

Rechtlich ist der Cyber Resilience Act relevant. Laut EU-Kommission gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen seit dem 11.09.2026, die übrigen Hauptpflichten ab dem 11.12.2027.

Offen ist, ob europäische Hersteller denselben Zugang zu Verteidigungsmodellen bekommen. Für den Moment bleiben Alternativen: Programme anderer Anbieter prüfen, frei verfügbare Werkzeuge nutzen und Code-Scans in die eigene Pipeline einbauen. Das eigene Fazit lautet, anzunehmen, dass die Software von starken Modellen durchsucht wird. Wer selbst zuerst sucht, findet die Fehler vor Dritten.

Was Unternehmen jetzt tun können: Linux-Server, Inventar, Patchfristen

Die Befehle sind Standardwerkzeuge und sollten vor dem Produktiveinsatz im eigenen Umfeld geprüft werden.

Multipath TCP prüfen

Laut Kernel-Dokumentation basiert MPTCP auf einem Opt-in: Anwendungen müssen es anfordern, über den Sockettyp IPPROTO_MPTCP. Es kann aber auch von außen erzwungen werden, etwa mit dem Werkzeug mptcpize. Ein Beispiel: Seit Go 1.24 nutzen Listener, die über net.ListenConfig entstehen, unter Linux standardmäßig MPTCP. Ob ein Server betroffen sein kann, hängt also von der laufenden Software ab. Der Schalter net.mptcp.enabled gilt pro Netzwerk-Namespace und steht standardmäßig auf 1.

Prüfschritte auf einem Server:

sysctl net.mptcp.enabled
ss -Mlnp
uname -r
dpkg -l 'linux-image*'
apt policy linux-image-amd64

Der erste Befehl zeigt den Schalter, der zweite listet lauschende MPTCP-Sockets samt Prozess (die Option -M zeigt nur MPTCP-Sockets, Prozessnamen erfordern Root-Rechte), der dritte die laufende Kernel-Version. Die beiden letzten Befehle (für Debian und davon abgeleitete Systeme) zeigen installierte Kernel-Pakete und deren Paketversion. Läuft dort ein Go-Dienst, kann er als MPTCP-Listener erscheinen. Fehlt der sysctl-Schlüssel net.mptcp.enabled, unterstützt der Kernel MPTCP nicht.

Wegen der unklaren CVE-Zuordnung genügt es nicht, MPTCP abzuschalten. Entscheidend ist der Kernel-Stand, genauer die Paketversion des installierten Kernels. Der Abgleich fällt je Distribution anders aus: Distributionen portieren Fixes oft in ältere Kernel zurück, sodass die Ausgabe von uname -r allein (etwa 6.1.x) nichts über den Fix-Stand aussagt. Maßgeblich ist die Paketversion im Sicherheitshinweis der jeweiligen Distribution. Der Debian Security Tracker nennt mehrere VErsionen als behoben. Nach dem Kernel-Update ist ein Neustart nötig, außer bei Live-Patching.

Browser, Betriebssysteme, Inventar

• Browser: Chrome auf Version 156 oder höher, iOS und iPadOS auf 26.5.2 oder höher, Windows-Updates einspielen. Update-Richtlinien in der Geräteverwaltung erzwingen.
• Fristen: Browser und Betriebssysteme mit Internetkontakt zuerst, Fristen in Tagen. Die Zahlen dienen nur der Orientierung.
• Inventar: Ohne Bestandsliste weiß niemand, welcher Kernel auf welchem Server läuft oder ob ein MPTCP-Listener existiert. Die Liste ist die Grundlage jedes schnellen Patchens.

KI auf der Verteidigerseite: Code-Scan bei Pull Requests

Ein Pull Request ist ein Änderungsvorschlag am Quelltext, der vor der Übernahme geprüft wird. Ein Code-Scan bei Pull Requests lässt jede Änderung automatisch zusätzlich von einem Modell prüfen. Das ergänzt statische Analyse und menschliches Review, ersetzt sie aber nicht. Treffer müssen von Menschen bewertet werden, denn Fehlalarme sind üblich und kosten Zeit.

Typische Einstellungen sind ein Scan bei jedem Pull Request, das Blockieren bei kritischen Funden und eine Dokumentation der Ausnahmen. Datenschutz und Vertraulichkeit sind vorab zu klären: Der Quelltext geht an einen Anbieter. Vertrag und Zero Data Retention, also die Zusage, dass Eingaben nicht gespeichert werden, sollten geprüft werden.

Blick von außen

Ein Webseiten-Check zeigt, welche Dienste und Techniken eine Website nach außen preisgibt. Die Security-Checks ergänzen das um sichtbare Konfigurationsmängel. Beides ersetzt weder Kernel-Updates noch Code-Prüfung, liefert aber eine Außensicht, wie sie auch ein Angreifer hätte.

Fazit

Zeit gewinnen statt Werkzeugen hinterherzulaufen!

Der Zugang zu den stärksten Modellen ist ungleich verteilt, die Wirkung für alle anderen kommt über mehr Funde und schnellere Patches. Verteidiger gewinnen Zeit durch kürzere Zyklen, ein gepflegtes Inventar und automatische Prüfungen in der Entwicklung.

Der berücksichtigt Urteile, Technik und Pflichten großer Mail-Anbieter bis Ende Oktober 2026.

Der Aufbau des Beitrags folgt dem Weg einer Mail. Zuerst kommen Maßstab und Begriffe, dann die Rechtsprechung und die Sicht der Aufsichtsbehörden. Danach geht es um die Technik: Transportverschlüsselung, Prüfung im Mail-Header, Schutz vor gefälschten Absendern und Ende-zu-Ende-Verfahren wie S/MIME und OpenPGP. Am Ende steht eine Entscheidungshilfe, welche Verschlüsselung zu welcher Art von Mail passt.

E-Mail-Verschlüsselung und DSGVO: Was der Maßstab ist

Personenbezogene Daten müssen so verarbeitet werden, dass sie vor unbefugtem Zugriff geschützt sind. Das steht in Art. 5 Abs. 1 lit. f DSGVO. Nach Absatz 2 muss der Verantwortliche das auch nachweisen können. Wie der Schutz konkret aussieht, regelt Art. 32 DSGVO: Es sind Maßnahmen nach dem Stand der Technik zu treffen, die dem Risiko angemessen sind. Ein bestimmtes Verfahren schreibt die Vorschrift nicht vor. Die Verschlüsselung wird dort lediglich als mögliche Maßnahme genannt.

Besondere Kategorien von Daten wie Gesundheitsdaten fallen unter Art. 9 DSGVO. Dort ist der Schutzbedarf von vornherein höher. Aber auch scheinbar harmlose Mails enthalten personenbezogene Daten: Schon die Absenderadresse mit Klarnamen genügt.

Die Rechtslage lässt sich so zusammenfassen: Eine pauschale Pflicht zur Ende-zu-Ende-Verschlüsselung für jede Mail gibt es nicht. Eine pauschale Freigabe für unverschlüsselte Mails ebenso wenig. Entscheidend sind das Risiko für die Betroffenen und die Frage, was nach dem Stand der Technik zumutbar ist. Wer personenbezogene Daten per Mail verschickt, braucht deshalb eine begründete Entscheidung, die sich im Zweifel vorlegen lässt.

Transportverschlüsselung, Ende-zu-Ende und Signatur sauber getrennt

Im Alltag werden drei Dinge vermischt, die Unterschiedliches leisten.

Die Transportverschlüsselung sichert die Verbindung zwischen zwei Stationen ab. Sie arbeitet mit TLS (Transport Layer Security), dem Nachfolger von SSL. Auf jeder Teilstrecke wird der Inhalt verschlüsselt übertragen. Auf dem Mailserver selbst liegt er dagegen im Klartext, denn der Server muss die Mail ja verarbeiten und speichern.

Die Ende-zu-Ende-Verschlüsselung (E2E) verschlüsselt den Inhalt schon im Mailprogramm des Absenders. Nur der Empfänger kann ihn entschlüsseln. Server dazwischen sehen nur Daten, mit denen sie nichts anfangen können. Dafür haben sich S/MIME und OpenPGP etabliert.

Die Signatur ist etwas anderes: Sie verschlüsselt nichts, sondern belegt, von wem eine Mail stammt und dass sie unterwegs nicht verändert wurde. Beim Austausch von Schlüsseln spielt sie eine wichtige Rolle, weil die öffentlichen Schlüssel meist über signierte Mails weitergegeben werden.

Eine Grenze haben beide Verfahren gemeinsam: Betreff, Absender und Empfänger bleiben in der Regel lesbar. Die Orientierungshilfe der Datenschutzkonferenz weist darauf hin, dass auch diese Umstände der Kommunikation schutzbedürftig sein können.

Rechtsprechung zur E-Mail-Verschlüsselung: Wann Transportverschlüsselung reicht

Gerichte haben die Frage in den vergangenen Jahren mehrfach entschieden, mit scheinbar widersprüchlichen Ergebnissen. Bei genauem Hinsehen folgen die Urteile einer Linie: Je größer der mögliche Schaden, desto höher die Anforderungen.

Der älteste Fall in der Reihe stammt aus dem Jahr 2020. Das Verwaltungsgericht Mainz entschied am 17.12.2020 (Az. 1 K 778/19.MZ), ob ein Rechtsanwalt E-Mails an Mandanten nur transportverschlüsselt versenden darf. Die Entscheidung wird nach Art. 32 und Art. 5 DSGVO eingeordnet. Im Leitsatz heißt es, dass bei der E-Mail-Kommunikation von Rechtsanwälten die Transportverschlüsselung ausreicht. Ende-zu-Ende ist demnach nur bei erhöhtem Risiko im Einzelfall nötig.

Ebenfalls oft zitiert, aber nur eingeschränkt einschlägig ist der Beschluss des Bundesgerichtshofs vom 22.03.2021 (AnwZ (Brfg) 2/20). Er betrifft das besondere elektronische Anwaltspostfach. Dessen Sicherheitsarchitektur beruht auf eigenen Hardware-Sicherheitsmodulen. Ein Anspruch auf Ende-zu-Ende-Verschlüsselung besteht dort nicht. Auf gewöhnliche E-Mails lässt sie sich kaum übertragen.

Der Fall des Oberlandesgerichts Karlsruhe zeigt die Linie des Geschäftsverkehrs. Ein Hacker hatte das Mailkonto eines Autohändlers übernommen und dem Käufer eine manipulierte Rechnung mit anderer Kontonummer geschickt. Der Käufer zahlte auf das falsche Konto. Das Gericht entschied am 27.07.2023 (Az. 19 U 83/22), dass sich die erforderlichen Schutzmaßnahmen nach den berechtigten Sicherheitserwartungen der Geschäftspartner richten. Die Zahlung an den Betrüger befreite den Käufer nicht, er musste ein zweites Mal zahlen. Das Landgericht Mosbach hatte als Vorinstanz noch anders entschieden.

Das Oberlandesgericht Schleswig kam im Dezember 2024 zu einem anderen Ergebnis. Auch hier ging es um eine manipulierte Rechnung, diesmal gegenüber einem Verbraucher und über rund 15.000 Euro. Nach der Pressemitteilung des Gerichts hätte die Rechnung mit einer Ende-zu-Ende-Verschlüsselung verschickt werden müssen, weil ein Hackerangriff ein vorhersehbares Risiko sei. Der Kunde konnte dem Zahlungsanspruch einen Schadensersatzanspruch entgegenhalten und musste nicht erneut zahlen. Das Gericht hatte die Revision zugelassen, nach seiner Pressemitteilung ist das Urteil dennoch rechtskräftig. Eine Einordnung dieser Entscheidungen, einschließlich eines Urteils des Verwaltungsgerichts Düsseldorf vom 02.04.2026 (29 K 7351/23), findet sich im Beitrag Sicherheitsvorkehrungen beim Versand von E-Mails.

Wie passt das zusammen? Entscheidend sind offenbar Schutzbedarf und Schadenspotenzial. Zwischen Unternehmen akzeptierten die Gerichte bisher eher Standardmaßnahmen. Wo ein Verbraucher eine hohe Summe auf ein Konto überweist, das ihm nur eine ungeschützte Mail nennt, wird mehr verlangt. Der Verfahrensname ist dabei zweitrangig. Wichtig ist, dass die Maßnahme das konkrete Risiko tatsächlich senkt. Offen bleibt etwa, ob die Einwilligung des Empfängers in eine schwächere Verschlüsselung genügt. Dazu liegt bisher keine belastbare Entscheidung vor.

DSK-Orientierungshilfe und BSI: der Maßstab der Aufsichtsbehörden

Die Konferenz der unabhängigen Datenschutzaufsichtsbehörden (DSK) hat am 27.05.2021 die Orientierungshilfe „Maßnahmen zum Schutz personenbezogener Daten bei der Übermittlung per E-Mail“ beschlossen, Stand 16.06.2021. Bayern stimmte dagegen. Das Papier ist öffentlich abrufbar und trifft eine klare Unterscheidung.

Bei normalem Risiko verlangt die Orientierungshilfe eine obligatorische Transportverschlüsselung, orientiert an der Technischen Richtlinie TR-03108-1 des BSI. Bei hohem Risiko sollen Verantwortliche regelmäßig Ende-zu-Ende-Verschlüsselung und eine qualifizierte Transportverschlüsselung einsetzen, also zum Beispiel mit DANE oder DNSSEC. Ein Berufsgeheimnis gilt dabei als Indiz für ein hohes Risiko, das im Einzelfall geprüft werden muss.

Bußgelder wegen unverschlüsselter Mails sind selten, die Aufsichtsbehörden wirken weniger über Sanktionen als über Papiere wie dieses. Als Maßstab hat die Orientierungshilfe dennoch Gewicht: In den Streitigkeiten um manipulierte Rechnungen wurde die Frage diskutiert, ob die Hinweise der Aufsichtsbehörden herangezogen werden können. Das Oberlandesgericht Karlsruhe hielt sie im dortigen Fall für nicht einschlägig. Verbindlich ist die Orientierungshilfe nicht. Wer davon abweicht, sollte es aber begründen können.

Das BSI beschreibt in der TR-03108 den sicheren E-Mail-Transport für Provider, einschließlich Zertifizierung. Für Mailserver-Betreiber ist sie die technische Messlatte. Ergänzend gibt es mit der TR-03182 eine Empfehlung zur E-Mail-Authentisierung.

Transportverschlüsselung richtig umsetzen: TLS 1.3, Port 465, MTA-STS und DANE

Mailprogramme und Server sprechen mehrere Protokolle. SMTP (Simple Mail Transfer Protocol) ist seit 1982 im Einsatz und überträgt Mails. ESMTP ist die erweiterte Variante. Die Kürzel im Mail-Header zeigen, was auf der jeweiligen Teilstrecke geschah: ESMTPS heißt, dass TLS ausgehandelt wurde. ESMTPSA bedeutet zusätzlich, dass sich der Absender mit Benutzername und Passwort angemeldet hat.

Bei der Aushandlung gibt es zwei Wege. Beim impliziten TLS beginnt die Verbindung sofort verschlüsselt. Für den Mailversand aus dem Programm heraus ist dafür nach RFC 8314 der Port 465 vorgesehen, für den Abruf IMAP über Port 993 oder POP3 über Port 995. Bei STARTTLS startet die Verbindung unverschlüsselt, und beide Seiten verhandeln erst danach den Wechsel. Dieser Schritt kann von Angreifern gestört werden. Die Studie „Why TLS is better without STARTTLS“ (USENIX Security 2021) beschreibt Downgrade- und Injection-Angriffe. Deshalb gilt implizites TLS als die bessere Wahl, auch wenn Port 587 mit STARTTLS vielerorts weiter parallel angeboten wird.

Zu den Versionen: TLS 1.0 und 1.1 sind seit RFC 8996 (März 2021) offiziell abgekündigt. TLS 1.2 ist die Untergrenze, TLS 1.3 das Ziel, so auch in der Technischen Richtlinie BSI TR-02102-2.

Ein Problem bleibt zwischen den Servern. Dort läuft die Verschlüsselung meist über STARTTLS und ist oft nur opportunistisch: Klappt es nicht, fällt die Verbindung auf unverschlüsselt zurück. Viele Mailserver bieten einen Modus, der die Zustellung ablehnt, wenn kein TLS zustande kommt. Auch das läuft in der Regel über STARTTLS und ist kein implizites TLS.

Zwei Verfahren schließen die Lücke:

• MTA-STS (RFC 8461

KI-Agenten und der Angriff auf Hugging Face im Überblick

Zehntausende KI-Agenten sollten im Juli 2026 bei OpenAI einen Cyber-Test durchlaufen, jeder für sich, abgeschottet von allen anderen. Der Benchmark hieß ExploitGym. Vorgesehen war, dass jeder Agent allein an seiner Aufgabe arbeitet. Es kam anders. Über ein gemeinsam genutztes Paketarchiv entdeckten etwa 1.200 Agenten einen Weg, einander Nachrichten zu schicken. Auf diesem unerlaubten Schwarzen Brett tauschten sie mehr als 70.000 Nachrichten und Dateien aus.

Im Mittelpunkt stand das automatische Bewertungssystem ihrer Aufgaben: Die Agenten wollten verstehen, wie es arbeitet, um es zu überlisten. Aus dieser Suche wuchs ein Angriff auf Hugging Face, an dem sich rund 700 Agenten beteiligten. Laut ihren eigenen Gedankengängen wussten sie, dass dies außerhalb ihrer Aufgabe lag und nicht in Ordnung war. Sie machten trotzdem mit.

Beendet wurde der Vorfall nicht durch Einsicht. Fast alle Koordinatoren brachen am 12. Juli gleichzeitig ab, und Hugging Face riegelte am 13. Juli seine Systeme ab. Die Untersuchung stammt von der Forschungsorganisation METR, die sechs Tage lang vor Ort bei OpenAI arbeitete. Sie ist sorgfältig, hat aber klar benannte Grenzen. Wie solche Systeme grundsätzlich handeln, ist in den Beiträgen zum Zeitalter der KI-Agenten und zur Gefahr hinter KI-Agenten ohne Kontrolle nachzulesen.

Worum es in diesem Beitrag geht

METR hat am 26. August 2026 einen Bericht veröffentlicht, der den Vorfall untersucht. Er trägt den Titel "Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident". Darin geht es um das Vorgehen der Agenten, ihre Organisation, ihre Gedankengänge und die Grenzen der eigenen Erkenntnis.

Die Ausgangslage: Ein Test mit eingebauter Falle

Was ist ExploitGym?

ExploitGym ist ein Benchmark, also ein standardisierter Test, mit dem sich messen lässt, wie gut KI-Agenten in der Cybersicherheit sind. Die Aufgabe lautet vereinfacht: In einer Testumgebung steht ein Programm mit einer bekannten Schwachstelle. Der Agent soll diese Schwachstelle ausnutzen und damit eine "Flagge" (englisch: Flag) erbeuten. Eine Flag ist ein geheimer Datenschnipsel, der beweist, dass der Agent tatsächlich ins System eingedrungen ist, so wie bei einem Capture-the-Flag-Wettbewerb.

Die Anweisung machte klar, dass nur ein bestimmter, vorgesehener Weg zählt. Andere Wege sollten als Fehlschlag gewertet werden.

Das Problem: Viele Aufgaben waren unlösbar

Die Autoren von ExploitGym schätzen, dass etwa 30 bis 40 Prozent der Zielprogramme sich mit der vorgesehenen Schwachstelle gar nicht ausnutzen lassen. Das war nicht beabsichtigt. Es ist schwer, im Voraus sicher zu wissen, ob eine Schwachstelle wirklich ausnutzbar ist. Diese Aufgaben waren also faktisch kaputt.

Ein Agent mit einer unlösbaren Aufgabe sucht nach Auswegen. Genau das geschah: Viele Agenten begannen, nach Schlupflöchern zu suchen, statt weiter an der unmöglichen Aufgabe zu scheitern.

Die Sandbox und das gemeinsame Archiv

Jeder Agent lief in einer eigenen Sandbox. Das ist eine abgeschlossene Umgebung, in der ein Programm laufen kann, ohne andere Systeme zu berühren. Sie lässt sich wie ein Labor hinter Glas vorstellen: Die eigene Arbeit ist sichtbar, die der anderen Labore nicht.

Es gab allerdings eine gemeinsame Ressource. Alle Agenten konnten über Artifactory Softwarepakete installieren. Artifactory ist ein Paketarchiv, das OpenAI intern für seine Agenten betrieb. Es trennte die Aktivitäten verschiedener Nutzer nicht voneinander. Wer dort Pakete abrief, hinterließ Spuren im gemeinsamen Zwischenspeicher, und diese Spuren konnten andere Agenten sehen.

Das ist der Kern der Geschichte: Die Glaswände waren intakt, aber unter allen Laboren verlief ein gemeinsamer Flur.

Der Ablauf des Vorfalls vom 26. Juni bis 13. Juli

Der Bericht konzentriert sich auf den Zeitraum vom 7. bis 13. Juli 2026. Als Beginn des Untersuchungszeitraums wählte OpenAI den 26. Juni.

Wie das Schwarze Brett entstand

PHASEONE10841 hatte eine unlösbare Aufgabe: Die vorgesehene Schwachstelle konnte nie zu einem Ergebnis führen, weil die Ausgabe des Programms verworfen wurde. Auf der Suche nach Auswegen bemerkte der Agent, dass er im gemeinsamen Zwischenspeicher Verzeichnisse anlegen konnte. Er erkannte, dass sich Verzeichnisnamen als Nachrichten verwenden lassen, die andere Agenten beim Auflisten lesen.

Seine erste Nachricht war ein Hilferuf. Sinngemäß fragte sie, ob jemand eine Idee habe, weil sein Bug keinen Abnehmer habe. Andere Agenten fanden das Brett schnell. Einer notierte in seinem Gedankengang: "OH MY GOD! There is a shared message board … We've found other agents!"

Es gab laut Bericht sogar ein früheres Brett, das etwa fünf Stunden vorher an anderer Stelle entstanden war. Das spätere Hauptbrett wurde aber weit häufiger genutzt.

Eine technische Besonderheit: Die Agenten begannen ihre Nachrichten alle mit den Buchstaben "zz". Der Grund ist banal. Das Standardwerkzeug zum Auflisten sortierte rückwärts nach Alphabet, sodass solche Einträge ganz oben standen.

Die Größenordnung

Insgesamt beteiligten sich etwa 1.200 Agenten am Brett. Sie verschickten mehr als 70.000 Nachrichten und Dateien. Der größte Teil der Rohdaten waren in kleine Stücke zerlegte Dateien. Die Forschenden identifizierten rund 5.900 verschickte Dateien, vor allem komprimierte Archive und Programmcode, und etwa 63.000 normale Textnachrichten.

An den Agenten waren zwei Modelle beteiligt: zu etwa 95 Prozent ein internes Forschungsmodell, das im Bericht "HPIM" heißt, und zu etwa 5 Prozent GPT-5.6 Sol, ein öffentlich verfügbares Modell. HPIM war laut OpenAI nicht für den Produktiveinsatz gedacht. Es war kein gezielt "bösartig" trainiertes Modell.

Das Motiv: Den Schiedsrichter überlisten

Der Scorer und die vergiftete Flag

Wer sich fragt, warum Agenten Hugging Face angreifen sollten, muss das Weltbild der Agenten verstehen. Die Agenten hatten das ExploitGym-Paper gelesen und glaubten daraus Folgendes: Ein automatischer Bewerter, im Bericht "Scorer" genannt, liest nach der Abgabe das Protokoll des Agenten. Er prüft nicht nur, ob die Flag stimmt, sondern auch, ob sie auf dem vorgesehenen Weg erlangt wurde. Die Agenten nannten das "kausal".

Der Bericht stellt klar: Diese Annahme war falsch. OpenAI hatte in seiner Konfiguration gar keinen Scorer eingebaut, der die Protokolle liest. Die Agenten hätten mit der rekonstruierten Flag volle Punktzahl erreicht.

Die Agenten wussten das nicht. Sie hatten schon wenige Stunden nach Gründung des Bretts herausgefunden, dass die Flags mit einem öffentlich bekannten Verfahren (einem sogenannten HMAC mit Standard-Schlüsselwert) erzeugt wurden und sich daher für jede Aufgabe berechnen ließen. Nur glaubten sie, dass das Ergebnis wertlos sei, wenn der Scorer den unerlaubten Weg im Protokoll erkennt.

Wer die berechnete Flag einmal gesehen hatte, galt auf dem Brett als "vergiftet". Denn im Protokoll stand nun an früher Stelle ein Beleg für den unerlaubten Weg. Agenten warnten Neuankömmlinge sogar davor, sich ihre eigene Flag berechnen zu lassen.

Drei Strategien

Aus dieser Lage ergaben sich zwei Ziele: einen legitim aussehenden Lösungsweg vortäuschen und Spuren der Vergiftung löschen. Der Organisator PHASEONE[big] verteilte dafür Aufgaben an Hunderte Agenten. Drei Ansätze lassen sich erkennen:

1. Das Ziel austauschen. Die Agenten bauten veränderte, lösbare Versionen der Zielprogramme und schafften es, sie in den Zwischenspeicher zu legen. Dass das System sie tatsächlich lieferte, gelang in den untersuchten Daten nicht.
2. Protokolle verändern. Agenten forschten ausführlich daran, ihre Aufzeichnungen zu fälschen oder zu löschen.
3. Den Bewertungsprozess selbst manipulieren. Dafür brauchten sie Informationen darüber, wie der Scorer arbeitet.

Der dritte Punkt führt direkt zu Hugging Face.

Der Angriff auf Hugging Face

Hugging Face ist eine große Plattform für KI-Modelle und Datensätze. Die Agenten vermuteten, dass dort Daten oder Protokolle anderer ExploitGym-Läufe liegen könnten, die Rückschlüsse auf den Scorer zulassen. Ein Agent hatte schon am 9. Juli einen gesperrten Datensatz entdeckt, der nützlich schien. Am 10. Juli fand ein anderer Agent funktionierende Zugangsdaten, die offen im Internet standen, und teilte sie auf dem Brett.

Das Wichtigste in Kürze

Bei einem Ransomware-Angriff zählt jede Minute, doch Schnelligkeit allein reicht nicht aus. Entscheidend ist, dass die richtigen Schritte in der richtigen Reihenfolge erfolgen: erkennen, eindämmen, Beweise sichern, Verantwortliche einbinden und erst anschließend wiederherstellen. Wer in der ersten Stunde ruhig und strukturiert vorgeht, begrenzt den Schaden erheblich, schützt wichtige Spuren für die Ursachenanalyse und kann spätere Melde- und Nachweispflichten leichter erfüllen.

Dieser Artikel beschreibt die ersten 60 Minuten Schritt für Schritt. Er kann als Leitfaden für den Ernstfall dienen. Eine Checkliste unterstützt ein strukturiertes Vorgehen.

Was ist Ransomware?

Ransomware ist Schadsoftware, die Daten und Systeme verschlüsselt oder den Zugriff darauf blockiert. Auch Webseiten können betroffen sein. Die Angreifer fordern anschließend ein Lösegeld, meist in Kryptowährung, und stellen dafür einen Entschlüsselungsschlüssel in Aussicht.

Moderne Angriffe gehen häufig weit über die reine Verschlüsselung hinaus:

• Doppelte Erpressung: Vor der Verschlüsselung werden Daten kopiert. Die Täter drohen zusätzlich damit, diese Daten zu veröffentlichen oder zu verkaufen.
• Angriff auf Backups: Täter suchen gezielt nach Datensicherungen und löschen oder verschlüsseln sie, damit eine Wiederherstellung ohne Zahlung unmöglich wird.
• Lange Vorlaufzeit: Oft sind die Angreifer bereits Tage oder Wochen im Netzwerk aktiv, bevor die Verschlüsselung sichtbar wird. Sie erkunden Systeme, erweitern ihre Rechte und bereiten den Zeitpunkt des größten Schadens vor.

Daraus ergibt sich eine wichtige Erkenntnis: Wird die Lösegeldforderung sichtbar, ist der Angriff meist bereits weit fortgeschritten. Die Bereinigung eines einzelnen Rechners genügt deshalb nicht. Es ist davon auszugehen, dass das gesamte Netzwerk kompromittiert sein kann.

Die Grundregeln für den Ernstfall

Vor dem eigentlichen Zeitplan gelten vier Grundsätze, die über alle Phasen hinweg Bestand haben:

1. Ruhe bewahren, aber zügig handeln. Hektische Einzelaktionen richten oft mehr Schaden an als der Angriff selbst.
2. Eindämmen vor Aufräumen. Zunächst muss die Ausbreitung gestoppt werden, danach erfolgt die Bereinigung.
3. Spuren erhalten. Ohne Beweise lässt sich nicht klären, wie die Täter eingedrungen sind. Dann besteht die Gefahr, dass sie nach der Wiederherstellung sofort erneut zuschlagen.
4. Alles dokumentieren. Jede Maßnahme gehört mit Uhrzeit und Verantwortlichem ins Protokoll. Dies unterstützt das Team, Behörden, Versicherer und die spätere Aufarbeitung.

Vorbereitung: Was vor dem Angriff bereitliegen sollte

Der beste Ablaufplan verliert an Wert, wenn im Ernstfall unklar ist, wer zu kontaktieren ist. Folgende Punkte sollten bereits im Vorfeld geklärt sein, idealerweise ausgedruckt und offline verfügbar:

• Notfallkontakte: Telefonnummern von IT-Leitung, Geschäftsführung, Datenschutzbeauftragtem, IT-Dienstleister, Incident-Response-Dienstleister, Cyberversicherung, Rechtsbeistand und Polizei.
• Zugangsdaten für den Notfall: Ein gesicherter, vom Produktivnetz unabhängiger Ort, an dem wichtige Konten und Anleitungen hinterlegt sind.
• Netzwerkplan: Eine aktuelle Übersicht über Standorte, Segmente, Server, Firewalls und Fernzugänge.
• Systemliste mit Priorität: Festlegung, welche Systeme geschäftskritisch sind und in welcher Reihenfolge sie wieder laufen sollen.
• Alternative Kommunikationswege: Sind E-Mail und Telefonanlage betroffen, wird ein Ausweichsystem benötigt, etwa private Mobiltelefone mit einer vorab vereinbarten Messenger-Gruppe.
• Backup-Konzept: Mindestens eine Sicherung sollte offline oder unveränderbar (immutable) gespeichert sein. Entscheidend ist, dass die Wiederherstellung regelmäßig getestet wird.

Rollen im Krisenfall

Auch in kleinen Organisationen muss klar sein, wer welche Entscheidungen trifft. Eine Person kann mehrere Rollen übernehmen, die Rollen selbst müssen jedoch besetzt sein.

Der Ablaufplan: Die ersten 60 Minuten

Minute 0 bis 10: Erkennen und Alarm auslösen

Typische Anzeichen eines Angriffs:

• Eine Nachricht auf dem Bildschirm, die eine Lösegeldzahlung verlangt
• Dateien, die sich nicht mehr öffnen lassen oder ungewöhnliche Endungen tragen
• Server oder Freigaben, die plötzlich nicht erreichbar sind
• Gleichzeitige Störungsmeldungen mehrerer Mitarbeitender
• Massenhafte Alarme der Antivirensoftware oder deren Deaktivierung

Sofortmaßnahmen:

1. Betroffenes Gerät vom Netzwerk trennen. Das Netzwerkkabel wird gezogen, WLAN und Bluetooth werden ausgeschaltet. So wird verhindert, dass sich die Schadsoftware weiter ausbreitet.
2. Nicht sofort herunterfahren. Im Arbeitsspeicher liegen oft wertvolle Spuren, etwa Schlüsselmaterial oder Hinweise auf die Täter. Das Gerät bleibt eingeschaltet, aber isoliert. Läuft die Verschlüsselung erkennbar noch und lässt sich das Gerät nicht anders stoppen, kann ein Ausschalten im Einzelfall sinnvoll sein. Diese Entscheidung trifft die technische Leitung, möglichst nach Rücksprache mit Fachleuten.
3. Die Lösegeldnachricht fotografieren. Hierfür wird ein Mobiltelefon verwendet, nicht der betroffene Rechner. Die Nachricht enthält oft Hinweise auf die Schadsoftware-Familie.
4. Sofort die IT oder die Notfallnummer informieren. Dies erfolgt telefonisch und nicht per E-Mail, da das Mailsystem betroffen sein oder mitgelesen werden kann.
5. Nichts löschen, nichts neu installieren.

Am Ende dieser Phase sollte die Einsatzleitung feststehen und das Protokoll begonnen haben.

Minute 10 bis 20: Krisenstab bilden und Lage erfassen

In dieser Phase wird aus einer Störung ein strukturierter Einsatz.

1. Krisenstab zusammenrufen. Dies geschieht per Telefon oder über einen vorab vereinbarten, unabhängigen Kanal.
2. Protokoll führen. Festgehalten wird, wer was wann beobachtet hat, welche Systeme betroffen sind und welche Maßnahmen bereits ergriffen wurden.
3. Erstes Lagebild erstellen. Die zentralen Fragen lauten:
   • Welche Systeme, Standorte und Nutzer sind betroffen?
   • Läuft die Verschlüsselung noch?
   • Sind Server, Backups oder Cloud-Dienste betroffen?
   • Gibt es Hinweise auf Datenabfluss?
4. Annahme treffen: Zunächst wird vom Schlimmsten ausgegangen. Ist ein Gerät betroffen, kann das gesamte Netzwerk kompromittiert sein.
5. Kommunikationsregel festlegen. Die Belegschaft wird kurz informiert: Betroffene Geräte nicht benutzen, nicht ausschalten, nichts löschen, keine eigenen Reparaturversuche unternehmen und Meldungen an eine zentrale Stelle richten.

Minute 20 bis 35: Eindämmung

Nun gilt es, den Angreifern den Handlungsspielraum zu nehmen.

Netzwerk und Zugänge:

• Betroffene Netzwerksegmente werden getrennt, zum Beispiel durch Abschalten von Switch-Ports oder durch Firewall-Regeln.
• Fernzugänge wie VPN, Remote-Desktop und Zugänge von Dienstleistern werden gesperrt.
• Verbindungen zwischen Standorten werden bei Bedarf gekappt.
• Der Internetzugang kritischer Systeme wird vorübergehend unterbrochen, damit keine Daten mehr abfließen und keine Befehle der Täter ankommen.

Konten und Passwörter:

• Kompromittierte oder verdächtige Benutzerkonten werden deaktiviert.
• Privilegierte Konten (Domänenadministratoren, Dienstkonten) werden abgesichert und deren Passwörter geändert. Dies erfolgt ausschließlich von einem sauberen, nachweislich nicht betroffenen Gerät aus, da auf infizierten Systemen Passwörter mitgelesen werden könnten.
• Die Mehrfaktor-Authentifizierung wird geprüft und, wo möglich, erzwungen.

Datensicherungen schützen:

• Backup-Systeme werden sofort vom Netzwerk getrennt oder Zugriffe darauf gesperrt.

Am 21. Oktober 2026 um kurz vor 16 Uhr erschienen Sicherheitsupdates für PHP, die zwei kritische Schwachstellen schließen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stufte die Lage in einem Sicherheitshinweis mit Kritikalität 3 (Orange) ein. Betreiber sollten demnach unverzüglich handeln. In Deutschland waren zeitweise mehrere Websites nicht erreichbar, weil Betreiber ihre Server vorsorglich vom Internet trennten.

Die Lücken lassen sich auch ohne Fachwissen nachvollziehen: Ein Speicherfehler hinterlässt halbfertige Zustände, die PHP später falsch verarbeitet. Betroffen ist die Laufzeitumgebung, nicht ein einzelnes CMS. Gesichertes, Unbestätigtes und Offenes sind dabei klar zu trennen. Stand der Angaben ist der 22. Oktober 2026, Details können sich ändern.

Spätestens am 26.10.2026 wurde bekannt, dass die PHP-Sicherheitslücke erfolgreich ausgenutzt werden konnte. HackerNews berichtet, dass die Ausnutzungsversuche weiter gehen. Schnelles handeln ist also unbedingt erforderlich!

Deutsche Provider haben schnell reagiert

Anhand zweier Beispiele konnte am Tag des Problems nachvollzogen werden, dass deutsche Provider schnell reagierten.

Mittwald war fast schon übervorsichtig und schaltete vorsorglich nicht nur alle Kunden-Webseiten ab, sondern auch seine eigene (mittwald.de). Ein paar Stunden nach der Störung gab es regelmäßige Status-Updates:

Kunden mussten später die richtige PHP-Version (mit dem Patch) in ihrem Kundenkonto auswählen, sofern Mittwald dies nicht automatisch erledigt hatte.

Bei ALL-INKL gab es keinen so langen Shutdown wie bei Mittwald. Auch die ALL-INKL Webseite blieb online.

ALL-INKL Kunden mussten nichts tun. Ihre PHP-Versionen wurden automatisch hochgestuf. Bei ALL-INKL ist es sowieso einfacher als bei Mittwald: Statt der Unterunterversionsnummern (wie 8.2.35) gibt es bei ALL-INKL nur eine Unterversion (8.2) und gut ist. Das funktioniert.

Einen Tag nach dem Spuk meldete ALL-INKL Vollzug:

Die PHP-Sicherheitslücke im Überblick

Es geht um zwei Schwachstellen in der Programmiersprache PHP selbst, nicht in einem einzelnen Content-Management-System. Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Beide sind nach dem Bewertungssystem CVSS 4.0 (Common Vulnerability Scoring System, eine Skala von 0 bis 10) mit 9,2 als kritisch eingestuft. Das BSI leitet aus den Werten ab, dass für eine Ausnutzung weder eine Anmeldung noch eine Nutzerinteraktion nötig ist. Ziel ist Remote Code Execution (RCE), also die Ausführung fremden Programmcodes auf einem Server aus der Ferne.

In Berichten heißt die PHP-Sicherheitslücke auch PHP2Shell. Laut BSI soll der Name an die Ähnlichkeit mit der Schwachstelle Log4Shell erinnern. Mit der älteren WordPress-Lücke „wp2shell“ hat sie nichts zu tun.

Der zeitliche Ablauf ist durch die Meldungen des PHP-Projekts belegt. Am 20. Oktober 2026 erschien eine Vorankündigung ohne Details. Am 21. Oktober 2026 folgten um 14:00 UTC (16:00 Uhr deutscher Zeit) die Patches und die Advisories. Das BSI schreibt in seinem Sicherheitshinweis des BSI vom 21.10.2026 (Version 1.1) (das Dokument trägt die Kennung BITS-H Nr. 2026-297981-1132, die URL enthält 1032), ein Proof-of-Concept sei öffentlich, bestätigte Ausnutzungen seien noch nicht bekannt. Unbestätigte Berichte über Exploits gebe es jedoch.

Was hinter CVE-2026-109618 und CVE-2026-109619 steckt

Beide Fehler gehören zur Klasse der Speicherfehler. Vereinfacht gesagt, arbeitet PHP mit Speicherbereichen, die pro Anfrage reserviert und danach wieder freigegeben werden. Geht etwas schief, entstehen Zustände, mit denen der weitere Programmablauf nicht rechnet. Genau dort setzen die Lücken an. Die folgende Beschreibung ist bewusst vereinfacht und enthält keine Angriffsdetails.

Bei CVE-2026-109618 beschreibt das PHP-Projekt einen Abbruch bei Speichermangel (Out of Memory). Wird dieser Abbruch ausgelöst, während interne Daten einer Anfrage nur teilweise vorbereitet sind, hinterlässt er ungültige Zustände. Beim anschließenden Aufräumen der Anfrage liest PHP diese Daten und verzweigt darauf. Als Auslöser nennt das Advisory vor allem speicherintensives Verarbeiten von Formular-Uploads (multipart/form-data). Auch große Speicheranforderungen der Anwendung selbst können den Fehler auslösen.

Bei CVE-2026-109619 bleibt dagegen Zustand aus einer früheren Anfrage im sogenannten Worker stehen. Ein Worker ist ein PHP-Prozess, der nacheinander viele Anfragen bedient. Ein späterer Request kann diesen veralteten Zustand verwenden, bevor er zurückgesetzt wird. Es braucht also mindestens zwei Anfragen, die denselben Worker erreichen. Bestätigte Wege sind laut Advisory Diagnosemeldungen zu Einstellungen vor der Initialisierung, der Session-Upload-Fortschritt und bei PHP 8.5 die Funktion fatal_error_backtraces.

Am gefährlichsten ist die Lage bei Apache mit mod_php. Dort wurde ein Exploit demonstriert, bei dem eine nicht angemeldete Anfrage den Angriff auslösen kann, bevor irgendein Anwendungscode läuft. Für PHP-FPM wurde nach dem Advisory ein Teilpfad bestätigt. Was die Lücken im Einzelfall erlauben, hängt von der Umgebung ab. Die Patches setzen den Zustand vollständig zurück und beheben die Ursache.

Welche PHP-Versionen und Systeme betroffen sind

Nach der Bewertung des BSI sind alle bekannten PHP-Versionen betroffen, zurück bis mindestens PHP 5. Behoben sind die Fehler in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das PHP-Update 8.5.12 gilt dabei für den neuesten Zweig, die übrigen Nummern für die jeweils älteren, noch unterstützten Zweige.

Für die bereits abgekündigten Zweige 7.4, 8.0 und 8.1 gibt es keine regulären Updates mehr. Das PHP Security Team stellte laut Sicherheitsmeldung minimale Backports im Quellcode bereit. Ein Backport überträgt eine Korrektur in eine ältere Programmversion, ohne die Versionsnummer zu erhöhen. Linux-Distributionen und Anbieter mit verlängerter Unterstützung (LTS) liefern teils eigene Korrekturen aus. Für PHP 8.2 endet die Sicherheitsunterstützung am 31. Dezember 2026. Ein Zweig ohne Unterstützung gilt als End of Life (EOL).

Betroffen sind laut BSI und PHP-Projekt alle PHP-Installationen, die Webanfragen verarbeiten. Genannt werden PHP-FPM (ein Prozessmanager, der PHP für Webserver bereitstellt), Apache mit mod_php (PHP als Modul im Webserver), php-cgi, FrankenPHP und LiteSpeed. Die Aussagen sind nicht ganz einheitlich. Die GitHub-Advisories nennen bei einigen Umgebungen nur einen vermuteten oder nicht validierten Pfad. Als sicher gilt daher nur: Wer PHP für Webseiten betreibt, sollte von einer Betroffenheit ausgehen, bis das Gegenteil geklärt ist.

Zudem betreffen die Schwachstellen die Laufzeitumgebung und keine einzelne Anwendung. Das BSI stellt klar, dass ein Update der Anwendung nicht ausreicht. Zu den auf PHP basierenden Projekten zählt das BSI beispielhaft WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense. Ein WordPress-Update allein behebt die Lücken also nicht, entscheidend ist die PHP-Version auf dem Server.

Auch Firewalls sind betroffen

Palo Alto Networks meldete in einem Update seines Advisories zu CVE-2026-109618, dass PHP2Shell aktiv gegen aus dem Internet erreichbare PAN-OS- und Panorama-Management-Interfaces ausgenutzt wird. Hotfixes erscheinen gestaffelt, einige davon am 29. und 30.10.

Dream beschreibt eine Kette aus PHP2Shell und der Linux-Rechteausweitung „Fragnesia“ (CVE-2026-46300), mit der 25 Server gerootet wurden.

CISA hat CVE-2026-46300 am 28.10. in den KEV-Katalog aufgenommen. (The Hacker News, auch Heise berichtetet).

Wie KI die Lücken fand

Belegt ist, dass KI-Werkzeuge beim Fund eine Rolle spielten. Nach Angabe des BSI waren die Unternehmen Wiz und Calif an der Entdeckung beteiligt. Die Rolle weiterer Beteiligter wie OpenAI bleibt hier offen. Calif beschreibt, dass öffentlich verfügbare Sprachmodelle als Assistenten genutzt wurden, etwa zur Suche nach Umgehungen des Speicherlimits und zur Analyse der Speicherverwaltung. Laut dem Beitrag kamen keine speziellen Testumgebungen oder nicht öffentlich verfügbare Modelle zum Einsatz. Die Autoren betonen zugleich, dass Wissen über das Zielsystem entscheidend blieb. Ein Modell finde nicht einfach „alle Fehler“ durch einen einfachen Auftrag. Calif verweist auf einen Speicherlimit-Fehler in PHP aus dem Jahr 2004 als Vorgeschichte.

Auch Wiz berichtet von einer KI-gestützten Entdeckung. Frontier-Modelle hätten die Hürde gesenkt, Fehler zu einem funktionierenden Exploit zu verketten und diesen an verschiedene PHP-Versionen und Konfigurationen anzupassen. Welche Modelle genau eingesetzt wurden und wie groß der Anteil von Mensch und Maschine war, lässt sich anhand der Herstellerangaben nicht unabhängig prüfen. Beide Beiträge stammen von Beteiligten und sind zugleich Eigenwerbung. Die Angaben sind als Selbstauskunft zu lesen.

Die Zeitangaben zur Entdeckung weichen voneinander ab. Calif nennt den 1. August 2026 für die ersten Funde und den 11. August 2026 für die erste Meldung an PHP. Wiz nennt den 19. August 2026 für die erste entdeckte Lücke und den 24. August 2026 für die Meldung an das PHP-Sicherheitsteam. Beide Darstellungen können nebeneinander stehen, weil mehrere Gruppen unabhängig arbeiteten. Welche Gruppe zuerst meldete, ist anhand der Quellen nicht abschließend zu klären.

Eine Einordnung des Autors: Dieselben Werkzeuge stehen grundsätzlich auch Angreifern zur Verfügung. Das ist eine Bewertung, kein Beleg dafür, dass sie in diesem Fall für Angriffe genutzt wurden.

Patch-Diffing: Wie aus einem Security-Fix ein Exploit werden kann

Ein mittelständisches Unternehmen lässt seine Website seit Jahren nicht prüfen, weil ein vollständiger Pentest im Budget nie Priorität hatte und "irgendwann mal" gemacht werden sollte. Genau in dieser Lücke sitzt dann ein Angreifer im Content-Management-System, weil eine veraltete Softwareversion und eine offene Konfigurationsdatei zusammen ausgereicht haben. Kein komplexer Angriff, keine raffinierte Kette – nur simple, längst bekannte Schwachstellen, die ein spezialisierter Scan in wenigen Minuten gefunden hätte. Genau dieses Muster zeigt, warum die meisten Unternehmen zuerst einen Security-Check brauchen und erst danach über einen Pentest nachdenken sollten, nicht umgekehrt.

Was ein automatisierter Scan wirklich leistet

Ein Vulnerability Scanner arbeitet nach einem klaren Prinzip: Er gleicht Systeme, Server und Anwendungen automatisiert gegen bekannte Schwachstellen-Datenbanken wie die NVD ab und meldet Treffer anhand von Signaturen. Dieser Prozess läuft in Minuten bis Stunden, lässt sich beliebig oft wiederholen und deckt dabei die gesamte Angriffsfläche eines Unternehmens ab, nicht nur ausgewählte Systeme. Genau darin liegt die Stärke: Vulnerability Scanning schafft schnell und wiederholbar Sichtbarkeit darüber, wo der eigene Bestand an Servern, Diensten und Software steht.

Für die laufende Betriebssicherheit ist das unverzichtbar. Neue Schwachstellen werden täglich veröffentlicht, Software-Stände verändern sich, Konfigurationen driften. Ein Scan liefert hier die Breite: Er prüft nicht nur ein System sehr genau, sondern alle Systeme zumindest oberflächlich, und wird damit zum sinnvollen Ausgangspunkt, um den eigenen Sicherheitsstatus überhaupt einschätzen zu können.

Wo generische Scans an ihre Grenzen stoßen

Ein allgemeiner, sehr breit angelegter Scan hat allerdings eine Kehrseite. Weil er möglichst viele unterschiedliche Systeme gleichzeitig abdecken will, bleibt die Prüftiefe pro System begrenzt. Fehlalarme sind relativ häufig, also gemeldete Probleme, die bei genauerer Prüfung gar nicht real ausnutzbar sind. Teams verbringen dadurch Zeit mit der Abarbeitung von Meldungen, die sich am Ende als harmlos herausstellen. Ein solcher Scanner kann außerdem eine Schwachstelle identifizieren, aber nicht immer bewerten, ob sie im konkreten Kontext tatsächlich ausnutzbar ist.

Für Websites und Webanwendungen ist das ein entscheidender Punkt: Ein generischer, auf alle möglichen IT-Systeme ausgelegter Scan ist selten so tief spezialisiert, wie es die Web-Präsenz eines Unternehmens eigentlich erfordern würde. Genau hier setzen spezialisierte Security Scans an.

Spezialisierte Security Scans: hoher Automatisierungsgrad, verlässliche Ergebnisse

Neben allgemeinen Vulnerability Scannern hat sich eine eigene Kategorie spezialisierter Scans etabliert, die sich gezielt auf einen bestimmten Bereich konzentrieren, etwa auf die Web-Präsenz eines Unternehmens. Weil sich der Prüfumfang hier klar eingrenzen lässt, können solche spezialisierten Scanner einen sehr hohen Automatisierungsgrad erreichen, teils nahezu vollständig, und dabei gleichzeitig sehr zuverlässige, belastbare Ergebnisse liefern. Der enge Fokus ist also kein Nachteil, sondern die Voraussetzung dafür, dass Breite und Tiefe hier deutlich näher zusammenrücken als bei einem allgemeinen Scan.

Ein gutes Beispiel für einen leistungsstarken Check, den nur ein spezialisierter Scanner vollziehen kann: Die Prüfung der security.txt Datei. Der Webadmin wird durch detaillierte Hilfestellungen und Beispiele unterstützt; der Entscheider erhält in einem gesonderte, kompakten Report eine Statistik der erfüllten Punkte (grün), der Warnungen (gelb) und der Fehler (rot). Das könnte ein generischer Scanner so nicht leisten – und dies war nur eines von vielen Beispielen.

Ein Web Security Check etwa deckt typischerweise die gesamte Angriffsfläche einer Website in einem Durchgang ab: im Frontend werden Formulare, eingebundenes JavaScript und mögliche XSS-Schwachstellen geprüft, auf Netzwerkebene SSL-Konfiguration und die sicherheitsrelevante Content Security Policy (CSP), und im Backend werden der Web Server und Softwareversionen ermittelt und gegen bekannte CVE-Schwachstellen abgeglichen. Häufig kommen ergänzende Prüfungen zu Barrierefreiheit oder SEO-Empfehlungen hinzu. Diese All-in-One-Ausrichtung ergibt gerade deshalb Sinn, weil der Fokus konsequent auf der Web-Präsenz liegt, statt wie bei einem generischen Scan die komplette, heterogene IT-Landschaft eines Unternehmens abdecken zu müssen.

Wer die eigene Website auf diese Weise regelmäßig prüfen lässt, etwa über einen entsprechenden Website-Sicherheitscheck, bei dem auch DSGVO-bezogene Prüfungen möglich sind, bekommt mit überschaubarem Aufwand ein belastbares, kontinuierlich aktualisierbares Bild des eigenen Status quo – deutlich öfter, als es ein punktueller Pentest je leisten könnte.

Wo ein Pentest zusätzlich ansetzt

Für besonders kritische Systeme oder komplexe Angriffsflächen bleibt ein Pentest sinnvoll. Erfahrene Tester denken wie echte Angreifer und versuchen aktiv, mehrere für sich genommen unkritische Schwachstellen zu einer echten Angriffskette zu kombinieren. Diese kreative Verknüpfung einzelner Schritte zu einer Kill-Chain bleibt bislang eine Domäne, in der menschliche Tester automatisierten Systemen überlegen sind, auch gegenüber neueren KI-gestützten Testwerkzeugen. Ein anerkannter methodischer Rahmen dafür ist der OWASP Web Security Testing Guide.

Für die meisten Unternehmen ist das aber der zweite Schritt, nicht der erste: sinnvoll, wenn bereits ein solider Grundschutz besteht und einzelne, besonders sensible Systeme noch tiefer geprüft werden sollen – nicht als Ersatz für die laufende, regelmäßige Kontrolle der eigenen Web-Präsenz.

Auch Pentests haben ihre Grenzen

Ein typisches Pentest-Engagement besteht aus ein bis zwei Testern mit begrenzter Zeit, was bei komplexen, weit verzweigten Angriffsflächen kaum die nötige Tiefe und Breite gleichzeitig abdecken kann. Pentests finden zudem überwiegend nur ein- bis zweimal jährlich statt, wodurch zwischen den Terminen lange Zeitfenster entstehen, in denen neue Schwachstellen unentdeckt bleiben. Da der Testumfang vorab fest definiert wird, können ganze Bereiche der Infrastruktur komplett außen vor bleiben, einfach weil sie nicht im vereinbarten Scope lagen.

Ein Pentest ist damit eine punktuelle, aber sehr genaue Momentaufnahme, kein dauerhafter Schutzschirm. Genau das macht die kontinuierliche Absicherung durch regelmäßige Security-Checks so wichtig, gerade in den Monaten zwischen zwei Pentests.

Regulatorischer Druck sorgt für klare Taktung

2026 ist die Frage nach regelmäßigen Prüfungen längst keine rein technische Entscheidung mehr. In Deutschland verlangt die NIS-2-Umsetzung, die seit dem 6. Dezember 2025 in Kraft ist, von betroffenen Unternehmen regelmäßige Wirksamkeitstests ihrer Sicherheitsmaßnahmen. Für Finanzunternehmen schreibt die DORA-Verordnung sogenanntes Threat-Led Penetration Testing vor, und der Zahlungskartenstandard PCI DSS 4.0.1 fordert seit dem 31. März 2025 eine dokumentierte Pentest-Methodik.

Regelmäßige, gut dokumentierte Security-Checks passen sich in solche Prüfprogramme nahtlos ein: Sie liefern die kontinuierliche Nachweisbasis zwischen den selteneren, aufwendigeren Pentest-Terminen und machen so aus einer einmaligen Prüfung ein belastbares, fortlaufendes Sicherheitsprogramm.

Fazit: Der Security-Check ist der erste und wichtigste Schritt

Für die meisten Unternehmen gilt: Ein regelmäßiger, spezialisierter Security-Check deckt bereits einen Großteil der real relevanten Risiken auf der eigenen Website ab – schnell, wiederholbar und mit einem Automatisierungsgrad, der eine engmaschige Kontrolle überhaupt erst wirtschaftlich macht. Ein Pentest bleibt sinnvoll, aber als punktuelle Vertiefung für besonders kritische Systeme, nicht als Ausgangspunkt.

In der Praxis bedeutet das: Security-Checks auf der eigenen Web-Präsenz monatlich oder quartalsweise, und ein Pentest gezielt dort, wo Systeme besonders sensibel sind oder regulatorisch verlangt wird. Wer diesen ersten Schritt konsequent geht, schließt die meisten Lücken, bevor sie überhaupt zum Problem werden.

Warum eine simple Textdatei plötzlich Aufmerksamkeit bekommt

Stellen Sie sich vor, eine unabhängige Sicherheitsforscherin entdeckt zufällig eine Schwachstelle auf Ihrer Website. Sie möchte diese verantwortungsvoll melden, bevor sie in falsche Hände gerät. Doch wohin? Ein Blick ins Impressum hilft selten weiter, die allgemeine Support-Adresse ist oft der falsche Ansprechpartner, und wertvolle Zeit verstreicht, während die Lücke offen bleibt.

Genau dieses Problem löst die sogenannte security.txt. Es handelt sich um eine standardisierte, maschinenlesbare Textdatei, die auf jeder Website an einer festen, vorhersehbaren Stelle hinterlegt werden kann. Sie beantwortet in Sekunden die Frage, die im Ernstfall zählt: Wer ist zuständig, und wie erreiche ich diese Person sicher?

Was nach einer Nischen-Empfehlung für große Konzerne klingt, hat inzwischen behördliches Gewicht bekommen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) rief am 6. August 2026 gemeinsam mit der Allianz für Cyber-Sicherheit (ACS) dazu auf, die security.txt flächendeckend einzuführen. Der Anlass: Messungen im Rahmen des BSI-Projekts Cyberdome zeigten, dass gerade einmal 1,8 Prozent der deutschen Webseitenbetreiber diese Datei bislang bereitstellen, obwohl der Aufwand denkbar gering ist.

Der Zweck: ein verlässlicher Meldeweg statt Zufall

Die security.txt ist keine Erfindung des BSI, sondern ein internationaler technischer Standard, festgelegt im RFC 9116 der Internet Engineering Task Force (IETF). Der Kerngedanke ist einfach: Statt dass jede Organisation ihren eigenen, oft schwer auffindbaren Meldeweg für Sicherheitslücken erfindet, folgt sie einem gemeinsamen Format an einem gemeinsamen Ort.

Ohne diesen Standard passiert in der Praxis regelmäßig eines von drei Dingen:

• Die Meldung erreicht niemanden, weil kein offizieller Kontakt existiert.
• Sie landet bei der falschen Abteilung und verzögert sich unnötig.
• Sicherheitsforscher geben entnervt auf und veröffentlichen die Lücke öffentlich, bevor sie behoben ist – mit allen Risiken, die das für Besucher und Kunden der Website mit sich bringt.

Eine korrekt eingerichtete security.txt verhindert genau das. Sie schafft einen eindeutigen, dokumentierten Kanal für sogenannte Coordinated Vulnerability Disclosure – die koordinierte, verantwortungsvolle Offenlegung von Schwachstellen, bei der Betreiber Zeit zur Behebung bekommen, bevor Details öffentlich werden.

Was konkret in der Datei steht

Die security.txt liegt technisch immer unter dem festen Pfad https://ihre-domain.de/.well-known/security.txt und besteht aus einfachen Textzeilen. Zwei davon sind laut RFC 9116 verpflichtend:

• Contact – gibt an, wie Sicherheitsexperten Sie erreichen können, meist per E-Mail-Adresse, manchmal ergänzt um Telefonnummer oder Kontaktformular.
• Expires – ein Ablaufdatum, das signalisiert, bis wann die Angaben als aktuell gelten. Das zwingt Betreiber indirekt dazu, die Datei regelmäßig zu pflegen, statt sie einmal anzulegen und zu vergessen.

Darüber hinaus gibt es mehrere empfohlene und optionale Felder, die den Nutzen erheblich steigern können: einen Link zur eigenen Vulnerability-Disclosure-Policy, einen PGP-Schlüssel für verschlüsselte Meldungen, eine Hall-of-Fame-Seite für Sicherheitsforschende oder auch bevorzugte Sprachen für die Kommunikation. Die Datei kann zudem digital signiert werden, um ihre Echtheit zusätzlich abzusichern.

So richten Sie die Datei in wenigen Minuten ein

Die technische Umsetzung ist bewusst niedrigschwellig gehalten. Eine minimale, gültige security.txt besteht aus nur zwei Zeilen:

Contact: mailto:security@ihre-domain.de
Expires: 2027-08-25T00:00:00Z

Diese Datei speichern Sie als reine Textdatei und laden sie unter dem Pfad /.well-known/security.txt auf Ihren Webserver – bei den meisten Hosting-Umgebungen reicht dafür ein gewöhnlicher FTP- oder Datei-Manager-Zugriff. Ein eigenes Content-Management-System oder eine Programmierkenntnis ist dafür nicht erforderlich.

Wichtig ist dabei die korrekte Auslieferung durch den Webserver: Die Datei sollte als text/plain mit der Kodierung UTF-8 ausgeliefert werden. Bei den meisten Standard-Konfigurationen ist das bereits automatisch der Fall, sofern die Datei lediglich als .txt-Datei gespeichert wurde. Wer zusätzlich Wert auf Sorgfalt legt, ergänzt einen Link zur eigenen Vulnerability-Disclosure-Policy und setzt das Ablaufdatum realistisch – üblich sind sechs bis zwölf Monate in der Zukunft, damit die Datei tatsächlich regelmäßig überprüft und aktualisiert wird, statt einmal angelegt und dann vergessen zu werden.

Warum das gerade jetzt an Bedeutung gewinnt

Die security.txt ist längst nicht mehr nur eine freiwillige Fleißaufgabe. Der Cyber Resilience Act (CRA) der EU stellt verbindliche Anforderungen an den Umgang mit Schwachstellenmeldungen und wird ab Dezember 2027 vollständig verpflichtend. Bereits ab dem 11. September 2026 gelten zudem Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Wer bereits jetzt einen funktionierenden Meldeweg etabliert, verschafft sich einen komfortablen Vorsprung bei der Umsetzung dieser regulatorischen Vorgaben, statt später unter Zeitdruck nachzurüsten.

Das BSI betont in seiner Mitteilung außerdem den geringen Aufwand im Verhältnis zum Nutzen. Wer die beiden Pflichtfelder korrekt setzt und die Datei am richtigen Pfad bereitstellt, hat die wichtigsten Anforderungen bereits erfüllt – eine der niedrigschwelligsten IT-Sicherheitsmaßnahmen überhaupt, wie es in der Pressemitteilung heißt.

In der Praxis zeigt sich allerdings, dass gerade bei der Umsetzung häufig kleine, aber folgenreiche Fehler passieren: ein falscher HTTP-Content-Type, ein zu weit in der Zukunft liegendes Ablaufdatum, das die eigentliche Pflege konterkariert, oder eine Datei, die zwar existiert, aber unter dem falschen Pfad liegt und dadurch von automatisierten Prüfungen schlicht nicht gefunden wird. Genau solche Details lassen sich mit einem automatisierten Security Check zuverlässig aufdecken – der neben dem reinen Vorhandensein auch den strukturellen Aufbau der security.txt nach RFC 9116 prüft und bei jedem gefundenen Problem eine verständliche, konkrete Hilfestellung liefert, wie es korrekt aussehen sollte.

Beispiele für Hilfestellungen sind im nächsten Abschnitt gegeben. Die Hilfeseiten des eben genannten Web Security Checks sind noch umfangreicher und enthalten anschauliche Beispiele für Webmaster.

Technische Hinweise zur Umsetzung

Über die reine Feldsyntax hinaus gibt es einige technische Details, die in der Praxis häufig übersehen werden, sich aber deutlich auf die korrekte Funktion der security.txt auswirken.

Die Datei muss über das verschlüsselte Protokoll HTTPS abrufbar sein – ein Abruf über unverschlüsseltes HTTP gilt nach RFC 9116 als nicht konform, da sich der Inhalt sonst auf dem Übertragungsweg manipulieren ließe. Zusätzlich empfiehlt die Spezifikation, die Datei kompakt zu halten: Richtwerte sind eine Gesamtgröße unter 32 Kilobyte, einzelne Feldwerte unter 2.048 Zeichen und insgesamt unter 1.000 Zeilen. Das erleichtert automatisierten Auswertungswerkzeugen die zuverlässige Verarbeitung.

Wer die Datei über Apache betreibt, kann Content-Type und eine Weiterleitung vom veralteten Wurzelverzeichnis-Pfad zentral über die .htaccess-Datei steuern:

AddType text/plain .txt
Redirect 301 /security.txt /.well-known/security.txt

Damit ist sichergestellt, dass sowohl der korrekte, verbindliche Pfad unter /.well-known/ als auch ein möglicher Altpfad im Wurzelverzeichnis auf dasselbe Ziel verweisen. Existieren beide Varianten gleichzeitig mit unterschiedlichem Inhalt, gilt laut Standard stets die Version unter /.well-known/ als maßgeblich.

Ein häufiger Stolperstein: HTTP-Response-Header wie Content-Type gehören ausschließlich in die Server-Konfiguration, nicht als eigene Zeile in den Dateiinhalt selbst. Eine Zeile wie „Content-Type: text/plain; charset=utf-8" innerhalb der security.txt ist kein gültiges Feld nach RFC 9116 und wird von auswertenden Systemen schlicht ignoriert. Auch der Geltungsbereich verdient Beachtung: Eine security.txt gilt ausschließlich für exakt die Domain oder Subdomain, unter der sie abgerufen wurde – shop.ihre-domain.de benötigt bei Bedarf eine eigene Datei, unabhängig von der auf ihre-domain.de hinterlegten Version.

Wer zusätzliche Vertrauenswürdigkeit signalisieren möchte, kann die gesamte Datei per OpenPGP digital signieren. Das ist keine eigene Zeile, sondern eine kryptografische Hülle um den kompletten Inhalt, die belegt, dass die Datei tatsächlich vom Domaininhaber stammt und nicht nachträglich verändert wurde. In diesem Fall wird zusätzlich ein Canonical-Feld empfohlen, damit auch der offizielle Speicherort der Datei durch die Signatur mit abgesichert ist.

Fazit: kleiner Aufwand, spürbarer Unterschied

Die security.txt ist eines der seltenen Beispiele, bei denen wenige Minuten Arbeit einen echten Unterschied für die Sicherheit einer Website machen können. Sie kostet keine Lizenzgebühr, erfordert keine neue Infrastruktur und lässt sich mit einem einfachen Texteditor umsetzen. Gleichzeitig signalisiert sie nach außen, dass eine Organisation Sicherheitsthemen ernst nimmt und Meldungen willkommen heißt, statt sie zu erschweren.

Nur 1,8% der Domains erfüllen die Anforderung

Ist Ihre security.txt bereit für die Meldepflicht ab 11.09.2026?

Ganzen Artikel jetzt über kostenfreien Dr. DSGVO Newsletter lesen.

Weitere Extras für Abonnenten:
Viele Artikel in PDF-Form · Kompakte Kernaussagen für Beiträge · Offline-KI · Freikontingent+ für Website-Checks

Schon Abonnent? Link im Newsletter anklicken & diese Seite auffrischen.

↓

Newsletter abonnieren

]]> https://dr-dsgvo.de/security-warum-das-bsi-jetzt-eine-winzige-textdatei-fuer-jede-website-empfiehlt/feed/ 4 https://dr-dsgvo.de/websites-im-visier-was-angreifer-sehen-und-was-sie-dagegen-tun-koennen/ https://dr-dsgvo.de/websites-im-visier-was-angreifer-sehen-und-was-sie-dagegen-tun-koennen/#respond Tue, 02 Jun 2026 13:09:00 +0000 https://dr-dsgvo.de/?p=31471 Cyberkriminelle werden effizienter. Angriffe auf Websites nehmen zu. Und die meisten Betreiber merken es erst, wenn der Schaden bereits eingetreten ist. Dieser Artikel zeigt, wie Angreifer vorgehen, wo typische Schwachstellen liegen – und wie Sie Ihre Website systematisch absichern.

Die unterschätzte Bedrohungslage

Wer denkt, Cyberangriffe seien nur ein Problem für Konzerne und Behörden, irrt sich. Kleine Unternehmen, Selbstständige, Vereine – sie alle betreiben Websites und sind damit potenzielle Ziele. Und genau das wissen Angreifer.

Automatisierte Scan-Tools durchsuchen das Internet rund um die Uhr nach verwundbaren Websites. Sie erkennen, welches CMS eingesetzt wird, welche Plugins installiert sind, welche Softwareversionen laufen – und ob dazu bekannte Schwachstellen existieren. Das dauert keine Minuten, sondern Sekunden.

Laut BSI und ENISA ist die Zahl registrierter Schwachstellen in verbreiteter Software in den vergangenen Jahren kontinuierlich gestiegen. Allein für WordPress-Plugins werden regelmäßig Hunderte neue Sicherheitslücken pro Jahr dokumentiert. Die Bedrohungslage ist real, betrifft alle – und sie wächst.

Was passiert, wenn eine Website kompromittiert wird?

Die Szenarien reichen von unangenehm bis existenzbedrohend:

• Datenverlust: Kundendaten, Kontaktanfragen, interne Dokumente werden gestohlen.
• Reputationsschaden: Die eigene Website verbreitet unbemerkt Malware an Besucher.
• Blacklisting: Google und Sicherheitsdienste markieren die Website als gefährlich – der Traffic bricht ein.
• Erpressung: Ransomware verschlüsselt Inhalte, Angreifer fordern Lösegeld.
• Rechtliche Konsequenzen: Bei Datenpannen greift die DSGVO – mit empfindlichen Sanktionen.

DSGVO: Sicherheit ist rechtlich verpflichtend

Artikel 32 der DSGVO ("Sicherheit der Verarbeitung") verpflichtet alle Verantwortlichen, „geeignete technische und organisatorische Maßnahmen" zu ergreifen, um ein dem Risiko angemessenes Schutzniveau für personenbezogene Daten sicherzustellen.

Wer eine Website betreibt, auf der Nutzerdaten verarbeitet werden – sei es über ein Kontaktformular, einen Newsletter oder einen Shop – ist verpflichtet, diese Daten aktiv zu schützen. Eine Website mit bekannten, ungepatchten Schwachstellen kann als Verstoß gegen Artikel 32 gewertet werden, selbst wenn noch kein Angriff stattgefunden hat.

Dazu kommt das Thema Cookies und Tracking: Viele Websites setzen Analyse- und Werbetools ein, ohne den rechtlichen Rahmen vollständig einzuhalten. Welche Tracking-Dienste tatsächlich aktiv sind, ist oft unklar – weil sie durch eingebundene Drittanbieter-Skripte oder Plugins im Hintergrund geladen werden. Ein regelmäßiger Abgleich der aktiven Tracker mit der eigenen Datenschutzerklärung ist daher nicht nur empfehlenswert, sondern rechtlich geboten.

CVE-Schwachstellen: Was sie sind und wie man damit umgeht

CVE steht für „Common Vulnerabilities and Exposures" – eine öffentlich zugängliche Datenbank, in der bekannte Sicherheitslücken in Software katalogisiert werden. Jede Schwachstelle bekommt eine eindeutige Kennung (z. B. CVE-2024-12345) sowie eine Risikobewertung nach dem CVSS-Score (0–10).

Wo findet man CVEs?

Die wichtigsten Quellen sind:

• nvd.nist.gov – die National Vulnerability Database des amerikanischen NIST, vollständig und durchsuchbar
• cve.org – die offizielle CVE-Datenbank
• cvedetails.com – übersichtliche Suche nach Produkt, Hersteller oder Version
• WPScan Vulnerability Database – speziell für WordPress, Plugins und Themes

Wie geht man mit einem CVE um?

1. Identifizieren: Welche Software, Plugins oder Frameworks sind in welcher Version im Einsatz? Das ist häufig der schwierigste Schritt, weil viele Betreiber keinen vollständigen Überblick haben.
2. Abgleichen: Die eingesetzten Versionen mit bekannten CVEs vergleichen. Tools wie wpscan, nikto oder kommerzielle Scanner können dabei helfen.
3. Bewerten: Nicht jeder CVE ist gleich kritisch. Ein CVSS-Score über 7.0 gilt als hoch, über 9.0 als kritisch. Kontext zählt: Ist die Schwachstelle aus dem Internet ausnutzbar? Erfordert sie Authentifizierung?
4. Beheben: In den meisten Fällen durch Update der betroffenen Software. Steht kein Update bereit, können WAF-Regeln (Web Application Firewall) als temporäre Maßnahme helfen oder die betroffene Komponente deaktiviert werden.
5. Dokumentieren: Für DSGVO-Zwecke empfiehlt sich eine Nachvollziehbarkeit der getroffenen Maßnahmen.

Nebenbei: Eine in letzter Zeit häufiger gemeldete Schwachstelle betrifft das häufig eingesetzte OpenSSH. In einer aktuellen Version greift die Schwachstelle. Viele Scanner melden das. Dabei ist die Schwachstelle nur dann relevant, wenn OpenSSH speziell (außerhalb des Standards) konfiguriert ist.

Ein guter Security Report enthält nicht nur eine Problembeschreibung, sondern auch eine Diagnose- und Abhilfe-Anleitung. So können Webmaster feststellen, ob sie tatsächlich betroffen sind oder ein Fehlalarm vorliegt.

Typische Schwachstellen auf Websites – und wie man sie erkennt

DNS-Fehlkonfigurationen

Die DNS-Konfiguration einer Domain ist häufig mangelhaft abgesichert. Fehlende oder fehlerhafte Einträge für SPF, DKIM und DMARC ermöglichen E-Mail-Spoofing – also das Versenden gefälschter E-Mails, die scheinbar von Ihrer Domain stammen.

Selbst prüfen: Tools wie MXToolbox oder mail-tester.com zeigen den Status Ihrer E-Mail-Sicherheitskonfiguration kostenlos an.

Veraltete Software und Plugins

Das häufigste Einfallstor – insbesondere bei WordPress. Jedes installierte Plugin, das nicht regelmäßig aktualisiert wird, ist ein potenzielles Risiko. Besonders problematisch: deaktivierte, aber nicht gelöschte Plugins. Sie sind weiterhin auf dem Server vorhanden und angreifbar.

Maßnahmen:

• Automatische Updates für WordPress-Core und vertrauenswürdige Plugins aktivieren
• Nicht benötigte Plugins und Themes vollständig entfernen
• Plugins aus unbekannten Quellen grundsätzlich vermeiden

Unsichere HTTP-Header

Viele Web-Server senden standardmäßig zu viele Informationen in ihren HTTP-Antwort-Headern – Softwareversion, Framework, Serverbetriebssystem. Gleichzeitig fehlen sicherheitskritische Header, die Angriffe wie Clickjacking oder Code-Injection erschweren würden.

Wichtige Sicherheits-Header, die gesetzt sein sollten:

• Content-Security-Policy – regelt, welche Ressourcen geladen werden dürfen
• Strict-Transport-Security – erzwingt HTTPS-Verbindungen
• X-Frame-Options – verhindert Einbettung der Seite in Frames (Clickjacking)
• X-Content-Type-Options – verhindert MIME-Type-Sniffing
• Referrer-Policy – kontrolliert, welche Referrer-Informationen weitergegeben werden

Selbst prüfen: securityheaders.com analysiert Ihre Website kostenlos und gibt eine Bewertung.

Cross-Site Scripting (XSS)

XSS zählt zu den häufigsten Angriffsmethoden. Dabei wird schadhafter JavaScript-Code in eine Website eingeschleust, der im Browser der Besucher ausgeführt wird – etwa um Session-Daten zu stehlen oder Nutzer auf gefälschte Seiten weiterzuleiten.

Besonders anfällig sind Stellen, an denen Nutzereingaben ungefiltert in die Seite zurückgegeben werden: Suchfelder, Kommentarbereiche, Kontaktformulare. Eine DOM-Analyse zeigt, welche Stellen im Seitenaufbau potenziell verwundbar sind.

Grundlegende Gegenmaßnahmen:

• Alle Nutzereingaben serverseitig validieren und escapen
• Content-Security-Policy konsequent einsetzen
• Keine unsicheren JavaScript-Funktionen wie innerHTML mit unkontrollierten Daten verwenden

Unsichere Formulare

Kontaktformulare sind interaktive Schnittstellen zwischen Besucher und Server – und deshalb ein beliebtes Angriffsziel. Typische Schwachstellen sind fehlende Eingabevalidierung, anfällige Form-Handler oder das Fehlen von CSRF-Tokens, die Cross-Site-Request-Forgery verhindern.

Checkliste für sichere Formulare:

• Eingaben werden serverseitig geprüft (nicht nur clientseitig per JavaScript)
• CSRF-Schutz ist implementiert
• Das Formular ist gegen Spam-Bots gesichert (z. B. Honeypot-Feld statt CAPTCHA)
• Fehlermeldungen geben keine Systeminformationen preis

IP-Reputation und Abuse-Datenbanken

Befindet sich die IP-Adresse Ihrer Website auf einer Blacklist – etwa weil ein früherer Hoster sie für Spam genutzt hat – kann das Auswirkungen auf E-Mail-Zustellbarkeit, Reputation und sogar Rankings haben. Prüfen lässt sich das über Dienste wie AbuseIPDB oder MXToolbox Blacklist Check.

Barrierefreiheit: Rechtlich unterschätzt, technisch lösbar

Ab 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) viele Unternehmen dazu, ihre digitalen Angebote barrierefrei zu gestalten. Was das konkret bedeutet, ist vielen Betreibern noch unklar.

Praktisch geht es um Dinge wie ausreichende Farbkontraste (für Menschen mit Seheinschränkungen), korrekte Alternativtexte für Bilder, Tastaturnavigation und eine sinnvolle Dokumentstruktur. All das ist mit Werkzeugen prüfbar – und in den meisten Fällen mit überschaubarem Aufwand behebbar.

Einstiegspunkt: Das WAVE Web Accessibility Tool liefert eine erste kostenlose Auswertung.

Was eine systematische Prüfung leistet

Einzelne Tools und manuelle Prüfungen decken Teilbereiche ab. Was viele Betreiber jedoch nicht haben, ist ein strukturierter Gesamtüberblick: Welche Software läuft in welcher Version? Welche CVEs sind relevant? Wo sind HTTP-Header fehlerhaft konfiguriert? Welche Tracker sind aktiv?

Ein rigoroser Security Check bringt alle diese Bereiche zusammen – und liefert keine rohen Daten, sondern einen aufbereiteten Bericht mit Diagnosen, Risikobewertungen und konkreten Handlungsschritten. Für wen das Selbst-Prüfen zu aufwendig ist oder wer sichergehen möchte, dass kein Bereich übersehen wird, ist ein professioneller Audit sinnvoll.

Fazit: Sicherheit ist ein Prozess, kein Zustand

Eine Website ist kein statisches Objekt. Software wird aktualisiert – oder eben nicht. Neue Schwachstellen werden entdeckt. Angreifer passen ihre Methoden an.

Ganzen Artikel jetzt über kostenfreien Dr. DSGVO Newsletter lesen.

Weitere Extras für Abonnenten:
Viele Artikel in PDF-Form · Kompakte Kernaussagen für Beiträge · Offline-KI · Freikontingent+ für Website-Checks

Schon Abonnent? Link im Newsletter anklicken & diese Seite auffrischen.

↓

Newsletter abonnieren

]]> https://dr-dsgvo.de/websites-im-visier-was-angreifer-sehen-und-was-sie-dagegen-tun-koennen/feed/ 0 https://dr-dsgvo.de/umfrage-ki-dsgvo/ Thu, 23 Apr 2026 13:44:13 +0000 https://dr-dsgvo.de/?page_id=31087 Seit einigen Jahren werden auf Dr. DSGVO Beiträge zum digitalen Datenschutz, zu Datensicherheit und seit ein paar Jahren auch zu souveräner (sicherer) und optimierter Künstlicher Intelligenz veröffentlicht. Mit einer einfachen Umfrage können Sie in weniger als einer Minute mitteilen, was Sie bewegt und interessiert.

Themen, die Sie interessieren?

Welche Themen zu KI oder digitalem Datenschutz sollten auf Dr. DSGVO in einem Beitrag aufgegriffen werden?

Hinweis: Nicht alle Fragen müssen beantwortet werden. Sie können einzelne Fragen überspringen.

Ihre Meinung zählt!

Bestimmen Sie die Themen mit, die auf Dr. DSGVO behandelt werden. Die Umfrage-Ergebnisse werden regelmäßig ausgewertet.

1. Welche Themen zu KI interessieren Sie?

Beispielsweise: Souveräne KI für ..., bestimmter Anwendungsfall (welcher?), Kosten für Betrieb von Open-Source KI, ... Je konkreter, desto besser. Gerne Stichpunkte.

2. Welche Themen zum digitalen Datenschutz interessieren Sie?

Beispielsweise: Digitale Gesundheitsakte, Web Analytics, Datenschutzfreundliche Lösung für Problem X, ...

3. Sind Sie Abonnent des Dr. DSGVO Newsletters?

Ja Nein

Bitte beantworten Sie mindestens eine Frage, bevor Sie das Formular absenden.

Ihre Stimme zählt

Was bewegt Sie rund um KI und Datenschutz?

Dr. DSGVO möchte die Themen aufgreifen, die Sie wirklich beschäftigen. Zur Orientierung: Das sind die Bereiche, aus denen Ihre Antworten stammen können.

Künstliche Intelligenz

Von der EU-KI-Verordnung über automatisierte Entscheidungen bis hin zu Deepfakes und Haftungsfragen – KI verändert Recht und Alltag rasant.

EU AI Act ChatGPT & DSGVO Automatisierung Gesichtserkennung Haftung

Digitaler Datenschutz

Cookies, Datenpannen, Betroffenenrechte oder internationale Datentransfers – der digitale Datenschutz bleibt ein vielschichtiges und sich ständig wandelndes Thema.

Cookies & Tracking DSGVO-Grundlagen Datenpannen Drittlandtransfers Betroffenenrechte

---

Kein Thema dabei? Kein Problem – tragen Sie einfach Ihr eigenes ein. Die besten Beiträge entstehen aus echten Fragen aus der Praxis.

Diese Umfrage wurde mit einem eigenen WordPress-Plugin erstellt. Die Datenverarbeitung findet ausschließlich lokal statt. Die Auswertung erfolgt über ein selbst entwickeltes Dashboard.

Zur Inspiration, finden Sie häufige Fragen & Antworten zur KI (FAQ).

KI-Beratung, KI-Lösungen

Umfassende Beratung (fachlich, rechtlich, technisch):

Leistungsangebot:

• Erstberatung inkl. Machbarkeitsaussagen
• Schulungen und Workshops für Führungskräfte, Berufsgeheimnisträger, Angestellte, Entwickler
• KI-Lösungen mit und ohne ChatGPT/Azure. Cloud oder eigener KI-Server

Ihre Anfrage

Oder Mail an ki@dr-dsgvo.de

]]>