Am Sonntag, dem 25. Oktober 2026, hat Microsoft außerplanmäßige Sicherheitsupdates für .NET 8, 9, 10 und den dritten Release Candidate von .NET 11 veröffentlicht. Anlass ist CVE-2026-111497, eine Schwachstelle im Brotli-Decoder, die unter den Namen Node2Shell, HTTP2Shell und Broccoli2Shell seit einer Woche durch die Fachpresse geht. Ein Angreifer kann mit einem präparierten, Brotli-komprimierten Datenstrom den Speicher des entpackenden Prozesses beschädigen, Speicherinhalte auslesen, den Prozess abstürzen lassen oder im schlimmsten Fall eigenen Code ausführen.

Das klingt nach einem Fall für „sofort alles patchen”. Ganz so einfach ist es nicht, und das ist der eigentliche Grund für diesen Artikel. Die Lücke steckt in einer Bibliothek von Google, die in Dutzenden Produkten mitgeliefert wird, und ob eine konkrete .NET-Anwendung angreifbar ist, hängt von ihrer Konfiguration ab. Ich gehe durch, was die Lücke ist, warum sie erst jetzt Schlagzeilen macht, obwohl der Fix seit Februar existiert, welche .NET-Versionen Sie brauchen und was Sie tun können, wenn Sie nicht sofort updaten können.

Was CVE-2026-111497 technisch ist

Brotli ist ein verlustfreies Kompressionsverfahren von Google, das vor allem im Web eingesetzt wird: Browser und Server tauschen HTML, CSS und JavaScript mit Content-Encoding: br aus. Die Referenzimplementierung in C ist die Grundlage für fast alle Brotli-Decoder in Umlauf, egal ob in Node.js, Python, Bun, Envoy oder eben in .NET.

Der Fehler sitzt in der Funktion DecodeBlockTypeAndLength() in c/dec/decode.c. Sie verarbeitet die Stellen, an denen ein Brotli-Strom den Blocktyp wechselt. In den betroffenen Versionen gibt die Funktion nur „wahr” oder „falsch” zurück, und „falsch” kann zweierlei heißen: der Strom ist kaputt, oder es fehlen noch Eingabedaten. Der Aufrufer kann das nicht unterscheiden, und im schnellen Decodierpfad wird der Rückgabewert ohnehin ignoriert. Ein präparierter Strom erklärt einen einzigen Blocktyp, lässt dessen Länge auf null laufen und erzwingt so einen Wechsel, der nicht gelingen kann. Der Decoder arbeitet dann mit veraltetem Zustand weiter und schreibt über einen kleinen internen Puffer hinaus. Das Node.js-Advisory vom 21. Oktober beschreibt es so: Ein ungültiger Blockwechsel wurde als vorübergehender Bedarf an mehr Eingabe gemeldet statt als dauerhafter Formatfehler, und der Streaming-Decoder hängte weiter Bytes an einen acht Byte großen internen Puffer an.

Der Fix im Brotli-Repository lässt die Funktion einen echten Fehlercode zurückgeben, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH mit dem Wert -17, und bricht auf beiden Pfaden ab. Betroffen sind laut CVE-Record die Brotli-Versionen 1.0.3 bis 1.2.0; behoben ist das Problem in 1.0.10, 1.1.1 und 1.2.1, je nach Entwicklungszweig.

Gefunden haben die Lücke Khai Tran und Sylvie Mayer von OpenAI Codex Security. Dass sich daraus mehr als ein Absturz machen lässt, hat das Red Team von Imperva gezeigt: Ron Masas beschreibt in seiner Analyse vom 22. Oktober, wie sein Proof of Concept auf dem offiziellen Node.js-24.22.0-Image für Linux arm64 mitgelieferten Code ausführte, sowohl über eine komprimierte HTTP-Antwort, die fetch() entpackt, als auch über einen Brotli-komprimierten Request-Body in Express 5 mit body-parser. Die Ausführung klappte nicht bei jedem Versuch, aber sie klappte. Auf 24.22.1 wurde dieselbe Eingabe abgewiesen.

Warum die Lücke seit Februar bekannt war

Das ist der Teil, der mich an der Geschichte ärgert. Der CVE-Record von Google nennt als datePublic den 27. Februar 2026. Die Ursache wurde damals im Brotli-Quellcode korrigiert. Nur hat das niemand als Sicherheitskorrektur behandelt, und deshalb gab es bis Oktober kein Release, das den Fix enthielt. So beschreibt es Aikido Security in seiner Zeitleiste, und Upwind kommt in seiner Analyse zum gleichen Befund.

Acht Monate lang lag ein Fix für eine Lücke, die Remote Code Execution ermöglicht, offen in einem öffentlichen Repository, ohne dass irgendjemand ein Paket gebaut hätte. Wer wollte, konnte den Commit lesen. Erst als Node.js am 21. Oktober ein Advisory samt Fixes veröffentlichte, kam die Kette in Gang: Am 22. Oktober der CVE-Record und die Python-Pakete, am 23. die Bibliothek selbst in Version 1.2.1 sowie Bun, Envoy und Istio, am 24. die Java-Bindings und Amazon Linux, am 25. Microsoft mit .NET, am 26. Debian und Alpine. Ubuntu, SUSE und die regulären Red-Hat-Repositories hatten zum Stand 26. Oktober noch keinen Fix.

Die Grafik zeigt, warum sich der Name so oft geändert hat. „Node2Shell” war der erste Name, weil Node.js zuerst patchte. „HTTP2Shell” kam am 23. Oktober auf, als klar wurde, dass jede Software betroffen ist, die Brotli über HTTP entpackt; mit dem Protokoll HTTP/2 hat die Lücke nichts zu tun. „Broccoli2Shell” ist der Name, den Wiz Research verwendet. Gemeint ist immer dieselbe CVE.

Fairerweise: Microsoft hat vergleichsweise schnell reagiert. Vier Tage nach dem Node.js-Advisory einen Out-of-Band-Patch für vier Produktlinien zu liefern, an einem Sonntag, ist nicht selbstverständlich. Dass der Patch nötig war, liegt nicht an Microsoft, sondern daran, dass .NET wie fast jedes andere Produkt seine eigene Kopie des Brotli-Decoders mitbringt.

Welche .NET-Anwendungen angreifbar sind

Hier wird es für die Praxis wichtig. Das Microsoft-Advisory sagt ausdrücklich: Eine Anwendung ist nicht angreifbar, nur weil ein betroffenes .NET-Paket installiert ist. Angreifbar ist sie, wenn sie von Angreifern kontrollierte Brotli-Daten über einen von drei Wegen entpackt:

1. ASP.NET Core Request Decompression ist aktiviert und akzeptiert br. Dann entpackt der Server eingehende Request-Bodies, bevor irgendeine Authentifizierung greift.
2. HttpClientHandler.AutomaticDecompression oder SocketsHttpHandler.AutomaticDecompression enthält DecompressionMethods.Brotli oder DecompressionMethods.All. Dann entpackt der Client Antworten fremder Server. Ein bösartiger Server kann also eine Anwendung angreifen, die ihn nur abfragt, etwa einen Webhook-Empfänger, einen Link-Preview-Dienst oder einen Importer, der URLs lädt.
3. Die Anwendung ruft BrotliStream oder BrotliDecoder aus System.IO.Compression direkt auf nicht vertrauenswürdige Daten auf, zum Beispiel beim Entpacken hochgeladener Dateien.

Keiner dieser Wege ist in einer frischen .NET- oder ASP.NET-Core-Installation aktiv. Request Decompression muss man explizit registrieren, automatische Antwort-Dekompression explizit konfigurieren. Das .NET Framework ist nicht betroffen. Diese Einschränkung erklärt auch, warum Microsoft die Lücke anders bewertet als der CVE-Record.

CVSS 8.1 oder 9.2, hoch oder kritisch?

Im CVE-Record, den Google als vergebende Stelle gepflegt hat, steht ein CVSS-4.0-Wert von 9.2, Einstufung „Critical”. Microsoft bewertet dieselbe Lücke in seinem Advisory nach CVSS 3.1 mit 8.1 und Schweregrad „High”, mit dem Vektor CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C. Der Unterschied liegt in der Angriffskomplexität: Microsoft setzt sie auf „hoch” (AC:H), was zu der Einschränkung passt, dass die Anwendung erst eine der genannten Konfigurationen haben muss. BleepingComputer schreibt in seiner Meldung vom 26. Oktober von einer kritischen Lücke und bezieht sich damit auf den CVE-Record, nicht auf die Microsoft-Einstufung.

Beide Zahlen sind richtig, sie beantworten nur verschiedene Fragen. 9.2 beschreibt die Bibliothek: Wer sie auf fremde Daten loslässt, hat ein kritisches Problem. 8.1 beschreibt .NET als Produkt, in dem diese Bibliothek standardmäßig nicht auf fremde Daten losgelassen wird. Für Ihre Anwendung zählt, welche der beiden Beschreibungen zutrifft.

Die Updates: Versionen und was Microsoft gleich mitrepariert

Die fehlerbereinigten Versionen laut .NET-Blog und Advisory:

Wer .NET 11 RC2 einsetzt, muss auf RC3 wechseln; RC2 bekommt den Fix nicht. .NET 7 ist laut Aikido ebenfalls betroffen, aber seit Mai 2024 ohne Support und bekommt deshalb nichts mehr. Für .NET 8 und 9 ist das Update übrigens eines der letzten: Beide Linien laufen laut Microsofts Support-Tabelle am 10. November 2026 aus, also in zwei Wochen. .NET 10 als LTS-Version ist bis zum 14. November 2028 versorgt.

Im selben Paket behebt Microsoft CVE-2026-114148, falsche Besitzrechte in den Linux-Tarballs von .NET, über die ein lokaler Angreifer Dateien ändern und Rechte ausweiten könnte. Bei .NET 10 und 11 betrifft das nur Source-Build-Tarballs, bei .NET 8 und 9 auch die ASP.NET-Core-Tarballs für normale Nutzer. Und dann ist da noch ein Satz im Blogbeitrag, der mir aufgefallen ist: Microsoft veröffentlicht die Advisories für CVE-2026-70197 (Speicherfehler in SocketAsyncEventArgs) und CVE-2026-102870 (Blazor-WebAssembly-Debugger) neu, weil das Update vom 13. Oktober diese beiden Lücken nicht vollständig geschlossen hat. Erst der jetzige Patch liefert die kompletten Fixes.

Das passt in ein Muster, das ich auf diesem Blog öfter beschreibe: Ein Patch-Tuesday-Update, das zwei Sicherheitslücken nur halb schließt, ist kein Einzelfall mehr. Ich rate seit einiger Zeit dazu, Windows-Updates einen Monat versetzt einzuspielen, weil die Qualität der Erstauslieferung das nicht mehr hergibt. Für diesen .NET-Patch gilt die Empfehlung allerdings nicht, und zwar aus zwei Gründen: Es ist ein Runtime-Update, kein kumulatives Windows-Update mit Nebenwirkungen auf das ganze System, und es gibt bereits funktionierende Exploits.

Ausnutzung: Proof of Concept ja, Angriffe in freier Wildbahn nein

Nach Angaben von BleepingComputer sind Proof-of-Concept-Exploits auf GitHub veröffentlicht. Imperva hat seinen Exploit in einem Video vorgeführt und beschrieben, dass er auf einem unveränderten Node.js-Build funktioniert. Berichte über Angriffe in freier Wildbahn gab es zum Stand 26. Oktober nicht; Upwind merkt an, dass die Lücke auch nicht im KEV-Katalog der CISA steht.

Zwei Dinge sollten Sie trotzdem einpreisen. Erstens: Wiz Research gibt an, dass laut eigenen Daten 91 Prozent der von Wiz beobachteten Cloud-Umgebungen Ressourcen mit dieser Lücke enthalten. Die Zahl stammt von einem Anbieter, der Scanner verkauft, und ich kann sie nicht nachprüfen, aber die Größenordnung ist plausibel, wenn man bedenkt, wie viele Container irgendeine Node.js- oder Python-Komponente mitbringen. Zweitens: Um die Lücke hat sich bereits ein Rattenschwanz an Trittbrettfahrern gebildet. Brandefense warnt in seiner Übersicht vor angeblichen Prüf-Tools, Exploit-Verkäufen und einem Krypto-Token namens „$HTTP2SHELL”, der mit der Lücke nichts zu tun hat. Wer jetzt nach Scannern sucht, sollte nur Quellen vertrauen, die er auch sonst nutzt.

Was Sie jetzt prüfen sollten

Wenn Sie .NET-Anwendungen betreiben oder entwickeln, ist die Reihenfolge aus meiner Sicht diese.

Zuerst klären, ob Brotli überhaupt entpackt wird. Suchen Sie im Code nach AddRequestDecompression, AutomaticDecompression, DecompressionMethods.Brotli, DecompressionMethods.All, BrotliStream und BrotliDecoder. Finden Sie nichts, ist die Anwendung nach Microsofts Beschreibung nicht angreifbar, und das Update kann den normalen Weg gehen. Finden Sie etwas, ist die Anwendung dran.

Dann prüfen, welche Runtime tatsächlich läuft. dotnet --list-runtimes zeigt die installierten Shared Runtimes auf einem Host. Framework-abhängige Anwendungen nutzen nach Installation der neuen Runtime und einem Neustart automatisch die fehlerbereinigte Version; auf Windows kommt das Runtime-Update laut Microsofts Support-Seite auch über Microsoft Update. Selbständige Anwendungen (self-contained) bringen ihre eigene Runtime mit und müssen mit dem aktualisierten SDK neu gebaut und ausgerollt werden. Dasselbe gilt für Container-Images und für NativeAOT-Anwendungen, bei denen der Decoder in die ausführbare Datei eingebunden ist. Ein Runtime-Update auf dem Host hilft diesen Anwendungen nicht. Das ist der Punkt, an dem Inventarlisten lügen: Ein Server kann 8.0.33 melden und trotzdem fünf Dienste mit eingebautem altem Decoder betreiben.

Drittens, falls das Update nicht sofort geht: Brotli abschalten, aber nur dort, wo es schon aktiv ist. Microsoft warnt im Advisory ausdrücklich davor, AddRequestDecompression oder AutomaticDecompression neu einzuführen, nur um Brotli dann auszuschließen, weil das Aktivieren der Dekompression eigene Denial-of-Service-Risiken mitbringt. Wer Request Decompression bereits nutzt, entfernt den br-Provider:

builder.Services.AddRequestDecompression(options =>
{
    options.DecompressionProviders.Remove("br");
});

Wer den HttpClient bereits mit automatischer Dekompression betreibt, beschränkt die Flags auf gzip und deflate:

var handler = new HttpClientHandler
{
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
};

Alternativ lässt sich Content-Encoding: br am Reverse Proxy oder an der Firewall abweisen. Das deckt aber nur eingehende Anfragen ab. Für den Fall, dass Ihre Anwendung fremde Server abfragt, hilft das nicht, und das Entfernen von br aus dem Accept-Encoding-Header hilft ebenfalls nicht, weil ein bösartiger Server trotzdem Brotli senden kann und viele Clients den Decoder nach dem Antwort-Header auswählen.

Und viertens der Blick über .NET hinaus. Die gleiche Lücke steckt in Node.js, Python-Paketen, Bun, curl-Builds mit Brotli, Envoy, Istio und in der libbrotli vieler Linux-Distributionen. Wer einen Reverse Proxy, eine Monitoring-Lösung, ein Ticketsystem oder eine Fachanwendung von Drittherstellern betreibt, hat vermutlich mehrere Kopien des Decoders im Haus, ohne es zu wissen. Zumindest eine Entwarnung gibt es: Apaches mod_brotli komprimiert nur und entpackt nicht, läuft also nicht in den anfälligen Code.

Fazit

CVE-2026-111497 ist eine Bibliotheks-Lücke, die erst durch das Node.js-Advisory vom 21. Oktober zu einem Ereignis wurde, obwohl der Fix seit Februar im Quellcode lag. Für .NET hat Microsoft am 25. Oktober geliefert, mit den Versionen 8.0.33, 9.0.22, 10.0.14 und 11 RC3, und dabei zwei halb geschlossene Lücken vom Oktober-Patchday gleich mit nachgebessert. Angreifbar sind nur Anwendungen, die Brotli-Daten aus fremder Hand entpacken, dann aber ohne Authentifizierung und in beide Richtungen.

Mein Vorschlag für heute Abend: Greppen Sie Ihre .NET-Projekte nach den sechs Bezeichnern aus dem Praxisabschnitt. Was Treffer hat, wird diese Woche neu gebaut und ausgerollt. Was keine hat, bekommt das Update im normalen Rhythmus. Und wer noch auf .NET 8 oder 9 sitzt, hat mit dem 10. November ohnehin einen Termin, der nicht wegen Brotli näher rückt.

Quellen:

• Microsoft / dotnet/announcements: Microsoft Security Advisory CVE-2026-111497 – .NET Brotli Decoder Out-of-bounds Write Vulnerability (25.10.2026)
• Microsoft .NET Blog: .NET October 2026 Out-of-Band Security Updates (25.10.2026)
• Microsoft: .NET and .NET Core Support Policy (Stand 25.10.2026)
• Node.js: Wednesday, October 21, 2026 Security Releases (21.10.2026)
• CVE Program / Google: CVE-2026-111497 Record (22.10.2026)
• GitHub Advisory Database: GHSA-9v8h-qqgm-4m35 / CVE-2026-111497 (22.10.2026)
• Google Brotli: Commit 0ed4268 – Fix für den Blockwechsel-Fehler
• Imperva: Node2Shell – From Brotli Data to Remote Code Execution (22.10.2026)
• Wiz Research: Broccoli2Shell – Everything You Need To Know About The Critical Brotli Decoder Vulnerability (25.10.2026)
• Aikido Security: Node2Shell evolves to HTTP2Shell (23.10.2026, Stand 26.10.2026)
• Upwind: HTTP2Shell (CVE-2026-111497) – one Brotli bug, RCE across the HTTP stack (24.10.2026)
• Brandefense: HTTP2Shell – One Brotli Flaw, Many Stacks and Their Fixes (Oktober 2026)
• BleepingComputer: Microsoft releases emergency .NET patches for critical Brotli flaw (26.10.2026)

Seit dem 22. Oktober hat der Monat einen Namen: „Black October”. Ein X-Account hatte zehn Sicherheitsvorfälle aus 48 Stunden aufgelistet, Florian Roth zog mit einer eigenen Liste nach, Günter Born griff den Begriff auf Borncity auf. Wer in dieser Woche einen PHP-Server, einen Exchange-Server, eine Fortinet-Firewall oder ein Node.js-Backend betreibt, hat vermutlich wenig geschlafen. Und wer nicht jeden Tag Security-Nachrichten liest, hat inzwischen den Überblick verloren, was davon ihn betrifft.

Dieser Artikel liefert diesen Überblick. Er fasst die Sicherheitsvorfälle und Sicherheitslücken des Oktobers 2026 nach Kategorien zusammen, mit CVE-Nummern, behobenen Versionen und dem Stand der Ausnutzung, jeweils belegt an Hersteller-Advisories und Primärquellen. Er legt dann die Monatszahlen des CVE-Programms, der Microsoft-Patchdays und des CISA-Katalogs aktiv ausgenutzter Lücken für 2025 und 2026 nebeneinander, um die Frage zu beantworten, ob dieser Oktober wirklich aus dem Rahmen fällt. Die kurze Antwort: beim Volumen der Lücken ja, bei der Ausnutzung nein. Der Treiber hinter beidem ist derselbe: Sprachmodelle, die Lücken finden, und Sprachmodelle, die sie ausnutzen. Und es gibt eine dritte Seite, die in den Listen fehlt: Die Updates, mit denen Microsoft auf die Flut antwortet, sind so fehlerhaft, dass schneller patchen gerade bei Windows das falsche Rezept ist.

Lieferkettenangriffe im Oktober 2026

Der folgenschwerste Vorfall des Monats ist der Angriff auf ConnectWise Cloud Backup. Angreifer missbrauchten App-Zugangsdaten des Backup-Dienstes (ehemals SkyKick), um sich direkt in die Microsoft-365-Tenants von Kunden anzumelden; Multi-Faktor-Authentifizierung griff nicht, weil es sich um eine App-Identität handelte. Microsoft ordnet den Angriff in einem Blogbeitrag vom 21. Oktober dem chinesischen Akteur Storm-0940 zu, der das agentische KI-Pentest-Framework ARTEX nutzt. Es gab Anmeldeversuche bei über 2.250 Tenants, in der Spitze 2.900 pro Minute. Huntress zählte in seiner Kundenbasis mindestens 162 kompromittierte Tenants, in einigen wurden Exchange-Admin- oder Global-Admin-Rollen vergeben. Eine offizielle Opferzahl gibt es nicht.

Aktiv ausgenutzte Lücken in Firewalls, VPNs und Edge-Geräten

Bei den Geräten am Netzrand war der Oktober schon voll, bevor der Begriff „Black October” aufkam. Die Reihenfolge ist chronologisch; alle Lücken in dieser Tabelle werden aktiv ausgenutzt, sofern nicht anders vermerkt.

Das BSI hat im Oktober genau drei eigene Cyber-Sicherheitswarnungen veröffentlicht: Cisco Secure Email Gateway, BeyondTrust und PHP2Shell. Wer sich an diesen drei orientiert, hat die wichtigsten Baustellen, aber nicht alle.

Sicherheitslücken in PHP, Node.js, GitLab und Kernel

Die zweite Gruppe sind Lücken in Software, die fast überall steckt: in Webservern, Build-Pipelines, Hypervisoren und Betriebssystemen. Hier ist die Ausnutzung weniger breit belegt, die Angriffsfläche dafür größer.

Microsoft-Patchday und Exchange-Probleme im Oktober 2026

Der Oktober-Patchday vom 13. Oktober gehört in dieses Lagebild wegen seiner Größe: 1.415 neue Microsoft-CVEs nach Zählung der Zero Day Initiative, erstmals ein vierstelliger Monat und mehr als jedes frühere Microsoft-Gesamtjahr. Aktiv ausgenutzt wurde eine einzige Lücke, CVE-2026-96951, ein Mark-of-the-Web-Bypass in der Windows-Shell. Für Exchange war es das letzte Sicherheitsupdate für die Versionen 2016 und 2019; ab November gibt es Updates nur noch für die Subscription Edition.

Nach den Updates wurden Exchange-Server instabil. Ursache sind laut Exchange Team die Windows-Server-Updates vom Oktober, nicht die Exchange-Sicherheitsupdates: Das Update führt ein Standardlimit von 512 gleichzeitigen Lookups im RPC Endpoint Mapper ein, das unter Exchange-Last erschöpft wird. OWA-Anmeldungen schlagen fehl, Mails bleiben im Postausgang, Sessions brechen mit „MapiExceptionMdbOffline” ab. Der Workaround ist der Registry-Wert EpmapSavedContextCap (REG_DWORD, 65536) unter HKLM\SOFTWARE\Microsoft\Rpc plus Neustart; Microsoft arbeitet laut BleepingComputer an einem Fix und rät von einer Deinstallation ab.

Mehr Patches, mehr Fehler: Microsofts Qualitätsproblem

Damit sind wir bei dem Thema, das in den „Black October”-Listen fehlt, obwohl es für den Betrieb mindestens so wichtig ist wie jede Zero-Day-Lücke: Microsofts Updates reparieren inzwischen fast jeden Monat etwas, das sie im Vormonat kaputt gemacht haben. Ich habe das in den letzten Wochen mehrfach beschrieben, und der Oktober setzt die Reihe fort.

Der September war ein Lehrstück. Stunden nach dem Patchday fielen die Remote-Desktop-Dienste auf Windows Server 2019, 2022 und 2025 aus (KB5122876, KB5122882, KB5122871): Neue Verbindungen blieben bei „Verbindung wird hergestellt” hängen, nach dem ersten Abmelden stürzte der Dienst ab. Microsoft bestritt zunächst bekannte Probleme, bestätigte sie am 11. September und lieferte am 14. September elf Out-of-Band-Updates nach. Am 16. September bestätigte Microsoft, dass Windows 11 nach KB5124008 die Vertrauensstellung zur Domäne verlieren kann, Ursache ist die neue Machine Identity Isolation. Dazu kamen schwarze Bildschirme in RDP- und Hyper-V-Sitzungen, BitLocker-Fehler 24641 und Updates, die sich nach dem ersten Neustart selbst zurückrollten; die Liste steht in meiner Nachlese zum September-Patchday.

Der Oktober macht weiter. Neben dem Exchange-Problem oben können sich auf Windows 11 24H2 bis 26H2 Standardbenutzer nicht mehr per Remote Desktop anmelden (Fehler 0xC000000D), sobald KB5124010 oder ein späteres Update installiert ist und die Administrator Protection aktiv ist, die Microsofts Sicherheits-Baselines mit dem Oktober-Update einschalten. Microsoft hat den Fall am 13. Oktober noch am selben Vormittag auf „Mitigated” gesetzt, was heißt: Workaround vorhanden, Fix offen. Wer Baselines einsetzt, muss die Funktion auf betroffenen RDP-Hosts abschalten; Details in der Nachlese zum Oktober-Patchday. Microsoft selbst hat im MSRC angekündigt, dass Out-of-Band-Updates häufiger werden; Notfall-Patches sind damit Teil des Plans.

Das ist die Kehrseite der Zahlen aus dem Abschnitt davor. Microsoft findet mit MDASH mehr Bugs als je zuvor und packt sie in Pakete mit über tausend Fixes, die in einem Monat auf dieselben Geräte treffen wie Preview-Updates und neue Baselines. Getestet wird das Zusammenspiel offenbar nicht; getestet wird beim Kunden. Für Microsoft ist der Rekord-Patchday ein Beleg dafür, dass die Verteidiger schneller werden. Für den, der die Server betreibt, ist er vor allem ein Rekord an Stellen, an denen etwas schiefgehen kann.

Daraus folgt für mich eine Empfehlung, die quer zu allem steht, was Microsoft derzeit verlangt: Windows-Updates einen Monat versetzt einspielen. Wer den Oktober-Patchday erst im November installiert, bekommt die Fixes für RDS, Exchange und Domänenvertrauen mitgeliefert, statt sie selbst zu entdecken. Die Drei-Tage-Regel, die Microsoft im Juli vorgestellt hat, hätte im September bedeutet, dass die Verteilung an dem Tag abgeschlossen war, an dem Microsoft die Probleme eingestand. Solange die Qualität so bleibt, ist ein beschleunigter Patchrhythmus für Windows keine Sicherheitsmaßnahme, sondern ein zusätzliches Betriebsrisiko.

Fairerweise: Das gilt für Windows-Clients und interne Server. Für alles, was aus dem Internet erreichbar ist und aktiv angegriffen wird, gilt es nicht. Eine FortiMail mit CVE-2026-104286 oder ein NetScaler mit CVE-2026-88779 wartet keinen Monat, weil der Angreifer nicht wartet. Ein schlechter Patch lässt sich deinstallieren, ein kompromittierter Domänencontroller nicht. Die Kunst besteht darin, beides auseinanderzuhalten: Perimeter sofort, Windows mit Abstand und Testring.

Datenpannen, Ausfälle und Angriffe auf Kommunen

In Deutschland traf es im Oktober mehrere Verwaltungen. Die Stadtverwaltung Eichstätt wurde in der Nacht zum 9. Oktober verschlüsselt, der Großteil der Daten vorher kopiert, das Rathaus lief im Notbetrieb. Das Landratsamt Cham wehrte am 8. Oktober einen DDoS-Angriff ab, der zeitweise Mail, Telefonie und Internet mehrerer Gemeinden im Behördennetz lahmlegte. Die Kreisverwaltung Oberspreewald-Lausitz schaltete am 20. Oktober nach einem Hinweis des Innenministeriums auf einen kompromittierten Client vorsorglich alle Systeme ab. Und wegen PHP2Shell gingen am 21. und 22. Oktober die Stadt Münster samt Universität und Kliniken sowie das Landratsamt Biberach vorsorglich vom Netz.

Ist der Oktober 2026 wirklich ungewöhnlich? Die Zahlen

Der erste Reflex nach so einer Liste ist: Ja, offensichtlich. Der zweite sollte sein, nachzuzählen. Drei Zeitreihen helfen dabei: die veröffentlichten CVE-Einträge pro Monat, die neuen Microsoft-CVEs pro Patchday und die monatlichen Neuaufnahmen in den CISA-Katalog der aktiv ausgenutzten Lücken (KEV).

Beim CVE-Volumen ist die Lage eindeutig. 2025 lagen die Monate nach den cvelistV5-Daten des CVE-Programms zwischen 3.010 und 5.432 Einträgen, im Schnitt 3.984 pro Monat. 2026 begann der Januar mit 4.275 und stieg dann fast jeden Monat: 7.815 im Juni, 9.756 im Juli, 12.255 im August, 14.930 im September. Der Oktober steht nach 23 Tagen bei 13.493, das sind rund 587 pro Tag; hochgerechnet auf den Monat wären das etwa 18.000. Bis zum 23. Oktober hat das Jahr 2026 mit 85.338 Einträgen das gesamte Jahr 2025 (47.802) um 78 Prozent übertroffen. Die Prognose von FIRST lag im Februar noch bei einem Median von 59.427 für das ganze Jahr. Zum Vergleich: Der BSI-Lagebericht 2025 nannte durchschnittlich 119 neue Schwachstellen pro Tag und wertete das als Anstieg um 24 Prozent. Der Oktober 2026 liegt rund beim Fünffachen davon. Der CERT-Bund-Zähler im Warn- und Informationsdienst stand am 23. Oktober bei WID-SEC-2026-4141, allein an diesem Vormittag kamen 23 neue Advisories dazu.

Fairerweise gehört dazu: Der Oktober ist beim CVE-Volumen nicht der Spitzenmonat, das war der September. Der Oktober setzt den Trend fort, er erfindet ihn nicht. Was im Oktober neu ist, ist die Dichte der ausgenutzten Lücken in Basiskomponenten innerhalb weniger Tage: PHP, Node.js, GitLab, Citrix, Ivanti, Fortinet, Collabora, VeloCloud, dazu zwei Lieferkettenangriffe auf Entwicklerwerkzeuge an einem einzigen Tag.

Bei Microsoft ist der Sprung noch deutlicher. Die Monate Januar bis Juni 2026 lagen nach ZDI-Zählung noch zwischen 58 und 208 CVEs, dann kamen 621 im Juli, 398 im August, 972 im September und 1.415 im Oktober. 2025 lag der stärkste Monat bei 177, das gesamte Jahr 2023 bei 914. Gleichzeitig ist die Zahl der Zero-Days nicht gestiegen: 15 Microsoft-Zero-Days von Januar bis Oktober 2026 gegenüber 17 im selben Zeitraum 2023. Microsoft hat diese Entwicklung im Juli selbst angekündigt: Das hauseigene Scanning-System MDASH setzt mehrere KI-Modelle auf Windows-Binaries an, und Kunden sollen sich auf ein höheres Volumen pro Patchday einstellen.

Und jetzt die Zahl, die das Bild relativiert. Der CISA-Katalog aktiv ausgenutzter Lücken ist von Januar bis September 2026 um durchschnittlich 27,3 Einträge pro Monat gewachsen. Der September war mit 43 ein Ausreißer, der Oktober steht nach 23 Tagen bei 26 Neuaufnahmen, also exakt im Durchschnitt. Die Google Threat Intelligence Group beziffert in ihrer Analyse vom 30. September die Zahl der in freier Wildbahn ausgenutzten Lücken auf 18 pro Monat (2025: 10,5) und die Zero-Days auf 11 pro Monat (2025: 8). Das ist ein deutlicher Anstieg, aber er bleibt weit hinter dem Anstieg der Veröffentlichungen zurück: Nur 0,23 Prozent aller 2026 veröffentlichten Lücken wurden ausgenutzt, eine von 431. Die Zahl der Lücken explodiert, die Zahl der Angriffe steigt moderat.

Mein Fazit aus den Zahlen: Der Oktober 2026 ist beim Finden und Veröffentlichen von Lücken ein Rekordmonat in einem Rekordjahr. Beim Ausnutzen ist er ein normaler Monat in einem Jahr, in dem „normal” rund 70 Prozent über dem Vorjahr liegt. Beides stimmt gleichzeitig, und das Gefühl der Überforderung kommt aus der Kombination.

KI als Brandbeschleuniger auf beiden Seiten

Dass KI hinter dem Volumen steckt, ist keine Vermutung mehr, die Hersteller sagen es selbst. Microsoft nennt MDASH als Grund für die Patchday-Zahlen. Fortinet bedankt sich bei vier KI-Laboren für die Tests, die zum Hardening-Release führten. Der Node.js-Fehler wurde von OpenAI Codex Security gefunden, PHP2Shell von OpenAI und Wiz mitentdeckt, die Linux-Kernel-Lücken auf der Mailingliste trugen den Finder „TrendAI”. Anthropic hat am 6. Oktober für sein Project Glasswing mindestens 129.000 verifizierte Schwachstellen bei Partnerunternehmen zwischen April und Juli gemeldet, über 33.000 davon als kritisch oder hoch eingestuft, und hält diese Zahl für eine Untererfassung um mindestens den Faktor fünf. Für curl, ein Projekt mit einer Handvoll Kern-Maintainer, hat Daniel Stenberg am 20. Oktober angekündigt, Low- und Medium-Reports künftig öffentlich zu bearbeiten, weil das Meldevolumen das Team an die Grenze bringt; das Release 8.23.0 vom 14. Oktober schloss 24 CVEs auf einmal. Sam Altman sagte in einem Vortrag an der Stanford Graduate School of Business laut Berichten, KI finde inzwischen Fehler bis auf Hardware-Ebene, und er glaube nicht mehr, dass sich alle einfach patchen ließen.

Auf der Angreiferseite ist der Oktober der Monat, in dem KI-gesteuerte Angriffe von Einzelfällen zum Muster wurden. Microsoft beschreibt ARTEX, das Storm-0940 bei ConnectWise nutzte, als Open-Source-Framework mit mehreren Sprachmodell-Agenten, mit dem der Akteur in mehreren Fällen in unter drei Stunden von der Zielauswahl zum privilegierten Zugriff kam; Hunderte Organisationen seit September. Straiker beschreibt mit CARLIY0S ein System, das Claude als Kommandanten und Grok als Datensammler kombiniert und über 400 Finanzziele bearbeitete. Unit 42 beobachtete bei PHP2Shell einen Angriff auf eine europäische Behörde, bei dem agentische KI-Plattformen innerhalb von zwei Stunden nach dem Einbruch Passwort-Hashes und MFA-Geheimnisse abzogen und einen Domain-Admin-Zugriff versuchten. Volexity schreibt bei der Ivanti-Kette von LLM-Einsatz durch die Angreifer, DIVD bei Zammad von einem autonomen Agenten, und die Agentenplattform Cairn wurde laut SecurityWeek missbraucht, um über 100 Organisationen mit mehr als 1.100 Angriffsprojekten anzugehen, Erfolgsquote rund zehn Prozent. Die Beobachtung von Mandiant aus dem Frühjahr, dass die mittlere Zeit bis zur Ausnutzung bereits negativ ist, also vor dem Patch liegt, passt dazu; die Atlassian-Lücke war zwei Stunden nach dem PoC unter Beschuss.

Die Gegenposition verdient einen eigenen Absatz, weil sie stark ist. Dustin Childs von der ZDI schreibt in seinem Oktober-Review, KI erfinde die Bugs nicht, sie seien alle schon da gewesen; sie verkürze nur die Zeit zwischen Existenz und Entdeckung, und die Entdeckung skaliere schneller als die Ausnutzung. GTIG zeigt, dass KI-gefundene Lücken zu 58 Prozent als mittel und nur zu vier Prozent als hoch eingestuft werden, und dass rund 5.000 der 2026er-CVEs allein auf automatische Linux-Kernel-Zuweisungen entfallen, ohne einen einzigen beobachteten Zero-Day. VulnCheck zählte im ersten Halbjahr 1.061 KI-attribuierte Lücken, von denen 14 ausgenutzt wurden, 1,3 Prozent. Und Daniel Stenberg hat im Mai in einem Blogbeitrag nüchtern aufgeschrieben, dass von fünf als bestätigt gemeldeten Mythos-Funden in curl genau einer eine echte, niedrig eingestufte Schwachstelle war. Wer sagt, der „Black October” sei vor allem eine Veröffentlichungswelle, deren Etikett den Blick auf die eigentliche Uhr, die Ausnutzungsgeschwindigkeit, verstellt, hat die Zahlen auf seiner Seite.

Ich halte beide Lesarten für richtig, und das ist das Problem. Für Hersteller und Maintainer ist die Flut echt, und sie können sie nicht abarbeiten: Von den Glasswing-Funden in Open-Source-Projekten waren Anfang Oktober nach einer Auswertung des Disclosure-Dashboards 6.157 offengelegt und 516 gepatcht, 8,4 Prozent. Für Betreiber ist die Ausnutzung echt, und die passiert zunehmend in Stunden statt Wochen. Die Lücke zwischen beidem, also zwischen dem, was bekannt ist, und dem, was gefixt und eingespielt ist, wird größer. Genau in dieser Lücke arbeiten ARTEX und CARLIY0S.

Was Sie jetzt prüfen sollten

Bei dieser Menge hilft keine Liste mit 60 Punkten, sondern eine Reihenfolge. Zuerst alles, was aus dem Internet erreichbar ist und aktiv angegriffen wird: PHP (8.5.12, 8.4.27, 8.3.36, 8.2.35 oder Backport), Citrix NetScaler, Ivanti Connect Secure, FortiMail und FortiOS, PAN-OS, Cisco Secure Email, BeyondTrust Remote Support, Atlassian Data Center, SonicWall SMA, Nextcloud mit Collabora-App, Arista VeloCloud. Wer eines dieser Produkte seit Anfang Oktober ungepatcht betrieben hat, sollte nicht patchen und weitermachen, sondern von einer Kompromittierung ausgehen und danach suchen; bei Citrix, Ivanti und BeyondTrust liegen die Indikatoren in den verlinkten Berichten.

Zweitens die Lieferkette: Wer ConnectWise Cloud Backup oder SkyKick im Einsatz hatte, prüft die App-Registrierungen und Rollenzuweisungen im Microsoft-365-Tenant, nicht nur die Anmeldeprotokolle. Wer LiteLLM, Railway, Zeabur, Rank Math PRO, UpdraftPlus oder die OVHcloud-CLI nutzt, rotiert Secrets und sucht nach fremden Admin-Konten. Wer Java betreibt, spielt das eMudhra-Update ein und prüft, ob eigene Zertifikatsketten über eMudhra liefen.

Drittens die stille Masse: Node.js, Brotli-Pakete in Python, GitLab und Ruby, der Linux-Kernel wegen PwnEscape. Hier ist noch keine breite Ausnutzung belegt, aber Florian Roth hat recht mit seiner Warnung, dass automatisierte Scans auf Node2Shell nicht lange auf sich warten lassen. Und bei Exchange: Wer nach den Oktober-Updates OWA-Aussetzer oder stehende Warteschlangen sieht, braucht den Registry-Workaround aus dem Exchange-Team-Blog, keine Deinstallation.

Viertens die Windows-Landschaft: Das Oktober-Update auf Clients und internen Servern einen Monat versetzt einspielen, vorher die Release-Health-Seite und die bekannten Probleme lesen, dann mit einem Testring je Serverrolle beginnen, bei Remote-Desktop-Hosts mit echten An- und Abmeldungen über mehrere Stunden. Wer das Oktober-Update schon installiert hat, prüft Exchange auf den RPC-Workaround und RDP-Hosts auf die Administrator Protection. Und unabhängig vom Rhythmus: Management-Interfaces gehören nicht ins Internet, das war schon vor PHP2Shell so; dass Palo-Alto-VMs und NetScaler nach Posts von Kevin Beaumont, über die mehrere Portale berichten, ohne ASLR laufen, macht es nur dringender.

Fazit

Der Oktober 2026 hat in gut drei Wochen Lieferkettenangriffe auf Backup-, Entwickler- und WordPress-Werkzeuge, ein Dutzend aktiv ausgenutzte Lücken in Firewalls und VPN-Gateways, kritische Fehler in PHP, Node.js, GitLab und dem Linux-Kernel, einen Patchday mit 1.415 CVEs, vier deutsche Verwaltungen im Notbetrieb und die erste von Microsoft als Welle beschriebene KI-gesteuerte Angriffskampagne gebracht. Der Name „Black October” ist eine Zuspitzung, aber keine Übertreibung.

Ungewöhnlich ist der Monat beim Volumen, nicht bei der Ausnutzung. 13.493 CVE-Einträge in 23 Tagen gegenüber knapp 4.000 pro Monat im Vorjahr, 1.415 Microsoft-CVEs an einem Dienstag, 129.000 verifizierte Funde aus einem einzigen KI-Programm: Das ist die neue Grundlast, und sie wird im November nicht sinken. Die Ausnutzung steigt langsamer, aber sie wird schneller, und sie wird von denselben Modellen gesteuert, die die Lücken finden.

Die unbequeme Wahrheit dahinter: Microsoft ist in dieser Lage sein eigener größter Gegner. Je mehr Lücken die KI findet, desto größer die Updates, und desto häufiger reißen sie Remote Desktop, Exchange oder das Domänenvertrauen mit. Schneller patchen hilft nur, wenn die Patches halten. Solange sie das nicht tun, bleibt für Windows ein Monat Abstand die bessere Antwort, und für alles am Perimeter das Gegenteil.

Mein Vorschlag für die kommende Woche: Nehmen Sie die Liste der aktiv angegriffenen Produkte aus dem Abschnitt oben, gleichen Sie sie mit Ihrem Bestand ab, und tragen Sie für jedes Gerät am Perimeter ein, wann es zuletzt gepatcht wurde und ob das Management-Interface von außen erreichbar ist. Das ist eine Stunde Arbeit. Die Angreifer brauchen für denselben Abgleich ein paar Minuten. Und tragen Sie daneben ein, wann der Oktober-Patchday auf Ihren Windows-Servern ansteht: nicht diese Woche.

Quellen:

• Microsoft Security: AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise (21.10.2026)
• Microsoft: Evolving Windows vulnerability management to meet the speed of AI-powered discovery (09.07.2026)
• Microsoft Exchange Team: Exchange servers may become unstable after installation of October 2026 Windows updates (Oktober 2026)
• eMudhra: eMudhra to exit global SSL/TLS certificate business (22.10.2026)
• Mozilla Bugzilla: Bug 2083449 eMudhra (20.10.2026)
• Oracle: Security Alert Advisory CVE-2026-91403 (21.10.2026)
• LiteLLM: Security incident Oct 21 2026 (21.10.2026)
• Railway: Security Disclosure Wednesday, October 21st (21.10.2026)
• Pete Batard: GitHub-Issue #3064 zu Brian Krebs’ Rufus-Post (24.10.2026)
• Fortinet: Fortinet Releases Security Hardening Release for Multiple Products (21.10.2026)
• HPE: Security Bulletin HPESBNW05162 (22.10.2026)
• Palo Alto Networks: Advisory CVE-2026-0257 (13.05.2026)
• Siemens ProductCERT: SSA-580366 DLL Sideloading Vulnerability in Siemens Software Center (15.10.2026)
• Arista: Security Advisory 0199 (22.10.2026)
• PHP: Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp (21.10.2026)
• PHP: Advisory zu CVE-2026-115560 (23.10.2026)
• Node.js: October 2026 Security Releases (21.10.2026)
• Imperva: Node2Shell: From Brotli Data to Remote Code Execution (22.10.2026)
• Aikido: Node2Shell evolves to HTTP2Shell (23.10.2026)
• GitLab: Patch Release 19.5.1 (21.10.2026)
• Ruby: Regexp compilation fixes related to GitLab’s CVEs (23.10.2026)
• NVD: CVE-2026-99999 (Oktober 2026)
• 0patch: Micropatches für CVE-2026-49179 (22.10.2026)
• 0patch: Micropatches für CVE-2026-69459 (14.10.2026)
• Straiker: Inside CARLIY0S (21.10.2026)
• Unit 42: Threat Brief CVE-2026-109618 / CVE-2026-109619 (aktualisiert 23.10.2026)
• Volexity: Chained exploitation of Ivanti Connect Secure zero-days (13.10.2026)
• BSI: Cyber-Sicherheitswarnung Cisco Secure Email Gateway 2026-297701-1032 (15.10.2026)
• BSI: Cyber-Sicherheitswarnung BeyondTrust Remote Support 2026-297832-1032 (16.10.2026)
• CERT-Bund: Warn- und Informationsdienst, Security Advisories (Stand 23.10.2026)
• CISA/FBI: SafePay Ransomware Advisory AA26-293A (20.10.2026)
• Capcom: IR-Mitteilung zu CAPCOM ID (22.10.2026)
• Pizza Hut Japan: Mitteilung zum unbefugten Zugriff (23.10.2026)
• Interpol: Cybercrime crackdown in Africa nets 1,462 arrests (22.10.2026)
• Lilith Wittmann: Zweimal gehackt: Wie 300 Gigabyte AfD-Daten abflossen (20.10.2026)
• Zeabur: October 2026 Security Incident (Oktober 2026)
• TeamUpdraft: Security incident October 2026 (aktualisiert 23.10.2026)
• GMO Internet: Notice regarding Onamae.com Desktop Cloud (22.10.2026)
• Stadt Eichstätt: Cyber-Attacke auf Stadtverwaltung (22.10.2026)
• Landkreis Cham: Cyberangriff auf Landratsamt Cham erfolgreich abgewehrt (13.10.2026)
• Anthropic: Cyber Verification Program (06.10.2026)
• Google Threat Intelligence Group: Vulnerability Discovery and Exploitation Trends in the AI Era (30.09.2026)
• Zero Day Initiative: The October 2026 Security Update Review (13.10.2026)
• Daniel Stenberg: Do minor curl vulnerabilities in the open (20.10.2026)
• Daniel Stenberg: Mythos finds a curl vulnerability (11.05.2026)
• FIRST: CVE Forecast 2026 (11.02.2026)
• VulnCheck: State of Exploitation 1H 2026 (28.07.2026)
• Northeastern University: Watching the Watchers (Studie, 2026)
• craci.com: CVE Publication Data, Auswertung des cvelistV5-Repositorys (Snapshot 24.10.2026)
• vulnerabilitydata.io: Microsoft Patch Tuesday, Monatszählung nach ZDI (Stand 22.10.2026)
• cvetodo.com: CISA KEV Monatsübersicht (Stand 24.10.2026)
• BleepingComputer: Microsoft October Windows Server updates cause Exchange issues (19.10.2026)
• BleepingComputer: Microsoft: Recent Windows updates may trigger Remote Desktop failures (Oktober 2026)
• BleepingComputer: Microsoft September updates cause RDS failures on Windows Server (September 2026)
• Microsoft Release Health: Windows 11, version 24H2 known issues (Stand Oktober 2026)
• Microsoft Support: KB5124010 (22.09.2026)
• BleepingComputer: Microsoft October 2026 Patch Tuesday fixes 1,411 flaws, 3 zero-days (13.10.2026)
• BleepingComputer: Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers (15.10.2026)
• BleepingComputer: Citrix patches NetScaler SAML zero-day exploited in attacks (04.10.2026)
• BleepingComputer: Hackers exploit critical Atlassian flaw after public PoC release (07.10.2026)
• BleepingComputer: Abandoned Popcorn Time app exposed millions of devices to RCE attacks (23.10.2026)
• BleepingComputer: Ransomware attack disrupts Japan’s IDCF cloud used by govt clients (Oktober 2026)
• The Register: PHP2Shell exploit bypasses protections designed to stop remote code execution (22.10.2026)
• The Register: Google Cloud London outage (20.10.2026)
• The Register: Grocery giant Ahold Delhaize confirms cyberattack (19.10.2026)
• The Hacker News: Hackers Breach Enterprise Firewalls and VPNs, Exposing Over 70,000 Credentials (23.10.2026)
• The Hacker News: Attackers hijacked over 300 Tor exit relays (21.10.2026)
• The Hacker News: BlackX UEFI bootkit bypasses Secure Boot (23.10.2026)
• The Hacker News: Critical SonicWall SMA 1000 flaw (12.10.2026)
• The Hacker News: Popular WordPress SEO plugin Rank Math backdoored (19.10.2026)
• SecurityWeek: AI Platform Cairn Abused to Hack Over 100 Organizations (20.10.2026)
• Help Net Security: AOMEI Backupper compromised in supply chain attack (20.10.2026)
• Help Net Security: CVE-2026-0322, CVE-2026-76519, CVE-2026-105133/105134 exploited (15.10.2026)
• Huntress: AhsayCBS flaws exploited (08.10.2026, aktualisiert 12.10.)
• DIESEC: Zammad zero-day vulnerabilities CVE-2026-102489/102490 (06.10.2026)
• Greenbone: FortiMail vulnerability actively exploited (12.10.2026)
• IT-Connect: OVHcloud CLI binaries on GitHub were tampered with (Oktober 2026)
• INCIBE-CERT: Cyberattack on supermarket refrigeration systems in France (Oktober 2026)
• Phoronix: LKML New Trend Vulnerabilities (22.10.2026)
• Rescana: HPE Aruba AOS CVE-2026-79844 (Oktober 2026)
• heise: Phishing-Angriff auf Merz und viele andere: CDU-Mailkonto in Heilbronn gehackt (19.10.2026)
• Stuttgarter Zeitung/dpa: Störung der ING-App, kein Hinweis auf Hacker (20.10.2026)
• CBS News: Jared Kushner pushes back on report of hacked phone (Oktober 2026)
• ransomware.live: Coop Italia bei Qilin (23.10.2026)
• Niederlausitz aktuell: Verdacht auf Cyberangriff, Kreisverwaltung OSL weitgehend lahmgelegt (21.10.2026)
• ms-aktuell: PHP-Sicherheitslücke in Münster (22.10.2026)
• new-facts.eu: PHP-Sicherheitslücke, Homepage Landratsamt Biberach offline (22.10.2026)
• Security-Insider: BSI-Lagebericht IT-Sicherheit 2025 (November 2025)
• complexdiscovery: Inside Mandiant’s M-Trends 2026 findings (2026)
• Matthew Wong: Project Glasswing patching deficit in open source (Oktober 2026)
• Security Boulevard: Altman warns of escalating cyber crisis (24.10.2026)
• Borncity: „Black October” 2026: IT-Katastrophen der letzten Tage (22.10.2026)
• Borncity: Black October Teil 2 (23.10.2026)
• Borncity: Black October Teil 3 (24.10.2026)

Zwei Tage nach PHP2Shell beginnt die Phase, in der die Politik Konsequenzen fordert. Johannes Schätzl, digitalpolitischer Sprecher der SPD-Bundestagsfraktion, verlangt laut Golem ein starkes BSI, das Schwachstellen frühzeitig erkennt, Maßnahmen einleitet und Betreiber aktiv unterstützt, dazu KI-Werkzeuge und eine grundlegende Neuaufstellung der Cyberabwehr. Der Satz, der hängen bleibt: Mit Updates einer bekanntgewordenen Sicherheitslücke hinterherzulaufen, könne nicht unsere Antwort sein.

Ich habe gestern aufgeschrieben, was bei PHP2Shell tatsächlich passiert ist. Wer das gelesen hat, merkt schnell, dass Schätzls Forderung auf die falsche Behörde zielt. Das BSI hat am 21. Oktober genau das getan, wofür es da ist. Das Problem lag zwei Jahre lang woanders, und für dieses Woanders gibt es seit Dezember 2024 ein EU-Gesetz, das kaum jemand erwähnt.

Was das BSI bei PHP2Shell gemacht hat, und was nicht

Zur Erinnerung: Das PHP-Projekt hat seine Vorankündigung am 20. Oktober um 19:30 UTC veröffentlicht. Das BSI hat am 21. Oktober seine Cybersicherheitswarnung BITS-H 2026-297981-1032 mit Stufe Orange herausgegeben, noch bevor der Patch da war, mit CVSS-Einordnung, Patch-Zeitpunkt und der Empfehlung, Server notfalls vom Netz zu trennen. Am Abend kam Version 1.1 mit den Advisories nach. Mehrere Länder, Städte und der Bund sind dem gefolgt, und Digitalminister Wildberger nannte die Abschaltung der Bundes-Webseiten laut dpa eine richtige Entscheidung.

Das ist, nüchtern betrachtet, ein funktionierender Warnprozess. Schneller als die Hersteller-Vorankündigung geht es nicht, denn die Lücke war bis dahin unter Embargo. Schätzl fordert nun ein BSI, das Schwachstellen „frühzeitig erkennt”. Frühzeitig erkannt wurde PHP2Shell aber bereits. Laut dem Statement der PHP Foundation fand ein Core-Entwickler die ersten Anzeichen 2024 beim Aufräumen nach einem externen Audit. Der Fix lag danach zwei Jahre in einem Konsensverfahren, weil ein kleines Team sich nicht zwischen drei unangenehmen Varianten entscheiden konnte und niemand Zeit hatte.

Was hätte ein stärkeres BSI daran geändert? Nichts. Das BSI schreibt keine Zend-Engine. Es kann sie auch nicht patchen, nicht reviewen und nicht gegen tausende Third-Party-Extensions testen. Die Entscheidung, welcher von drei Fixes das Ökosystem am wenigsten zerlegt, trifft niemand in Bonn, und das ist auch gut so.

Wer die Software herstellt, trägt die Verantwortung

Schätzl sagt selbst, Sicherheit liege in der Verantwortung jeder Behörde und jedes Unternehmens. Das ist richtig, aber unvollständig. Vor der Behörde, die PHP betreibt, steht der Hersteller, der PHP in sein Produkt eingebaut hat. Golem zitiert den Verband eco mit dem Hinweis, dass PHP in Routern, Speichersystemen und Sicherheitsprodukten steckt, oft ohne dass die Betreiber es wissen. Genau das ist der Punkt. Eine Kommune, deren Fachverfahren oder NAS-Oberfläche im Hintergrund auf PHP 7.4 läuft, kann die Lücke nicht erkennen, weil sie nicht weiß, dass sie da ist. Der Hersteller weiß es. Oder müsste es wissen.

Und dafür gibt es seit dem 10. Dezember 2024 den Cyber Resilience Act, die Verordnung (EU) 2024/2847. Er gilt in voller Breite ab dem 11. Dezember 2027, aber die Meldepflichten nach Artikel 14 gelten bereits seit dem 11. September 2026, also seit sechs Wochen. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen binnen 24 Stunden an die ENISA und die nationalen CSIRTs melden. Das CSIRT in Deutschland ist das BSI. Wer also ein Produkt mit eingebettetem PHP verkauft, war seit Mittwoch meldepflichtig, sobald er von einer Ausnutzung erfuhr.

Dazu kommt die Software-Stückliste. Anhang I Teil II des CRA verlangt von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, in einem maschinenlesbaren Format, das mindestens die obersten Abhängigkeiten abdeckt. Das BSI hat dafür mit der TR-03183 Teil 2 längst eine Vorgabe geschrieben. Eine SBOM ist genau das Werkzeug, das am 21. Oktober gefehlt hat: ein Dokument, aus dem ein Betreiber in fünf Minuten ablesen kann, ob PHP drinsteckt und welche Version. Dass die Pflicht erst ab Ende 2027 vollständig greift, ist ein Terminproblem, kein Konzeptproblem. Die Antwort auf PHP2Shell steht im Gesetz, sie ist nur noch nicht in Kraft.

Der CRA kennt sogar die PHP Foundation

Der CRA hat auch an den Fall gedacht, der bei PHP2Shell im Zentrum stand: eine Stiftung, die eine frei verfügbare Sprache pflegt, mit der andere Geld verdienen. Artikel 24 schafft dafür die Rolle des Open-Source-Software-Stewards. Stewards unterliegen einem leichteren Regime als Hersteller, müssen aber eine dokumentierte, überprüfbare Cybersicherheitsstrategie haben, die beschreibt, wie Schwachstellen behandelt, behoben und in der Community geteilt werden, und sie müssen mit den Marktüberwachungsbehörden kooperieren.

Lesen Sie das noch einmal mit dem Foundation-Statement daneben. Die Foundation räumt ein, dass ihr Entscheidungsprozess im Konsens über Monate blockiert war und erst nach August 2026 auf Mehrheitsentscheidungen umgestellt wurde. Genau diesen Prozess soll ein Steward nach Artikel 24 schriftlich haben. Der CRA adressiert das Versagen von PHP2Shell also schon, nur nicht beim BSI, sondern dort, wo es entstanden ist. Und er nimmt die Bußgelder für Stewards ausdrücklich heraus, weil der Gesetzgeber verstanden hat, dass man eine unterfinanzierte Stiftung nicht mit Strafen besser macht.

Die Frage, die Schätzl nicht stellt: Wer bezahlt

Die Foundation hat die 2024er-Audit-Runde nicht selbst bezahlt. Das war die Sovereign Tech Agency des Bundes mit 205.000 Euro für 2023 und 2024, für Audit, Extension-Infrastruktur, Dokumentation und Testwerkzeuge. Der Audit fand laut php.net 27 Punkte, 17 davon sicherheitsrelevant, vier CVEs. Und beim Aufräumen fiel die Lücke auf, die jetzt PHP2Shell heißt.

Das ist die Pointe, die in der Debatte fehlt: Der Bund hat das Richtige getan. Er hat Geld in die Hand genommen, der Audit hat geliefert, das Problem wurde gefunden. Was danach fehlte, war die Kontinuität, also jemand, der zwei Jahre lang bezahlt wird, um den Fund zu Ende zu bringen. Die Foundation schreibt im Statement wörtlich, ohne ihre Finanzierung wäre es unmöglich gewesen, mehrere Leute Vollzeit auf das Thema zu setzen. Das heißt im Umkehrschluss: Mit mehr Finanzierung wäre es 2024 möglich gewesen.

Schätzl will mehr Geld und Personal für das BSI. Ich will das auch, das BSI hat seit dem NIS-2-Umsetzungsgesetz vom 6. Dezember 2025 mit dem neuen BSIG deutlich mehr Aufsichtsaufgaben und braucht dafür Leute. Aber ein Euro im BSI schließt keine Lücke in PHP. Ein Euro in der Sovereign Tech Agency oder direkt bei der Foundation tut das. Wer die Cyberabwehr „grundlegend neu aufstellen” will, sollte mit der Frage anfangen, warum 70 Prozent des Webs auf einer Sprache laufen, deren Security-Team laut eigener Aussage aus einer Handvoll bezahlter Entwickler und etwas ehrenamtlicher Hilfe besteht.

Die Gegenposition: Was an Schätzls Forderung stimmt

Fairerweise: Schätzl hat an zwei Stellen recht. Erstens schrumpft das Zeitfenster zwischen Patch und Angriff tatsächlich. Cloudflare-Chef Matthew Prince hat auf X beschrieben, wie die Angriffsversuche von tausenden vor der Veröffentlichung auf Millionen am nächsten Morgen stiegen. Wenn KI Exploits in Stunden baut, reicht ein Patch-Zyklus von Tagen nicht mehr. Da hat er einen Punkt, und eco-Vorstand Norbert Pohlmann sagt laut Golem dasselbe.

Zweitens ist ein BSI, das Betreiber aktiv unterstützt, statt nur zu warnen, eine sinnvolle Forderung. Die Niederlande haben laut Borncity über ihr NCSC ein öffentliches GitHub-Repository mit Erkennungswerkzeugen und Härtungshinweisen zu PHP2Shell veröffentlicht. So etwas vom BSI wäre am Mittwoch für viele Admins wertvoller gewesen als die dritte Pressemitteilung.

Nur folgt aus beidem nicht, dass das BSI Schwachstellen „frühzeitig erkennen” soll. Erkannt war sie. Was fehlte, war ein Prozess beim Hersteller, der den Fund in einen Fix verwandelt, und ein Dokument beim Betreiber, das sagt, wo das Produkt betroffen ist. Für beides steht die Regel im CRA. Dass das Wort in Schätzls Statement nicht vorkommt, ist das eigentliche Problem daran.

Was stattdessen zu fordern wäre

Wenn ich eine Forderung formulieren müsste, wäre es diese: Erstens, der Bund sorgt dafür, dass die Sovereign Tech Agency aus Einzelprojekten eine Dauerfinanzierung für die Software macht, auf der seine eigenen Portale laufen. Die Foundation hat am Mittwoch Regierungen ausdrücklich um genau das gebeten. Zweitens, das BSI nutzt seine Rolle als CSIRT unter dem CRA, um die Meldepflicht ab September 2026 bei Herstellern eingebetteter PHP-Produkte tatsächlich durchzusetzen, statt nur Warnungen zu schreiben. Drittens, öffentliche Auftraggeber verlangen in Ausschreibungen schon jetzt eine SBOM, ein Jahr bevor der CRA sie vorschreibt, denn nichts hindert sie daran.

Das ist weniger spektakulär als eine „grundlegende Neuaufstellung der Cyberabwehr”. Es hätte am Mittwoch aber funktioniert.

Fazit

PHP2Shell war kein Versagen des BSI. Es war ein Versagen beim Hersteller, der einen bekannten Fund zwei Jahre nicht fixen konnte, und bei Betreibern, die nicht wussten, wo PHP bei ihnen läuft. Für das erste kennt der CRA den Open-Source-Steward und die Meldepflicht, für das zweite die SBOM. Beides gilt teils seit September, vollständig ab Ende 2027. Wer jetzt nach dem BSI ruft, verlangt von der Feuerwehr, dass sie die Bauordnung schreibt.

Herr Schätzl ist Informatiker mit Berufspraxis in der IT-Branche. Er weiß, dass man eine Engine nicht per Behördenauftrag patcht. Die richtige Forderung liegt auf seinem Tisch, sie heißt Cyber Resilience Act und Dauerfinanzierung für Open Source. Ich würde ihn bitten, beim nächsten Interview mit dem Handelsblatt dieses Wort zu benutzen.

Quellen:

• PHP: Upcoming Critical PHP Security Release (20.10.2026)
• PHP: PHP Core Undergoes Security Audit – Results Now Available (10.04.2025)
• The PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security (21.10.2026)
• BSI: Version 1.1: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit (21.10.2026)
• EUR-Lex: Verordnung (EU) 2024/2847, Cyber Resilience Act (20.11.2024)
• Springlex: CRA Artikel 71 – Inkrafttreten und Geltungsbeginn
• Springlex: CRA Artikel 24 – Pflichten der Verwalter quelloffener Software
• Sovereign Tech Agency: PHP (2023)
• Golem: SPD-Digitalpolitiker kritisiert nach PHP-Lücke das BSI (22.10.2026)
• finanzen.at/dpa-AFX: PHP-Lücke: Wildberger sieht keine Hinweise auf Bundesangriff (22.10.2026)
• Matthew Prince (Cloudflare) auf X: Some stats on #php2shell (22.10.2026)
• Heuking: Ab jetzt gilt’s: NIS2-Umsetzungsgesetz in Kraft (05.12.2025)
• Johner Institut: SBOM – Software Bills of Materials (Anhang I CRA)
• Borncity: php2shell: Lücke seit 2024 bekannt, Angriffe laufen, Hosting gefährdet? (22.10.2026)

Am Mittwoch um 16 Uhr deutscher Zeit war es dann so weit. Nach einem Vormittag, an dem Landesregierungen, Städte, Kliniken und Bundesministerien ihre Webseiten vom Netz nahmen, veröffentlichte das PHP-Projekt die Updates gegen zwei Lücken, die inzwischen jeder nur noch PHP2Shell nennt. CVE-2026-109618 und CVE-2026-109619, beide mit CVSS 9.2, beide ohne Anmeldung aus der Ferne ausnutzbar, beide im Kern der Sprache, auf der nach eigener Aussage der PHP Foundation ein großer Teil des Webs läuft.

Wer gestern Server betreut hat, kennt den Tag: Warten auf 16 Uhr, Updates einspielen, Worker neu starten, hoffen. Dieser Artikel ist der Rückblick darauf. Was passiert ist, warum es passiert ist, und warum die Geschichte dahinter deutlich peinlicher ist als die Lücke selbst.

Vorab eine Korrektur, weil sie inzwischen in mehreren Versionen kursiert: Die Lücke existiert nicht „seit 2014″ und ist auch nicht seit 2014 bekannt. Sie steckt nach Angaben des BSI mindestens seit PHP 5 im Code, also seit 2004. Bekannt war sie der PHP-Entwicklung seit 2024. Das ist weniger lang, aber nicht weniger schlimm, denn zwei Jahre reichen völlig aus, um einen Fix nicht zu bauen.

Was PHP2Shell technisch ist

Die beiden Lücken sitzen dort, wo nahezu jede PHP-Anfrage durchläuft: Speicherverwaltung und Fehlerbehandlung. Die erste, CVE-2026-109618, nennt das Projekt im Security Advisory auf php.net „RCE via OOM corruption”. Erreicht eine Anfrage das memory_limit im falschen Moment, bleiben halb initialisierte interne Daten liegen, die PHP später für gültig hält. Auf Apache mit mod_php reicht dafür eine einzige Anfrage, bevor überhaupt Anwendungscode läuft.

Die zweite, CVE-2026-109619, heißt „RCE via stale global state”. Ein fataler Fehler zum falschen Zeitpunkt hinterlässt internen Zustand, der auf Speicher einer vorherigen Anfrage zeigt. Die nächste Anfrage im selben Worker nutzt diesen freigegebenen Speicher. Das Projekt schreibt dazu den Satz, den ich mir eingerahmt habe: Es gibt keine vollständigen Mitigationen, Updaten ist die einzige sichere Wahl.

Gefixt sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 7.4, 8.0 und 8.1 gibt es minimale Quellcode-Backports in eigenen Git-Branches, keine Releases. Wer noch darauf läuft, soll beim Distributor oder LTS-Anbieter nachfragen. Und PHP 8.2 läuft am 31. Dezember 2026 aus, der Hinweis steht gleich mit im Release-Text.

Der Tag, an dem Deutschland die Webseiten abschaltete

Das BSI hat am 21. Oktober die Cybersicherheitswarnung BITS-H 2026-297981-1032 veröffentlicht, Stufe 3 von 4, Orange. Darin stand ein Satz, der in der deutschen Behördenlandschaft offenbar als Anweisung gelesen wurde: Wer nicht kurzfristig patchen könne, solle eine vorübergehende Trennung des Webservers vom Internet erwägen.

Erwogen wurde ausgiebig. Laut einer dpa-Zusammenstellung bei teltarif nahm die Landesregierung Baden-Württemberg die Seiten der Ministerien und Regierungspräsidien vom Netz. In Bayern waren Ministerien und Polizei nicht erreichbar, dazu das Landratsamt Rhön-Grabfeld und das Klinikum Nürnberg. Die hessische Staatskanzlei teilte mit, dass hessen.de und die Webseiten der Ministerien und nachgeordneten Bereiche im Hessen-Web vorübergehend nicht erreichbar seien. Thüringen setzte seine Onlineangebote aus. Mainz deaktivierte mainz.de, Dresden kündigte an, bis voraussichtlich Donnerstag offline zu bleiben. Und am frühen Mittwochnachmittag gingen nach dpa-Angaben mehrere beim ITZ-Bund gehostete Seiten von Bundesministerien vom Netz. In der Schweiz zog laut SRF der Kanton Basel-Stadt den Stecker.

Man muss sich das kurz auf der Zunge zergehen lassen: Der offizielle Rat der nationalen Cybersicherheitsbehörde an die öffentliche Hand lautete sinngemäß „macht das Internet aus, bis es sicher ist”. Und das Beste daran ist, dass der Rat vermutlich richtig war. Digitalminister Wildberger nannte die Abschaltung der Bundes-Webseiten gegenüber der Bild eine richtige Entscheidung und sah keine Hinweise auf eine erfolgreiche Kompromittierung. Dann fügte er hinzu, der Fall zeige, dass wir am Beginn eines neuen Zeitalters der Cybersicherheit stünden, in dem KI-Tools Schwachstellen schneller aufspürten als je zuvor. Das stimmt sogar. Nur hat die KI die Lücke nicht gefunden. Ein Mensch hat sie 2024 gefunden. Die KI hat nur zwei Jahre später bewiesen, dass sie ausnutzbar ist.

Was die PHP Foundation einräumt

Die interessanteste Quelle des Tages war nicht das BSI, sondern das Statement der PHP Foundation, veröffentlicht wenige Stunden nach dem Patch. Es ist selten, dass ein Projekt dieser Größe so offen aufschreibt, was schiefgelaufen ist. Die Zeitleiste in Kurzform:

2024 ließ die Foundation PHP zum ersten Mal seit Jahren extern auditieren. Bezahlt hat das die deutsche Sovereign Tech Agency, organisiert hat es OSTIF, durchgeführt Quarkslab. Beim Beheben eines der Audit-Funde stieß ein von der Foundation bezahlter Core-Entwickler auf die ersten Anzeichen des OOM-Problems hinter CVE-2026-109618. Ein Exploit wurde damals theoretisch durchgespielt, aber niemand fand einen konkreten Weg, und andere Probleme mit klarerer Wirkung hatten Vorrang.

Dann kam der Teil, den jeder kennt, der je in einem Gremium gesessen hat. Das Security-Team entwickelte mehrere konkurrierende Fixes. Einer brach die Abwärtskompatibilität, einer brachte neues DoS-Potenzial mit, einer hätte Änderungen in vielen Third-Party-Extensions erfordert. Das Team arbeitete im Konsens, fürchtete die Folgen der falschen Wahl, und die wenigen Leute mit tiefem Engine-Wissen hatten noch zehn andere Aufgaben. Die Arbeit am Fix, so die Foundation wörtlich, stockte und startete über Monate immer wieder neu. Ihr eigenes Urteil: ein strukturelles Versagen, verursacht durch den Entscheidungsprozess des Security-Teams und seinen Mangel an Ressourcen.

Ich will das nicht kleinreden, aber ich will auch kurz würdigen, was hier steht. Die Lücke, wegen der gestern Landesregierungen offline gingen, lag zwei Jahre in einer Schublade, weil ein Gremium sich nicht einigen konnte, welcher von drei unangenehmen Fixes der am wenigsten unangenehme ist. Das ist nicht Bosheit, das ist Sitzungskultur. Und wer in der öffentlichen Verwaltung je versucht hat, drei Fachbereiche auf eine gemeinsame Lösung zu bringen, weiß, dass das in zwei Jahren eine ambitionierte Zeitvorgabe gewesen wäre.

Wie aus einer Schublade ein Notfall wurde

Ab dem Sommer 2026 ging es dann schnell. Im Rahmen von OpenAIs Programm „Patch the Planet” begann die Sicherheitsfirma Calif am 30. Juli einen Audit. Am 11. August meldete der Calif-Researcher Ryan A eine Remote Code Execution mit genau der Ursache, die die Foundation 2024 selbst gefunden hatte. OpenAI meldete am selben Tag unabhängig dasselbe. Wiz legte am 24. August nach, OpenAI am 18. September. Erst jetzt, schreibt die Foundation, war die volle Tragweite klar, und erst jetzt wurde der Fix zur obersten Priorität.

Auch die Zahlen dahinter sind lesenswert: Seit dem 1. Juli hat das Security-Team 15 CVEs veröffentlicht und über 100 Meldungen abgearbeitet, die ungültig, doppelt oder nicht reproduzierbar waren. KI-gestützte Forschung produziert Berichte in einer Menge, die ein Team dieser Größe nicht mehr weglächeln kann. Werkzeuge finden die Bugs. Was Werkzeuge nicht können, so die Foundation, ist entscheiden, wie man eine jahrzehntealte Design-Entscheidung in der Engine repariert, ohne das Ökosystem zu zerlegen. Dafür braucht es Leute, die den ganzen Code kennen, und davon gibt es zu wenige.

Die Pointe folgt am Ende des Statements. Die Foundation bittet Unternehmen, Hoster und ausdrücklich Regierungen um Geld. Die Sovereign Tech Agency habe mit dem Audit 2024 gezeigt, was öffentliche Förderung bewirken kann. Das ist korrekt. Der Audit hat die Lücke gefunden. Danach war das Geld alle, und der Fix lag zwei Jahre.

Coordinated Disclosure, unkoordiniert

Eigentlich sollte das Ganze am Donnerstag, 22. Oktober, veröffentlicht werden. Dann lief es so, wie Coordinated Disclosure in der Praxis meistens läuft.

Am Dienstag, 20. Oktober, gegen 15 Uhr UTC tauchten die beiden CVE-IDs in Foren und sozialen Medien auf, mit falscher Uhrzeit und einem falschen CVSS-Score von 10.0. Das PHP-Projekt zog seine Vorankündigung auf 19:30 UTC vor und den Release auf den Mittwoch, weil die Distributoren noch beim Paketieren waren. Gegen 20 Uhr UTC veröffentlichte Calif, eine der meldenden Firmen, versehentlich ein Video, das ihren Proof-of-Concept gegen echte Ziele zeigte. Das Video wurde gelöscht, Kopien kursierten. Die Mitigation-Hinweise, die das Projekt gegen 23 Uhr UTC an einige Betreiber kritischer Infrastruktur gab, sind nach Einschätzung der Foundation möglicherweise ebenfalls durchgesickert.

Und am Mittwoch um 07:41 UTC, mehr als sechs Stunden vor dem Release, veröffentlichte Chainguard fertige Container-Images mit dem Fix. Chainguard hatte den Patch wie alle Distributoren vorab bekommen. Jeder Angreifer konnte den Fix nun im Binärformat studieren, während der Rest der Welt auf 16 Uhr wartete. Die Foundation nennt das einen einseitigen Bruch des Embargos, der Wochen Arbeit vieler Beteiligter missachtet habe. Ich hätte es weniger höflich formuliert.

Was das in Zahlen bedeutet, hat Cloudflare-Chef Matthew Prince auf X zusammengefasst: In den zehn Stunden vor der Veröffentlichung sah sein Netz tausende Angriffsversuche. In den 45 Minuten nach der Veröffentlichung waren es zehntausende, nach zwei Stunden hunderttausende, am Donnerstagmorgen Millionen. Amazon berichtet laut SecurityWeek sogar von einem Exploit-Versuch gegen einen Honeypot am 17. Oktober, vier Tage vor dem Release, und weiß nach eigener Angabe nicht, woher der Angreifer von der Lücke wusste.

Fairerweise gehört dazu: Ein bestätigter erfolgreicher Einbruch war bis Donnerstag nirgends dokumentiert. Die US-Behörde CISA hatte laut CyberScoop zum Zeitpunkt ihrer Warnung keine Ausnutzung beobachtet, Huntress auf den Systemen seiner Partner auch nicht. BSI-Vizepräsident Thomas Caspers sagte laut The Next Web gegenüber Politico, man sehe Angriffe, aber keinen erfolgreichen. Und watchTowr beobachtete Massenausnutzung, stellte aber laut SecurityWeek fest, dass keiner der kursierenden Proof-of-Concepts tatsächlich Code ausführt. Millionen Versuche sind nicht Millionen Einbrüche. Das ist der Teil, den die Schlagzeilen gern weglassen.

Die Gegenposition, und warum sie trotzdem nicht reicht

Man kann das alles auch anders lesen, und die Foundation tut es in ihrem Statement selbst. Der Fix ist für vier Branches gleichzeitig erschienen, mit Backports für drei weitere, die Distributoren hatten ihn vorab, und die Leute haben nach eigener Angabe Wochenenden und Nächte durchgearbeitet. Das ist, gemessen an dem, was ein Projekt mit einer Handvoll bezahlter Entwickler leisten kann, eine beachtliche Leistung. Dass der Zeitplan überhaupt bis zwei Tage vor Release gehalten hat, ist bei so vielen Beteiligten eher die Ausnahme. Und die Abwägung zwischen Kompatibilität, Performance und Sicherheit ist bei einer Engine, auf der Millionen Anwendungen laufen, wirklich keine, die man in einer Stunde trifft.

Trotzdem bleibt die Frage, die niemand gern stellt: Warum braucht es einen externen Audit, finanziert von einer deutschen Bundesagentur, damit ein Projekt dieser Reichweite überhaupt in seinen eigenen Speichermanager schaut? Und warum ist nach diesem Audit niemand da, der den Fund zu Ende bringt? Die Antwort steht im Statement. Es gibt zu wenige Leute, und die wenigen werden von zu wenigen bezahlt. Jeder Onlineshop, jede Verwaltung, jede Bank, die auf PHP läuft, hat gestern von der Arbeit einer Handvoll Menschen gelebt, von denen die meisten ihre Namen nie gehört haben.

Und wenn die Foundation von Governments spricht, meint sie auch uns. Die Länder, die gestern ihre Portale abgeschaltet haben, betreiben sie auf PHP. Die Sovereign Tech Agency hat einmal einen Audit bezahlt. Das war gut. Ein Audit ist aber ein Foto, keine Wartung.

Was Sie jetzt tun sollten

Das ist meine Lesart der Hinweise des PHP-Projekts, keine Garantie. Erstens Version prüfen, und zwar nicht im Dashboard, sondern mit php -v auf jedem Host und in jedem Container. Zweitens, wenn die Version nicht 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder ein entsprechendes Distributionspaket ist, updaten und jeden Worker neu starten. Drittens, wer noch auf 8.1 oder älter läuft, hat jetzt keinen Patch, sondern eine Migration vor sich, und die Backport-Branches sind eine Brücke, kein Zuhause.

Wer gar nicht updaten kann, findet im Advisory Maßnahmen, die einzelne Angriffspfade schließen: memory_limit=-1 per php_admin_value, ein niedriges post_max_size, session.upload_progress.enabled=0 in der php.ini oder FPM-Pool-Konfiguration, nicht per ini_set(). Das Projekt sagt ausdrücklich, dass diese Maßnahmen eine Installation nicht sicher machen. Sie machen sie weniger unsicher. Das ist ein Unterschied, den man kennen sollte, bevor man die Seite wieder einschaltet.

Fazit

PHP2Shell war kein Zero-Day im klassischen Sinn. Es war eine Lücke, die 2024 gefunden, zwei Jahre in einem Konsensverfahren geparkt und 2026 von KI-gestützten Researchern wiederentdeckt wurde, bevor ein Leak, ein versehentliches Video und ein Distributor, der nicht warten wollte, aus einem geordneten Release einen Mittwoch machten, an dem Landesregierungen ihre Webseiten abschalteten. Die Entwickler haben am Ende geliefert. Die Struktur um sie herum hat versagt, und sie sagen es selbst.

Wenn Sie in einer Organisation arbeiten, die auf PHP läuft, und das sind fast alle, dann lesen Sie das Statement der Foundation bis zum letzten Absatz. Dort steht ein Link zum Sponsoring. Der Patch gestern war kostenlos. Der nächste ist es vielleicht nicht, wenn niemand bezahlt.

Quellen:

• PHP: Security advisory: Critical remote code execution vulnerabilities, update now (21.10.2026)
• PHP: Upcoming Critical PHP Security Release (20.10.2026)
• The PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security (21.10.2026)
• BSI: Version 1.1: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit (21.10.2026)
• Matthew Prince (Cloudflare) auf X: Some stats on #php2shell (22.10.2026)
• teltarif/dpa: Behörden reihenweise offline: Sicherheits-Leck bedroht Seiten (21.10.2026)
• finanzen.at/dpa-AFX: PHP-Lücke: Wildberger sieht keine Hinweise auf Bundesangriff (22.10.2026)
• SRF: Gravierende PHP-Sicherheitslücke bedroht Millionen Webseiten (22.10.2026)
• SecurityWeek: PHP2Shell Exploitation Started Days Before Patches (22.10.2026)
• CyberScoop: PHP releases emergency fixes for 2 critical vulnerabilities (21.10.2026)
• The Next Web: Millions of PHP2Shell attempts so far, but officials see no break-in (22.10.2026)

Der Hackerparagraf steht seit 2007 im Strafgesetzbuch, und fast genauso lange fordern Informatiker, ihn zu ändern. Am 25. August 2026 hat die Gesellschaft für Informatik (GI) den nächsten Anlauf genommen und ein 25-seitiges Whitepaper zur Reform des Computerstrafrechts vorgelegt. Entstanden ist es aus drei Workshops im Mai und Juni mit Leuten aus Sicherheitsforschung, Automobilindustrie und Zivilgesellschaft, in Zusammenarbeit mit der AG KRITIS und dem Verein LOAD.

Ich habe das Papier gelesen und die tragenden Angaben nachgeprüft. Die Richtung stimmt, mehrere Vorschläge sind konkret und brauchbar. An einer Stelle ist das Papier aber schlicht falsch, und ein zentraler Vorschlag hat aus meiner Sicht eine Schwäche. Beides steht weiter unten, zusammen mit dem, was Sie als Admin oder Verwaltung schon heute tun können, ohne auf Berlin zu warten.

Was § 202a StGB und § 202c StGB heute unter Strafe stellen

Unter „Hackerparagraf“ laufen drei Vorschriften. § 202a StGB bestraft, wer sich unbefugt Zugang zu Daten verschafft, die gegen unberechtigten Zugang besonders gesichert sind, und dabei die Zugangssicherung überwindet. Der Strafrahmen reicht bis zu drei Jahren Freiheitsstrafe. § 202b erfasst das Abfangen von Daten. § 202c StGB stellt schon die Vorbereitung unter Strafe, etwa das Herstellen oder Verbreiten von Programmen, deren Zweck eine solche Tat ist. Hier drohen bis zu zwei Jahre.

Die Absicht kommt im Tatbestand des § 202a nicht vor. Ob jemand Daten verkaufen oder dem Hersteller eine Lücke melden will, spielt für die Strafbarkeit zunächst keine Rolle. Das Whitepaper beschreibt die Folge so: Wer eine Schwachstelle meldet, gibt mit der Meldung zu, unbefugt Zugang gehabt zu haben. Die Meldung ist das Geständnis.

Für Admins ist § 202c der unangenehmere Teil, weil Portscanner und Passwort-Auditoren genauso zum Angriff taugen wie zur Prüfung des eigenen Netzes. Das Bundesverfassungsgericht hat 2009 klargestellt, dass nur Programme erfasst sind, deren Zweck die Begehung einer solchen Straftat ist. Bitkom weist in seiner Stellungnahme vom März 2025 trotzdem darauf hin, dass für Nutzer von Dual-Use-Werkzeugen ein Restrisiko bleibt.

Das Modern-Solution-Urteil – und wo das Whitepaper danebenliegt

Der Fall, an dem sich die Debatte seit Jahren festmacht, ist Modern Solution. Das Whitepaper widmet ihm einen Exkurs. Dort steht, der IT-Experte sei 2021 verurteilt worden, nach § 202c StGB, und das Bundesverfassungsgericht habe seine Beschwerde 2024 abgelehnt. Alle drei Angaben stimmen nicht.

Das Urteil des Amtsgerichts Jülich stammt vom 17. Januar 2024 und lautet auf Ausspähen von Daten nach § 202a StGB: 50 Tagessätze zu je 60 Euro, also 3.000 Euro. Die Lücke wurde 2021 entdeckt, daher vermutlich die Verwechslung. Das Landgericht Aachen bestätigte das Urteil am 4. November 2024. Die Verfassungsbeschwerde nahm Karlsruhe am 15. September 2025 nicht an (Az. 2 BvR 1086/25), wie Günter Born dokumentiert hat. Die Quelle, die das Whitepaper an dieser Stelle selbst zitiert, ist auf Oktober 2025 datiert.

Man kann das für Kleinkram halten. Ich sehe es anders: Ein Papier, das Abgeordneten und Ministerialbeamten erklären will, warum das Strafrecht falsch gebaut ist, sollte beim eigenen Kronzeugenfall den richtigen Paragrafen nennen. Die Gegenseite liest solche Papiere genau.

Was im Urteil steht, ist ohnehin aufschlussreicher als jede Zusammenfassung. Das Passwort zur Datenbank mit Daten von rund 600.000 bis 700.000 Endkunden lag unverschlüsselt im Code der Software. Der Entwickler hat es nach Überzeugung des Gerichts per Dekompilierung ausgelesen. Das Gericht räumt ein, der Hersteller habe „nachlässig gehandelt“, sieht darin aber trotzdem eine besondere Zugangssicherung, weil schon die Verwendung eines Passworts das Geheimhaltungsinteresse dokumentiere. Die beschlagnahmten Rechner bekam der Mann erst nach fast anderthalb Jahren zurück.

Fairerweise gehört auch die andere Hälfte dazu. Das Gericht hielt dem Angeklagten vor, zuerst einen Blogger informiert zu haben, sodass die Lücke noch am Tag der Entdeckung öffentlich wurde. Dem Unternehmen blieb keine angemessene Frist. Das war keine saubere Responsible Disclosure, also keine koordinierte Meldung mit Zeit zur Behebung. Wer den Fall als Beleg nimmt, sollte das wissen.

Was die GI zur Reform des Computerstrafrechts vorschlägt

Der Kern des Papiers: Die Absicht soll ins Gesetz. Die GI schlägt vor, in §§ 202a und 202b eine Schädigungsabsicht als zusätzliches Tatbestandsmerkmal aufzunehmen. Wer eine Lücke findet und dem Hersteller meldet, statt sie auszunutzen, wäre dann gar nicht erst tatbestandsmäßig unterwegs. Das soll auch die abschreckende Wirkung von Hausdurchsuchungen und beschlagnahmten Arbeitsgeräten mindern.

Dazu kommen drei weitere Baustellen. Das Merkmal „besonders gesichert“ soll an realistische Kriterien gebunden werden, damit ein Klartext-Passwort im Programmcode nicht mehr als Sicherung durchgeht. § 202c soll angepasst oder abgeschafft werden: Strafbar wäre dann die Verwendung eines Werkzeugs für eine verbotene Handlung und nicht mehr sein Besitz oder seine Herstellung. Und die GI will über das Strafrecht hinaus an das Urheberrecht, das Geschäftsgeheimnisgesetz und das Abhörverbot in § 5 TDDDG heran, weil Dekompilieren und das Melden unverschlüsselter Funkstrecken dort eigene Risiken auslösen.

Lesenswert ist der Abschnitt, in dem die GI sagt, wovon sie abrät. Ein Register für Sicherheitsforscher lehnt sie ab, weil es Zufallsfunde ausbremst und sich auch Kriminelle eintragen könnten, um sich zu legitimieren. Anonyme Meldungen sollen möglich bleiben, auch nach einer Legalisierung, weil Zivilklagen genauso abschrecken können wie Strafanzeigen. Überzogene Formvorgaben für Meldungen hält sie für eine eigene Fehlerquelle.

Der Blick nach Polen, Portugal und Belgien

Laut Whitepaper ist ethisches Hacking in sieben europäischen Staaten ausdrücklich erlaubt, in zwei weiteren entfällt unter Bedingungen die Strafverfolgung. Als Vorbilder nennt die GI Polen, Portugal und Belgien. Portugal und Belgien knüpfen die Straffreiheit an kumulative Bedingungen wie gute Absicht, keinen Schaden und zeitnahe Meldung. Belgien führt zusätzlich eine Hall of Fame.

Polen nennt das Papier den liberalsten Ansatz. Das stimmt für die Werkzeuge. Für den Zugriff selbst verlangt Art. 269c des polnischen Strafgesetzbuchs aber ebenfalls etwas: unverzügliche Benachrichtigung des Betreibers, kein verletztes Interesse, kein Schaden. Auch das liberalste Modell kommt also mit Bedingungen.

Der Cyber Resilience Act macht den Widerspruch sichtbar

Seit dem 11. September 2026 gilt die erste Stufe des Cyber Resilience Act. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle binnen 24 Stunden melden. Das Whitepaper formuliert hier etwas zu großzügig, wenn es von einer Meldepflicht für jede „identifizierte Schwachstelle“ spricht. Die Pflicht greift bei aktiver Ausnutzung.

Der Widerspruch bleibt trotzdem. Europa verpflichtet Hersteller zu melden, wenn ihre Lücken ausgenutzt werden. Deutschland bedroht gleichzeitig den Außenstehenden mit Strafe, der die Lücke findet, bevor es so weit kommt. Die GI schlägt vor, an die Herstellerpflicht eine geregelte Meldemöglichkeit für externe und ehrenamtliche Forscher anzuhängen. Das halte ich für den pragmatischsten Vorschlag im ganzen Papier, weil er an etwas Bestehendes andockt.

Was gegen ethisches Hacking ohne Auftrag eingewendet wird

Die Gegenposition gibt es, und sie kommt nicht nur von Unternehmen mit schlechter Software. Das Whitepaper zitiert selbst einen Referenten des Deutschen Mittelstandsbunds: Wenn Unbeauftragte auf Systeme zugreifen, könnten Daten verändert oder Funde öffentlich werden, und kleinen Firmen fehle oft das Geld, eine Lücke schnell zu schließen. Das Justizministerium hält nach einem Bericht von heise online daran fest, dass unbefugter Zugriff grundsätzlich strafbar bleiben soll. Und § 202a schützt nach der Rechtsprechung das formelle Geheimhaltungsinteresse des Berechtigten, unabhängig davon, wie gut seine Technik ist.

Das Argument mit dem Geheimhaltungsinteresse überzeugt mich nur halb. Wer ein Passwort im Klartext für alle Kunden ausliefert, hat sein Interesse dokumentiert, aber nichts gesichert. Das Datenschutzrecht verlangt von jedem Verantwortlichen den Stand der Technik. Dass das Strafrecht denselben Verantwortlichen schon für das bloße Vorhandensein eines Passworts belohnt, passt nicht zusammen.

Ernster nehme ich einen anderen Einwand, und der richtet sich gegen den Hauptvorschlag der GI. Eine Schädigungsabsicht als Tatbestandsmerkmal würde nicht nur Sicherheitsforscher entlasten. Auch wer aus Neugier in fremden Postfächern liest, will niemanden „schädigen“. Das ist meine Einschätzung als Nichtjurist, aber ich halte das Modell des Referentenentwurfs von 2024 hier für treffsicherer: Dort sollte der Zugriff „nicht unbefugt“ sein, wenn er in der Absicht geschieht, eine Lücke festzustellen und zu melden. Der damalige Justizminister Buschmann sagte dazu laut LTO, wer Lücken schließen wolle, habe Anerkennung verdient, „nicht Post vom Staatsanwalt“. Der Entwurf ist mit dem Ende der Ampel verfallen.

Wo die Reform im Oktober 2026 steht

Im Koalitionsvertrag von CDU, CSU und SPD steht, man wolle im Computerstrafrecht Rechtssicherheit für IT-Sicherheitsforschung schaffen. BSI-Präsidentin Claudia Plattner hat im November 2025 öffentlich gefordert, Meldende nicht zu verfolgen. Das Justizministerium erklärte damals, man prüfe die Umsetzung, einen Zeitplan nannte es nicht.

Ende August berichtete Tagesspiegel Background, das Ministerium wolle den nächsten Anlauf im vierten Quartal 2026 nehmen. Dieses Quartal hat begonnen. Einen neuen Referentenentwurf habe ich bis zum 9. Oktober 2026 nicht gefunden.

Was Kommunen und Admins jetzt schon tun können

Ich betreue die IT einer Gemeinde, und aus dieser Sicht ist die wichtigste Erkenntnis aus dem Jülicher Urteil eine prozessuale. § 202a wird grundsätzlich nur auf Strafantrag verfolgt, sofern die Staatsanwaltschaft kein besonderes öffentliches Interesse bejaht. Ob aus einer gut gemeinten Meldung ein Ermittlungsverfahren wird, entscheidet also in aller Regel der Betroffene selbst. Für eine Verwaltung heißt das: Die Entscheidung liegt beim Bürgermeister oder der Amtsleitung, und sie sollte nicht im Affekt fallen.

Daraus folgen ein paar Dinge, die kein Gesetz brauchen:

• Eine security.txt nach RFC 9116 auf der eigenen Website hinterlegen. Das BSI empfiehlt das dringend, weil die Suche nach dem richtigen Ansprechpartner eine der größten Hürden beim Melden ist.
• Intern festlegen, wer eine eingehende Meldung liest, wer sie bewertet und wer dem Melder antwortet. Ein Postfach, das niemand abruft, ist schlimmer als keines.
• Vorab klären und am besten veröffentlichen, dass auf Meldungen in guter Absicht keine Anzeige folgt. Vom BSI gibt es dafür eine CVD-Leitlinie als Vorlage.
• In Verträge mit Fachverfahrensherstellern schreiben, dass Sicherheitsprüfungen der gelieferten Software erlaubt sind. Das Whitepaper zitiert eine Studie, nach der mehr als die Hälfte der angefragten Produktverantwortlichen auf solche Anfragen gar nicht antwortete.

Der letzte Punkt ist der, an dem es in der Verwaltung am häufigsten hängt. Wir betreiben Software, deren Innenleben wir nicht prüfen dürfen, und verarbeiten damit Meldedaten, Sozialdaten und Steuerdaten. Wenn dort jemand von außen ein Klartext-Passwort findet, möchte ich das erfahren.

Fazit

Das GI-Whitepaper ist kein Gesetzentwurf und will keiner sein. Es sammelt, was die Praxis braucht: die Absicht als Kriterium, einen ehrlichen Begriff von „Sicherung“, legale Werkzeuge und einen Meldeweg, der an den Cyber Resilience Act anschließt. Der Exkurs zu Modern Solution gehört korrigiert, und die Schädigungsabsicht sollte durch eine engere Formulierung ersetzt werden. An der Diagnose ändert das nichts. Nach 19 Jahren trifft dieses Strafrecht zuverlässig die, die Bescheid sagen.

Zwei Dinge können Sie diese Woche erledigen. Legen Sie die security.txt an und klären Sie im Haus, wer bei einer Meldung antwortet. Und schreiben Sie Ihrem Bundestagsabgeordneten, dass das vierte Quartal läuft.

Quellen:

• Gesellschaft für Informatik, Whitepaper „Reform des Computerstrafrechts“ (August 2026) und Meldung „Zeit zu handeln“ (25.08.2026);
• AG Jülich, Urteil 17 Cs-230 Js 99/21-55/23 (17.01.2024);
• § 202a und § 202c StGB (dejure.org, geltende Fassung);
• LG Aachen, 74 NBs 34/24 (04.11.2024, nach dejure.org);
• Borns IT- und Windows-Blog zur BVerfG-Entscheidung 2 BvR 1086/25 (21.09.2025);
• Kuketz-Blog (23.09.2025);
• Bitkom, Stellungnahme Modernisierung des Computerstrafrechts (März 2025);
• LTO zum Referentenentwurf (04.11.2024);
• heise online zu Plattner und BMJV (November 2025);
• Tagesspiegel Background (27.08.2026, nur Anriss frei lesbar);
• netzpolitik.org, „Raus aus der Grauzone“ (26.08.2026);
• ENISA, Factsheet CRA Single Reporting Platform (September 2026);
• BSI, FAQ für Hersteller (CVD, security.txt);
• Kodeks karny Art. 269b, 269c (lexlege.pl, Stand 07.07.2026).

Die Cybersicherheit im Bund hat seit dem 12. August 2026 ein amtliches Zeugnis, und es liest sich wie die Beurteilung eines Auszubildenden, den man leider nicht kündigen kann. Der Bundesrechnungshof hat dem Haushaltsausschuss auf 31 Seiten aufgeschrieben, wie die Bundesregierung ihre eigene IT schützt. Kurzfassung: Sie weiß es nicht. Dafür weiß sie jetzt, wie ein Pirol klingt.

Auf dem Bericht steht, eine Veröffentlichung sei nicht zulässig. netzpolitik.org hat ihn trotzdem veröffentlicht, und man versteht nach der Lektüre, warum der Bund ihn lieber im Schrank gelassen hätte.

Ich betreue die IT einer Gemeinde. Ich lese solche Berichte mit einer Mischung aus Schadenfreude und Sodbrennen, weil ich weiß, wer am Ende die Formulare ausfüllt.

Was die Bereichsausnahme der Schuldenbremse mit IT-Sicherheit zu tun haben sollte

Erst die Fakten. Artikel 115 Absatz 2 Grundgesetz erlaubt dem Bund, bestimmte Ausgaben an der Schuldenregel vorbei über Kredite zu finanzieren, soweit sie zusammen ein Prozent des Bruttoinlandsprodukts übersteigen. Dazu gehören Verteidigung, Zivilschutz, Nachrichtendienste, Hilfe für angegriffene Staaten und der Schutz informationstechnischer Systeme. Der Haushaltsausschuss hat im November 2025 verlangt, dass der Bund damit seine IT-Sicherheit stärkt, zentral gesteuert vom Bundesministerium für Digitales und Staatsmodernisierung (BMDS).

In den Haushalten 2025 und 2026 stehen laut Bericht 4,5 Milliarden Euro in dieser Kategorie. Jede Titelgruppe trägt einen Vermerk, dass daraus nur Ausgaben für den Schutz informationstechnischer Systeme bezahlt werden dürfen. Für 2027 soll der Betrag von 2,8 auf 3,9 Milliarden Euro steigen.

Kriterien dafür, was „Schutz informationstechnischer Systeme” eigentlich ist, gibt es nicht. Das Finanzministerium hat das Risiko erkannt, es schriftlich festgehalten und dann beschlossen, lieber nichts zu definieren, weil jede Definition anfechtbar wäre. Das muss man sich als Admin einmal gönnen: eine Firewall-Regel nicht schreiben, weil sie falsch sein könnte.

1,2 Milliarden Euro, und die Vogelstimmen-App ist kein Ausrutscher

Der Rechnungshof hat fünf Titel der Forschungsförderung geprüft, zusammen mehr als 1,2 Milliarden Euro in zwei Jahren. Ergebnis: Keine der 68 zugehörigen Förderrichtlinien nennt den Schutz informationstechnischer Systeme als vorrangigen Zweck. Fünf davon schließen IT-Sicherheit als Forschungsgegenstand ausdrücklich aus. Das ist gut ein Viertel der gesamten Kategorie (eigene Rechnung: 1,2 von 4,5 Milliarden sind 26,7 Prozent).

Allein 2025 flossen aus diesen Titeln mehr als 600 Millionen Euro ab. Gefördert wurden Rechenzeit, KI-Methoden und Robotik. Einzelne Projekte entwickelten eine App zur Erkennung von Vogelstimmen, Verfahren zur Füllstandsmessung von Wertstoffcontainern und Röntgenstrahlquellen.

Ich habe nichts gegen Vögel. Ich habe auch nichts gegen volle Altglascontainer, die sich rechtzeitig melden. Nur schützt beides keinen Domänencontroller. Der Rechnungshof betont, dass die Beispiele keine herausgepickten Einzelfälle sind, sondern das Muster. Er spricht von verfassungs- und haushaltsrechtlichen Verstößen und einer höheren Nettokreditaufnahme, als die Schuldenregel erlaubt.

Dass kreditfinanzierte Sondertöpfe in Berlin ein Eigenleben entwickeln, kennen Leser dieses Blogs schon vom Sondervermögen, von dem bei den Kommunen rund 12 Prozent ankommen.

Die andere Hälfte des Befunds ist fast noch schöner. Von 105 Haushaltskapiteln mit IT-Ausgaben haben 64 keinen einzigen Euro für IT-Sicherheit in der Bereichsausnahme veranschlagt. Die einen buchen also Vogelkunde als Cyberabwehr, die anderen betreiben IT und melden für deren Schutz nichts an.

Die Gegenposition: Souveränität ist auch irgendwie Sicherheit

Fairerweise: Die Bundesregierung sieht das anders, und ihr Argument ist nicht völlig abwegig. Das Forschungsministerium erklärt, Schutz dürfe nicht auf operative Sicherheitsmaßnahmen verengt werden. Wer IT schützen wolle, müsse die gesamte Architektur im Sinne technologischer Souveränität beherrschen, von der Physik bis zur Anwendung. Die Gesetzesmaterialien zur Grundgesetzänderung definierten den Begriff zudem nicht näher.

Der Rechnungshof gibt ihr sogar ein Stück recht: Forschung kann dem Schutz dienen. Dann muss es aber im Förderzweck stehen. Wer alles, was einen Stecker hat, pauschal zur Cybersicherheit erklärt, hat keine Ausnahme mehr, sondern einen zweiten Haushalt. Der Linken-Haushälter Sascha H. Wagner nennt das gegenüber netzpolitik.org „neue Tricks, um alle möglichen IT-Ausgaben an der Schuldenbremse vorbeizuschmuggeln”. Ich hätte es unfreundlicher formuliert.

BSI-Kontrollen in der Bundesverwaltung: einmal pro Generation

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) darf seit Dezember 2021 die Sicherheit der Kommunikationstechnik des Bundes kontrollieren. Geplant war eine Standardrevision vor Ort bei allen Einrichtungen im Drei-Jahres-Rhythmus. Tatsächlich hat das BSI in den Jahren 2024 und 2025 zusammen 15 Einrichtungen geprüft. Für 2026 sind zehn weitere vorgesehen.

Bei mindestens 200 zu prüfenden Einrichtungen kommt der Rechnungshof auf rund 20 Jahre für einen Durchgang. Das ist noch freundlich gerechnet: Mit dem bisherigen Tempo von 7,5 Kontrollen pro Jahr wären es knapp 27 Jahre (eigene Rechnung: 200 geteilt durch 7,5). Und seit Dezember 2025 gilt die Kontrollbefugnis für alle Einrichtungen der Bundesverwaltung, die Liste ist also länger geworden.

Das BMDS antwortet, dem BSI fehle das Personal. Der Rechnungshof erinnert daran, dass das BSI über mehr als 1.700 Stellen verfügt und selbst entscheidet, wo es sie einsetzt. Ich kenne Gemeinden, die mit einer halben Stelle mehr Server anfassen.

Selbstauskunft statt Audit: das IS-Controlling, das seit 2022 kommt

Ein Informationssicherheitscontrolling, kurz IS-Controlling, soll dem Bund mit Kennzahlen zeigen, wie sicher seine IT tatsächlich ist. Der Haushaltsausschuss hat es im November 2022 gefordert. Zugesagt war es zuerst bis 2025. Jetzt soll bis Ende 2026 eine Grundversion stehen und 2027 ein erster belastbarer Bericht. Immerhin gibt es schon 18 Kennzahlen. Daten dazu gibt es nicht.

Woher sollen sie kommen? Aus einer jährlichen Basisdatenerhebung, also einem Fragebogen, den jede Behörde über sich selbst ausfüllt. Das BMDS nennt das eine „optimale Balance von Datenqualität und Aufwand”. Der Rechnungshof nennt es ein verzerrtes Bild: zehn Kontrollen vor Ort stehen weit über 200 Selbstauskünften gegenüber. Er empfiehlt unabhängige Auditoren. Das BMDS will den wesentlichen Empfehlungen nicht folgen.

Verbindliche Nachweise müssen die Einrichtungen des Bundes dem BSI übrigens erst zum 6. Dezember 2030 vorlegen. Auch die sollen als Selbstauskunft kommen. Ein Verfahren dafür hat das BSI laut Bericht bisher weder konzipiert noch erprobt.

Wer hier regelmäßig mitliest, erkennt das Muster. Der Bund weiß nicht, welche Software er überhaupt einsetzt, er weiß nicht, was seine Deutschland-App kostet, und jetzt weiß er auch nicht, wie sicher das Ganze ist. Aber er fragt nach. Bei sich selbst.

Was das für die IT-Sicherheit in Kommunen bedeutet

Hier endet der Bericht und beginnt meine Bewertung.

Derselbe Staat verpflichtet seit dem 5. Dezember 2025 rund 29.500 Unternehmen und Organisationen zu verbindlichen Sicherheitsmaßnahmen, mit Meldepflichten und Sanktionen. Für sich selbst plant er Fragebögen und eine Frist bis 2030. Die Kommunen hat er gleich ganz ausgenommen, was ich in Null von 421 für Hessen aufgeschrieben habe: 421 Gemeinden, kein gesetzlicher Mindeststandard.

Wohin das führt, war im August in Berlin zu besichtigen, als Angreifer 5,79 Terabyte aus zwei Senatsverwaltungen zogen und die Daten anschließend im Darknet landeten. Ich wüsste gern, was in der Selbstauskunft dieser Häuser gestanden hätte. Vermutlich „weitgehend umgesetzt”.

Und während oben Milliarden für Sicherheit in Robotik und Vogelkunde fließen, erklären Verbände und Ministerien den Rathäusern, wie wichtig Resilienz sei, verbindlich bitte nur für die anderen. In Hessen sitzt die Zuständigkeit dafür in drei Häusern gleichzeitig. Die Debatte der Saison dreht sich derweil um Hackbacks. Zurückschlagen will man also. Nachsehen, ob die eigene Tür zu ist, dauert noch bis 2030.

Für Admins und Verwaltungsleitungen steckt trotzdem etwas Brauchbares im Bericht, nämlich seine Methode. Der Rechnungshof hat nicht gefragt, ob die Ressorts sich für sicher halten. Er hat in Förderrichtlinien und Haushaltstitel geschaut. Das können Sie im Kleinen auch:

• Nehmen Sie Ihren letzten Sicherheits-Fragebogen, egal von wem, und lassen Sie drei Antworten von jemandem prüfen, der sie nicht selbst gegeben hat.
• Sehen Sie nach, was in Ihrem Haushalt unter IT-Sicherheit verbucht ist und was davon tatsächlich ein System schützt.
• Fragen Sie Ihren Dienstleister nicht, ob die Datensicherung läuft. Lassen Sie eine Datei zurückspielen.

Fazit

Der Bund hat sich eine Ausnahme von der Schuldenbremse ins Grundgesetz geschrieben, um seine IT zu schützen, und dann nicht festgelegt, was Schutz ist. Er hat eine Kontrollbehörde mit über 1.700 Stellen, die 15 Einrichtungen in zwei Jahren schafft. Und er will die Lücke mit Fragebögen schließen, deren Verfahren noch niemand entworfen hat. Das alles steht nicht in einem Oppositionspapier, sondern in einem Bericht seines eigenen Rechnungshofs, dessen Empfehlungen das zuständige Ministerium überwiegend ablehnt.

Der Haushalt 2027 wird gerade beraten. Wenn Sie einen Abgeordneten im Haushaltsausschuss kennen oder in dessen Wahlkreis wohnen, schicken Sie ihm die Seiten 13 und 24 des Berichts und fragen Sie, wofür die 3,9 Milliarden diesmal gedacht sind. Und prüfen Sie diese Woche eine einzige Ihrer eigenen Selbstauskünfte nach.

Der Pirol ist übrigens zuverlässig zu erkennen. Immerhin etwas.

Quellen:

• Bundesrechnungshof, Bericht nach § 88 Abs. 2 BHO „Cybersicherheit – Effektiver Ressourceneinsatz durch bessere Steuerung”, Gz. VII 4 – 0000583-5 (12.08.2026), veröffentlicht von netzpolitik.org;
• netzpolitik.org, Esther Menhard: „Digitalminister macht IT-Sicherheit per Vogelstimmen-App” (08.10.2026)

Am Freitagabend vor dem Feiertag hat Microsoft die September-Sicherheitsupdates für Exchange Server ein zweites Mal veröffentlicht. Der Grund heißt CVE-2026-96940: Wer an einem lokalen Exchange angemeldet ist, kann unter Umständen die Postfächer anderer Nutzer derselben Organisation öffnen und Mails samt Anhängen lesen.

Wer das September-Update bereits installiert hat, ist damit nicht fertig. Die V2-Pakete müssen zusätzlich drauf. Ich fasse zusammen, was bekannt ist, welche Builds Sie brauchen und wo Microsofts eigene Dokumentation gerade nicht zusammenpasst.

Was das Exchange Server Sicherheitsupdate September 2026 V2 enthält

Microsoft beschreibt die Neuauflage im Beitrag des Exchange-Teams als V2 der September-Updates. Neu ist nach übereinstimmenden Berichten nur der Fix für CVE-2026-96940, alles andere entspricht dem Stand vom 8. September. Es gibt vier Pakete:

• Exchange Server SE RTM: KB5129955 (SU10v2), Build 15.02.2562.053
• Exchange Server 2019 CU15: KB5129956, Build 15.02.1748.053
• Exchange Server 2019 CU14: KB5129957, Build 15.02.1544.048
• Exchange Server 2016 CU23: KB5129958, Build 15.01.2507.075

Den Build für Exchange SE nennt das Download Center zu KB5129955 selbst, die übrigen drei stammen aus Sekundärberichten. Die Updates sind kumulativ. Auf einem unterstützten CU genügt also das jeweils neueste SU.

Exchange Online ist nicht betroffen. Dort hat Microsoft die Korrektur bereits eingespielt. In Hybrid-Umgebungen bleiben die lokalen Server trotzdem Ihre Aufgabe, auch wenn sie nur noch zur Verwaltung laufen.

Rechteausweitung in Exchange: Ein Konto reicht

Die Lücke steckt in der Autorisierungsprüfung. Ein authentifizierter Angreifer kann seine Rechte über das Netzwerk ausweiten, und zwar auf fremde Postfächer. Über Mandantengrenzen hinweg funktioniert das laut Microsoft nicht. Details stehen im Eintrag des Security Update Guide.

Microsoft vergibt einen CVSS-3.1-Wert von 8.8 und die Einstufung „Important“. Aktive Angriffe sind bisher nicht gemeldet, die Ausnutzung gilt aber als „Exploitation More Likely“. Code lässt sich über die Lücke nicht ausführen. Es geht um Lesezugriff.

Man kann das beruhigend finden: kein Angriff von außen ohne Zugangsdaten, keine Übernahme des Servers. Ich finde es nicht beruhigend. Ein gültiges Konto ist die niedrigste Hürde, die es in einer Organisation gibt. Eine einzige erfolgreiche Phishing-Mail liefert es, und danach liest jemand im Postfach der Personalabteilung mit.

KB5129955 kam vor der Dokumentation

Der Ablauf am 2. Oktober war holprig. KB5129955 tauchte zuerst im WSUS auf, ohne dass Microsoft irgendetwas dazu veröffentlicht hatte. Günter Born hat das in seinem Bericht zu den Updates vom 2. Oktober nachgezeichnet: Erst am späten Abend kamen Support-Artikel, CVE-Eintrag und Blogbeitrag hinterher.

Die nachgereichte Dokumentation hat Lücken. Im Support-Artikel zu KB5129955 steht für das englische Paket der SHA256-Hash 40B38254…857F. Das ist derselbe Wert, den Microsoft schon für das ursprüngliche September-Update KB5121608 angegeben hat. Das Download Center nennt für die V2-Datei dagegen 007EA4E6…3713. Stand 3. Oktober widersprechen sich also zwei Microsoft-Seiten. Ich halte den Wert im Download Center für den richtigen, weil er zur neuen Datei gehört. Geprüft habe ich das nicht.

Dazu passt, dass der Artikel als ersetztes Update weiterhin das August-SU nennt und nicht das September-SU. Und die CVE-Liste führt neben der neuen Lücke acht ältere auf, obwohl das September-Update neun Schwachstellen geschlossen hat. Das sieht nach Copy-and-paste unter Zeitdruck aus. Schlimm ist das einzeln nicht. Aber wer Hashes prüft, bevor er ein Paket auf den Mailserver lässt, bekommt gerade von Microsoft selbst einen falschen Vergleichswert.

Exchange 2016 und 2019: Fix nur mit ESU

Exchange 2016 und 2019 sind seit dem 14. Oktober 2025 aus dem Support. Die V2-Pakete gibt es für diese Versionen nur im Programm „Period 2 ESU“, also mit bezahlten Extended Security Updates. Dieses Programm deckt Updates von Mai bis Oktober 2026 ab.

Zwei Folgen. Wer 2016 oder 2019 ohne ESU betreibt, hat jetzt eine dokumentierte Lücke zum Mitlesen fremder Postfächer und keinen Patch. Und wer ESU hat, bekommt in wenigen Wochen ebenfalls nichts mehr. Die Migration auf Exchange Server SE lässt sich dann nicht weiter schieben.

Bekannte Probleme im Exchange-Update bleiben bestehen

Die V2 behebt keines der bekannten Probleme aus dem September. Microsoft listet weiterhin drei: Veröffentlichte Kalender (.ics) liefern „HTTP 500“, Frei/Gebucht-Abfragen für delegierte Postfächer scheitern in Hybrid-Umgebungen, die nur die Graph API nutzen, und fehlende koreanische WordBreaker-Dateien können einen ContentEngine-Deadlock auslösen.

Für das Kalenderproblem beschreibt Microsoft im Artikel zum .ics-Fehler einen Workaround per URL-Rewrite-Regel. Wenn Sie Kalender nach außen veröffentlichen, etwa Raumbelegungen oder Sitzungstermine, lesen Sie den vorher.

Fairerweise: Zwei ältere Fehler sind behoben, nämlich Wrapper-Nachrichten in freigegebenen Postfächern seit dem Juni-Update und verschobene Frei/Gebucht-Zeiten über Graph. Beides war aber schon im September-Update enthalten.

Was das für Exchange in der Verwaltung bedeutet

In einem Rathaus liegen im Postfach nicht nur Termine. Da liegen Personalvorgänge, Sozialdaten, Vergabeunterlagen, Schriftverkehr mit dem Personalrat. Eine Lücke, über die jeder angemeldete Nutzer in fremde Postfächer schauen kann, ist dort ein Datenschutzvorfall mit Ansage. Sollte ein Zugriff tatsächlich stattgefunden haben, läuft die 72-Stunden-Frist nach Art. 33 DSGVO.

Ich würde so vorgehen:

1. Mit dem Exchange Server Health Checker den Build aller Exchange-Server und aller Rechner mit Verwaltungstools prüfen.
2. In WSUS nachsehen, ob KB5129955 per automatischer Genehmigung schon installiert wurde. Wenn ja: veröffentlichte Kalender testen.
3. Server mit OWA oder ActiveSync am Internet zuerst patchen, danach den Rest.
4. Nach der Installation neu starten und kontrollieren, ob alle Exchange-Dienste laufen.
5. Bei Exchange 2016 oder 2019 klären, ob ESU vorhanden ist. Falls nicht, den Migrationstermin festlegen, und zwar mit Datum.

Bis zum nächsten regulären Patchday würde ich damit nicht warten.

Fazit

Die Lücke ist kein Weltuntergang, aber sie trifft den Kern dessen, was ein Mailserver leisten soll: dass jeder nur seine eigene Post liest. Ein gekapertes Konto genügt, und davon gibt es in jeder größeren Organisation früher oder später eines.

Mich ärgert weniger das Nachpatchen als die Art. Ein Sicherheitsupdate am Freitagabend ohne Dokumentation in den WSUS zu kippen und dann einen Support-Artikel mit dem Hash des Vorgängers nachzuschieben, ist keine Kleinigkeit bei einem Produkt, das Microsoft inzwischen im Abo verkauft.

Prüfen Sie am Montag den Build Ihrer Exchange-Server. Steht dort nicht die V2, planen Sie das Wartungsfenster noch für diese Woche.

Quellen:

• Microsoft Support, KB5129955 (2. Oktober 2026);
• Microsoft Download Center, Security Update for Exchange Server SE RTM SU10v2 (2. Oktober 2026);
• Microsoft Security Update Guide, CVE-2026-96940 (2. Oktober 2026);
• Exchange Team Blog, Released: September 2026 V2 Exchange Server Security Updates (2. Oktober 2026);
• Microsoft Support, KB5121608 (8. September 2026);
• S-EDV News, Exchange-Update schließt Postfach-Lücke (3. Oktober 2026, KI-generiert laut Kennzeichnung des Portals)

Die private Handynummer des BND-Vize Dag Baehr steht im Internet, zusammen mit E-Mail-Adresse und Wohnanschrift. Die Daten stammen aus dem Hack eines amerikanischen Online-Auktionshauses im Jahr 2020, bei dem die Angreifer Daten von mehr als drei Millionen Kunden veröffentlichten. Das haben WDR und Süddeutsche Zeitung recherchiert.

So weit, so alltäglich. Datenlecks passieren, auch Generälen. Der Teil, bei dem mir der Kaffee aus der Hand gefallen ist, kommt danach: Die Nummer ist bis heute aktiv. Golem bringt es in der Überschrift auf den Punkt: Der Mann hat die geleakte Nummer einfach weiter genutzt.

Ich betreue die IT einer Gemeinde. Bei uns gibt es für so etwas eine Unterweisung und einen ernsten Blick. Beim Auslandsnachrichtendienst gibt es dafür offenbar den Posten des Vizepräsidenten.

Was beim Datenleck des Auktionshauses 2020 passiert ist

Erst die Fakten, dann der Spott. Das Auktionshaus gibt an, die Betroffenen damals per E-Mail über das Leck informiert zu haben. Baehr war 2020 noch nicht beim BND. Er kam im September 2023, davor war er unter anderem Kommandeur des KSK und in der Führung des Kommandos Strategische Aufklärung.

Gegenüber WDR und SZ erklärte Baehr, er nutze die Nummer ausschließlich privat. Dem stehen Militärangehörige und Beamte gegenüber, die den Reportern sagten, sie hätten von ihm nur diese eine Nummer, ohne privat mit ihm zu tun zu haben.

Er ist nicht allein. Laut der Recherche sind mehrere europäische Geheimdienstchefs von solchen Datenpannen betroffen, darunter der Chef des niederländischen Militärgeheimdienstes MIVD.

Strategische Aufklärung, nur eben nicht in eigener Sache

Jetzt die Bewertung. Ein Mann, der in der Führung eines Kommandos mit dem Namen „Strategische Aufklärung“ saß, lässt sechs Jahre lang eine Nummer in Betrieb, die jeder mit Suchmaschine und Geduld finden kann. Aufklärung ist offenbar etwas, das man bei anderen betreibt.

Was er bei dem Auktionshaus ersteigern wollte, ist nicht überliefert und geht mich nichts an. Ich hoffe nur, es war den Preis wert. Bezahlt hat er am Ende mit Anschrift, Mailadresse und Telefonnummer, und die Quittung hängt seit 2020 öffentlich aus.

Auf der Leitungsseite des BND steht Baehr als „Vizepräsident und Dienstältester Offizier“. Dienstältester. Man möchte ergänzen: mit der dienstältesten Handynummer des Hauses.

Private Handynummer, dienstlich bekannt: die Sache mit „ausschließlich privat“

„Ausschließlich privat“ ist ein schöner Satz. Er hält genau so lange, bis Offiziere und Beamte erzählen, dass sie keine andere Nummer von ihm kennen. Entweder pflegt der Vizepräsident ein ungewöhnlich großes privates Umfeld in Uniform, oder die Trennung zwischen privat und dienstlich ist beim BND ähnlich stabil wie in jedem Rathaus, in dem der Chef „schnell mal per WhatsApp“ erreichbar sein will.

Und selbst wenn es stimmt: Eine private Nummer ist für einen Angreifer kein Trostpreis. Sie ist der Hauptgewinn. Am privaten Gerät hängen Familie, Messenger, Standort, Gewohnheiten.

Warum eine Telefonnummer für Spionage reicht

Mit Mailadresse und Telefonnummer lassen sich laut der Recherche Aufenthaltsorte und Hobbys nachvollziehen, im schlechtesten Fall auch Geheimes. Russische Dienste gelten als geübt in genau diesen Methoden. Dazu braucht es keinen Zero-Day. Es reicht eine Nummer, die in Messengern registriert ist, ein Profilbild, ein „zuletzt online“ und jemand in Moskau mit einer Excel-Tabelle.

Der Mann, dessen Behörde uns erklärt, wie gefährlich hybride Bedrohungen sind, liefert dem Gegner also die Stammdaten frei Haus. Ich nenne das Bürgernähe. Nur eben gegenüber den falschen Bürgern.

Fairerweise: Was für Baehr spricht

Baehr ist hier zunächst Opfer. Gehackt wurde ein Auktionshaus, nicht er. 2020 war er nicht beim BND, und niemand wechselt gern eine Nummer, die seit Jahren in jedem Adressbuch steht. Dass gleich mehrere europäische Geheimdienstchefs betroffen sind, spricht außerdem für ein Systemproblem und gegen die Geschichte vom einzelnen Schussel.

Nur trägt das nicht weit. Spätestens mit dem Wechsel in die BND-Spitze 2023 hätte jemand fragen müssen, welche Daten des neuen Vizepräsidenten schon draußen sind. Das ist keine Raketenwissenschaft, das ist ein Leak-Check und eine neue SIM-Karte. Wenn eine Sicherheitsüberprüfung so etwas nicht findet oder findet und liegen lässt, dann ist das Problem größer als ein Mann und sein Telefon. Ob man das Vorsatz oder Irrsinn nennt, überlasse ich Ihnen. Ich schwanke noch.

OPSEC in der Verwaltung: Was Kommunen daraus mitnehmen

Lachen Sie nicht zu laut. In fast jeder Verwaltung, die ich kenne, läuft dasselbe Muster, nur ohne Geheimdienst. Die private Nummer der Bürgermeisterin steht im Vereinsverteiler, der Amtsleiter registriert sich mit der Dienstadresse bei einem Onlineshop, und der Admin hat seit 2014 dieselbe Mobilnummer im Notfallplan, im Impressum eines alten Projekts und in drei geleakten Kundendatenbanken.

Was ich in der Praxis für sinnvoll halte:

• Dienstliche Mailadressen der Führungsebene und der Admins regelmäßig gegen bekannte Leaks prüfen, etwa mit dem Identity Leak Checker des HPI oder Have I Been Pwned.
• Dienstadressen nie für private Konten verwenden, und das schriftlich regeln, nicht nur beim Kaffee.
• Wer in exponierter Funktion ist und in einem Leak mit Nummer und Anschrift auftaucht, bekommt eine neue Nummer. Das kostet einen Nachmittag.
• Dienstliche Kommunikation läuft über dienstliche Geräte. Wenn es keine gibt, ist das die eigentliche Baustelle.

Nichts davon ist teuer. Es scheitert in der Regel daran, dass es unbequem ist und niemand dem Chef sagen will, dass er seine Nummer wechseln muss. Beim BND anscheinend auch.

Fazit

Ein Datenleck von 2020 ist kein Skandal. Sechs Jahre danach mit denselben Daten an der Spitze eines Nachrichtendienstes zu sitzen, ist einer. Die Behörde, die von uns allen Wachsamkeit verlangt, hat bei ihrem eigenen Vizepräsidenten nicht nachgesehen oder nicht gehandelt.

Prüfen Sie heute Ihre eigene Dienstadresse in einem Leak-Checker, und danach die Ihrer Verwaltungsspitze. Das dauert zehn Minuten. Damit sind Sie dem BND dann sechs Jahre voraus.

Microsoft hat eine Drei-Tage-Regel für Windows-Updates ausgerufen: Wer Qualitätsupdates länger zurückstellt, handelt fahrlässig, denn Angreifer bauen mit KI in Stunden Exploits. Das sagt der Hersteller, dessen September-Updates Terminalserver stilllegten, Domänenvertrauen kappten und VPN-Verbindungen im Kreis laufen ließen. Man muss diese Chuzpe fast bewundern.

Jörn Walter hat das beim Windows Papst höflich als zwei Wahrheiten beschrieben, die nicht zusammenpassen wollen. Ich bin weniger höflich. Hier fordert der Brandstifter kürzere Anfahrtszeiten für die Feuerwehr.

Was die Microsoft-Patch-Empfehlung wörtlich sagt

Die Regel stammt aus keinem Sicherheitsstandard, sondern aus einem Werbevideo von dreieinhalb Minuten. Am 7. Juli 2026 erklärte Jeremy Chapman, Microsoft 365 Director, bei Microsoft Mechanics die neuen Werte: Rückstellung unter drei Tagen, Deadline null oder ein Tag, Kulanzzeit höchstens zwei Tage. Sein erster Satz: „Intentionally delaying security patches might be a common practice, but it shouldn’t be”.

Warum diese Praxis so verbreitet ist, erwähnt er nicht. Es wäre auch unangenehm geworden. Admins verzögern Updates nicht aus Faulheit, sondern aus Erfahrung, und diese Erfahrung hat einen Lieferanten.

Fairerweise: Chapman schränkt ein. Die Empfehlung gilt für verwaltete Geräte, bei denen man es sich leisten kann, und er spricht über Clients, Edge und Microsoft 365 Apps. Server kommen im Video nicht vor. Rein zufällig lautet die Lösung Autopatch, Intune und Hotpatch, also drei Produkte aus dem eigenen Haus. Das Problem wird mitgeliefert, die Lösung gibt es im Abo.

Microsoft-Update-Qualität: Die KI findet, der Kunde testet

Den Grundsatztext dazu schrieb Tom Gallagher vom Microsoft Security Response Center in seiner Notiz zum Mai-Patchday. Die Patchdays werden weiter wachsen, weil Microsofts eigene KI immer mehr Lücken findet. Und dann steht dort tatsächlich: „every update makes our customers safer”. Jedes. Auch das vom 8. September.

Lesenswert ist der Text trotzdem, vor allem zwischen den Zeilen. Gallagher kündigt an, dass Kunden sich auf häufigere Out-of-Band-Updates einstellen sollen, die sofortige Aufmerksamkeit verlangen. Notfallpatches sind damit kein Betriebsunfall mehr, sie stehen im Fahrplan.

Die Rechnung dahinter ist simpel. Die KI findet Lücken im Akkord, die Entwickler schreiben Fixes im Akkord, und irgendwo dazwischen müsste jemand testen. Raten Sie, wer das ist. Er sitzt nicht in Redmond und steht auf keiner Gehaltsliste von Microsoft.

Patchday September 2026: 974 Fixes und ein Scherbenhaufen

Zuerst die Leistung, denn die gab es. Microsoft zählt 974 CVEs, davon bleiben nach der Auswertung von Malwarebytes 964 für Kunden. Dazu kommen zwei aktiv ausgenutzte Zero-Days, die SecurityWeek als CVE-2026-85880 in ALPC und CVE-2026-81963 im Windows Update Stack benennt. Die Details stehen in meinem Beitrag zum September-Patchday.

Ja, Sie haben richtig gelesen. Eine der beiden ausgenutzten Lücken steckte in der Komponente, die Updates installiert. Bessere Pointen schreibt kein Kabarettist.

Und nun die Kollateralschäden, in der Reihenfolge ihres Auftretens:

• 8. September: Patchday. Auf Windows Server 2019, 2022 und 2025 fallen wenige Stunden nach der Installation die Remote Desktop Services aus.
  11. September: Microsoft räumt die Probleme mit RDS und Hyper-V ein. Bis dahin hieß es offiziell, es gebe keine bekannten Probleme. Meine Patchday-Nachlese stammt vom selben Tag.
  14. September: elf Out-of-Band-Updates reparieren den Patchday, für Server nur über den Update-Katalog.
  16. September: Microsoft bestätigt, dass Windows 11 nach KB5124008 die Vertrauensstellung zur Domäne verliert.
• Um den 24. September: Always On VPN bleibt unter Windows 11 beim Verbinden hängen. BleepingComputer zitiert den Workaround, einen Termin für die Korrektur gibt es nicht.
• Seit 24. September: KB5002907 räumt gekaufte Office-2019-Installationen ab.
  29. September: Windows 11 26H2 erscheint mit drei bekannten Problemen. Immerhin diesmal vorab bekannt.

Das ist ein einziger Monat. Kein Angreifer war beteiligt.

Betatester für Windows-Updates: Ihr neuer Nebenjob

Legen Sie jetzt die Drei-Tage-Regel über diese Liste. Wer am 8. September begonnen und brav nach drei Tagen die Breite erreicht hätte, wäre am 11. fertig gewesen. Also genau an dem Tag, an dem Microsoft zum ersten Mal zugab, dass etwas nicht stimmt. Der Hersteller verlangt von Ihnen ein Tempo, das er bei der eigenen Fehlerbestätigung nicht schafft.

Walter schlägt vor, das Testen zu verdichten: ein Pilotring unter echter Last, 24 bis 48 Stunden, dann die Breite. Technisch hat er recht, der RDS-Fehler wäre so aufgefallen. Schauen Sie sich aber an, was da passiert. Sie stellen die Testumgebung, die Testnutzer und das Monitoring, und Sie melden den Fehler. Früher nannte man das Qualitätssicherung und bezahlte Leute dafür.

Ich nenne es beim Namen. Der Pilotring ist die Alpha, die Breite ist die Beta, und die Lizenzgebühr ist das Eintrittsgeld. Dass Sie für das Privileg bezahlen, ist der eigentliche Geniestreich des Geschäftsmodells.

Die Gegenposition: Wo Microsoft leider recht hat

Jetzt der ärgerliche Teil. Die Bedrohung ist nicht erfunden. Zwei Zero-Days in einem Monat sind real, die Zeit bis zum Exploit schrumpft wirklich, und einen kaputten Patch kann man deinstallieren, einen übernommenen Domänencontroller nicht.

Gallaghers Hausaufgabenliste ist auch vernünftig: Angriffsfläche reduzieren, Identitäten absichern, segmentieren, nach Exposition priorisieren statt nach CVE-Zahl. Erkennen und Eindämmen seien inzwischen so wichtig wie das Patchen selbst, schreibt er. Stimmt. Er meint damit Angreifer. Es gilt genauso für seine Updates.

Microsoft hat also in der Sache recht und macht es sich trotzdem bequem. Die Dringlichkeit ist echt, die Qualität fehlt, und die Differenz zahlen Sie mit Nachtschichten.

Patchmanagement in der Kommune: Schneller, aber nicht blind

In einer Kommunalverwaltung patcht kein Team, sondern ein Mensch, manchmal anderthalb. Der Terminalserver trägt die Fachverfahren, und wenn er steht, steht das Rathaus. Für diese Umgebung hat in Redmond niemand ein Video gedreht.

Was ich für vertretbar halte:

1. Clients ohne Sonderrolle schnell patchen, mit einem kleinen Pilotring ab Tag eins, in dem mindestens ein VPN-Nutzer sitzt.
2. Aus dem Internet erreichbare Systeme und alles mit aktiv ausgenutzten Lücken innerhalb von drei Tagen, auch wenn es wehtut.
3. Je einen Server pro Rolle ab Tag eins testen, bei RDS mit echten An- und Abmeldungen über mehrere Stunden.
4. Den Rest im Wartungsfenster innerhalb einer Woche, nachdem das Release-Health-Dashboard und die einschlägigen Blogs gelesen sind.

Schreiben Sie das auf. Der IT-Grundschutz-Baustein OPS.1.1.3 verlangt zeitnahes Einspielen und vorheriges Testen, und ein Ringmodell mit festen Tagen ist dafür der Nachweis. Es erklärt auch, warum der Terminalserver am Donnerstag noch ungepatcht war: weil er am Freitag noch lief.

Fazit

Microsoft hat einen Gegner, der gefährlicher ist als jede Ransomware-Gruppe, und er sitzt im eigenen Haus. Die Drei-Tage-Regel wäre eine gute Idee, wenn die Updates drei Tage Vertrauen verdienten. Bis dahin ist sie eine Risikoverlagerung vom Hersteller zum Kunden, hübsch verpackt als Sicherheitsempfehlung.

Am 13. Oktober ist wieder Patchday. Prüfen Sie vorher, ob Sie ohne RDP an Ihre Server kommen, wer einen hängenden Terminaldienst innerhalb einer Stunde bemerkt und ob Ihre Deinstallation geübt ist. Sie werden gebraucht. Als Tester.

Quellen:

• Microsoft Mechanics / Tech Community, „Deploy Windows updates to counter AI-discovered threats” (07.07.2026);
• MSRC, Tom Gallagher, „A note on this month’s Patch Tuesday” (12.05.2026);
• SecurityWeek (08.09.2026); Malwarebytes (09.2026);
• BleepingComputer zu Always On VPN (09.2026);
• Der Windows Papst, Jörn Walter (02.10.2026);
• eigene Beiträge auf blog.grams-it.com (09.09., 11.09., 15.09., 17.09., 27.09., 30.09.2026)

Nach dem Rekordmonat Juli, in dem Microsoft rund 570 Schwachstellen stopfen musste, fällt der August-Patchday auf den ersten Blick etwas kleiner aus. Doch „kleiner” ist relativ: Mit über 400 behobenen Sicherheitslücken bewegt sich auch dieser Monat auf einem Niveau, das noch vor zwei Jahren als absoluter Ausnahmefall gegolten hätte. Dreistellige und mittlerweile fast vierstellige Patch-Zahlen sind zum Dauerzustand geworden.

Der Grund dafür ist strukturell und wird sich nicht mehr umkehren. Microsoft setzt inzwischen selbst auf KI-gestützte Systeme zur automatisierten Schwachstellensuche und hat angekündigt, dass genau das die Zahl der monatlichen Sicherheitsupdates dauerhaft nach oben treibt. Was der Codequalität langfristig guttut, bedeutet für Administratoren kurzfristig einen dauerhaft hohen Testaufwand.

Der eigentliche Unterschied zum Juli ist aber nicht die Menge, sondern die Brisanz einer einzelnen Lücke: Diesen Monat gibt es wieder einen Zero-Day, der bereits aktiv ausgenutzt wird, und zwar von einem staatlichen Akteur. Dieser Überblick zeigt, wo die Gefahr derzeit am größten ist und in welcher Reihenfolge Sie Ihre Systeme absichern sollten.

Die nackten Zahlen im Überblick

Bei den Gesamtzahlen lohnt ein genauer Blick, denn sie schwanken je nach Quelle erheblich. Microsoft selbst weist in seiner offiziellen Release-Note 421 Schwachstellen aus. Sicherheitsdienstleister wie Tenable kommen nach Abzug bestimmter Cloud- und Sonderfälle hingegen auf rund 398. Das ist eine reine Frage der Zählweise, die in den kommenden Tagen für unterschiedliche Zahlen in der Berichterstattung sorgen wird. Von diesen Lücken gelten 42 als kritisch, der ganz überwiegende Teil (355) als wichtig, eine einzelne als moderat. Innerhalb der kritischen Lücken dominiert erwartungsgemäß die Remotecodeausführung mit 37 Einträgen, hinzu kommen fünf kritische Rechteausweitungen. Für die Rollout-Planung hilfreich ist die Aufteilung nach Produkten: Allein 236 der Lücken entfallen auf Windows 11 und werden über das kumulative Update abgedeckt, weitere 98 auf Office (separate Office-Updates), gefolgt von SharePoint Server mit 30 und den Developer Tools mit 26.

Über alle Kategorien hinweg verteilen sich die Schwachstellen grob wie folgt: rund 176 Rechteausweitungen (Elevation of Privilege), etwa 110 Remotecodeausführungen (RCE), rund 86 Fälle von Informationsoffenlegung, 21 Spoofing-Lücken, 12 Denial-of-Service-Schwachstellen und 11 Umgehungen von Sicherheitsfunktionen. Besonders relevant sind in diesem Monat gleich drei Zero-Days: Eine davon wird bereits aktiv angegriffen, zwei weitere waren vor der Bereitstellung des Patches öffentlich bekannt.

Die kritischsten Brennpunkte im Detail

Wer diesen Patch-Zyklus überspringen möchte, sollte sich die folgende Liste genau ansehen. Mehrere Lücken betreffen zentrale Server-Rollen, die in praktisch jeder Windows-Domäne laufen: DNS-Server, DHCP und die Bereitstellungsdienste. Es folgt die detaillierte technische Aufarbeitung der wichtigsten Patches dieses Monats.

1. AFD.sys WinSock Elevation of Privilege (CVE-2026-68820)

CVSS-Score: 7,0

SCHWERWIEGENDKEIT: Hoch (aktiv ausgenutzt)

BEDROHUNG: Elevation of Privilege (Lokale Rechteausweitung auf SYSTEM)

EXPLOITS: Dies ist die einzige nachweislich aktiv ausgenutzte Schwachstelle dieses Monats und damit der wichtigste Patch überhaupt. Entdeckt und an Microsoft gemeldet wurde die Lücke von den Check-Point-Forschern Moshe Marelus und David Driker. Laut deren Analyse wurde sie im Rahmen gezielter Angriffe von der nordkoreanischen Lazarus-Gruppe eingesetzt, um über gefälschte Stellenangebote eine neue Variante des Kernel-Rootkits FudModule einzuschleusen. Auch Action1 stuft diese Schwachstelle als die mit Abstand wichtigste des gesamten Monats ein, schlicht weil die Ausnutzung bereits nachgewiesen ist. Kurios am Rande: Im CVSS-Vektor stuft Microsoft die Exploit-Reife formal als „unproven” ein, benennt die Lücke gleichzeitig aber als aktiv ausgenutzt. Diesen Widerspruch hat unter anderem die Zero Day Initiative süffisant angemerkt.

TECHNISCHE ZUSAMMENFASSUNG: Die Schwachstelle liegt im Ancillary Function Driver for WinSock (afd.sys), jenem Kernel-Treiber, der die Socket-Infrastruktur von Windows bereitstellt. Es handelt sich um einen Use-after-free-Fehler: Ein Speicherobjekt wird freigegeben und anschließend erneut referenziert. Ein lokal angemeldeter Angreifer mit niedrigen Rechten kann über eine speziell präparierte Anwendung eine Race Condition auslösen und diesen Zustand ausnutzen, um eigenen Code im Kontext des Kernels und damit mit SYSTEM-Rechten auszuführen. Eine Benutzerinteraktion ist nicht erforderlich.

AUSNUTZBARKEIT: Der Angriff setzt lokalen Zugriff und ein niedrig privilegiertes Konto voraus. Die Angriffskomplexität gilt als hoch, da der Angreifer das enge Zeitfenster der Race Condition treffen muss. Für einen staatlich unterstützten Akteur wie Lazarus ist das keine ernsthafte Hürde. Da afd.sys auf praktisch jedem Windows-System aktiv ist, ist die Angriffsfläche entsprechend groß.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Diese Lücke ist der klassische zweite Baustein einer Angriffskette. Nach dem initialen Zugang, etwa über ein manipuliertes Bewerbungsdokument, hebelt der Angreifer die Rechtetrennung des Systems aus und erlangt volle SYSTEM-Rechte. Mit dem nachgeladenen FudModule-Rootkit lassen sich anschließend Endpoint-Protection und Virenschutz blenden, Treiber manipulieren und dauerhafte, schwer auffindbare Persistenz verankern. Für Kommunen und KRITIS-nahe Einrichtungen ist der spionagegetriebene Hintergrund besonders brisant.

WORKAROUND: Einen sinnvollen technischen Workaround gibt es nicht; hier hilft nur das Einspielen des Updates. Flankierend sollte das EDR-System so konfiguriert werden, dass es verdächtige Kernel-Manipulationen und ungewöhnliche Kindprozesse erkennt. Ein konsequentes Least-Privilege-Prinzip und Application Control (zur Abwehr präparierter Dokumente aus Fake-Bewerbungen) senken das Restrisiko zusätzlich.

DRINGLICHKEIT: Höchste. Als einzige aktiv ausgenutzte Lücke des Monats gehört dieser Patch mit oberster Priorität auf alle Systeme, zuerst auf exponierte und besonders gefährdete Clients.

2. Windows User Profile Service – „LegacyHive” (CVE-2026-62832)

CVSS-Score: 7,8

SCHWERWIEGENDKEIT: Hoch

BEDROHUNG: Elevation of Privilege (Rechteausweitung auf Administrator)

EXPLOITS: Die Schwachstelle war bereits vor Verfügbarkeit des Patches öffentlich bekannt. Sie entspricht dem als „LegacyHive” veröffentlichten Proof-of-Concept des Sicherheitsforschers Nightmare Eclipse, also derselben Quelle, die bereits im Juni mit ihren BitLocker- und GreenPlasma-Veröffentlichungen für Aufsehen gesorgt hatte. Microsoft stuft die Ausnutzung als „eher wahrscheinlich” ein.

TECHNISCHE ZUSAMMENFASSUNG: Ursache ist eine fehlerhafte Link-Auflösung (Improper Link Resolution / Link Following) im Windows-Benutzerprofildienst. Ein authentifizierter Angreifer, der über Zugangsdaten für ein anderes lokales Konto verfügt, kann mit einer präparierten Anwendung erzwingen, dass die Registry-Hive eines anderen Benutzers geladen wird. Über symbolische Verknüpfungen wird der Dienst dabei auf geschützte Pfade umgelenkt. Meldet sich anschließend ein Administrator an dem kompromittierten Gerät an, lassen sich auf diesem Weg Befehle mit dessen Rechten ausführen.

AUSNUTZBARKEIT: Erforderlich ist ein lokaler, authentifizierter Zugriff. Besonders relevant ist die Lücke auf Mehrbenutzer-Systemen wie Terminalservern, Citrix-Umgebungen oder geteilten Arbeitsplätzen, auf denen ohnehin mehrere Benutzerkonten existieren.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Aus einem gewöhnlichen Standardbenutzer wird ein Administrator. In Kombination mit einer Phishing-Mail ergibt sich eine zuverlässige Rechteausweitung: Sobald der Angreifer einen Fuß in der Tür hat, kann er Virenschutz deaktivieren, Anmeldedaten aus dem LSASS-Speicher auslesen und sich lateral im Netzwerk ausbreiten.

WORKAROUND: Primär gilt: patchen. Flankierend helfen ein striktes Least-Privilege-Prinzip, der Verzicht auf gemeinsam genutzte Konten sowie ein Monitoring auf das ungewöhnliche Laden fremder Registry-Hives.

DRINGLICHKEIT: Hoch. Öffentlich bekannter PoC, von Microsoft als „eher wahrscheinlich” eingestuft.

3. Container Isolation FS Filter Driver (CVE-2026-72971)

CVSS-Score: 5,5

SCHWERWIEGENDKEIT: Hoch (öffentlich bekannt)

BEDROHUNG: Tampering (Lokale Manipulation)

EXPLOITS: Auch diese Lücke wurde vor Verfügbarkeit des Patches öffentlich bekannt; Microsoft schreibt die Entdeckung den Forschern „yhw & txz” zu. Anders als bei den beiden vorgenannten Zero-Days stuft Microsoft die Ausnutzung hier als „unwahrscheinlich” ein.

TECHNISCHE ZUSAMMENFASSUNG: Betroffen ist der Container Isolation FS Filter Driver (unionfs.sys), der das Overlay-Dateisystem für Windows-Container bereitstellt. Erneut liegt die Ursache in einer fehlerhaften Link-Auflösung: Über Link-Following lässt sich die Dateizugriffslogik des Treibers umlenken und für Manipulationen missbrauchen.

AUSNUTZBARKEIT: Der Angriff erfordert lokalen, authentifizierten Zugriff und ist praktisch nur auf Hosts relevant, die tatsächlich Windows-Container betreiben. Für reine Client-Arbeitsplätze ohne Container-Workloads ist das Risiko gering.

AUSWIRKUNGEN AUF DAS GESCHÄFT: In Container-Umgebungen kann die Lücke als Baustein dienen, um Dateien zu manipulieren oder Isolationsgrenzen aufzuweichen. Wo keine Container zum Einsatz kommen, ist die Angriffsfläche jedoch nicht gegeben.

WORKAROUND: Patch einspielen, insbesondere auf Container-Hosts. Umgebungen ohne Container haben hier keinen akuten Handlungsdruck.

DRINGLICHKEIT: Mittel. Öffentlich bekannt, aber als „unwahrscheinlich” eingestuft und mit stark begrenzter Angriffsfläche.

4. Windows DNS Server Remote Code Execution (CVE-2026-62878)

CVSS-Score: 9,8

SCHWERWIEGENDKEIT: Kritisch

BEDROHUNG: Remote Code Execution (RCE / wurmfähig)

EXPLOITS: Bislang wurden weder aktive Angriffe noch eine öffentliche Veröffentlichung beobachtet, und Microsoft bewertet die Ausnutzung offiziell als „unwahrscheinlich”. Die Zero Day Initiative hält diese Einschätzung allerdings für zu optimistisch, da die Lücke wurmfähig ist. In diesem Monat wurden gleich mehrere DNS-Server-RCEs geschlossen, darunter CVE-2026-62817 (Out-of-Bounds-Write, CVSS 8,8) und CVE-2026-62820 (Race Condition, CVSS 8,1). CVE-2026-62878 ist aber mit Abstand die schwerste.

TECHNISCHE ZUSAMMENFASSUNG: Es handelt sich um einen Stack-based Buffer Overflow im Windows-DNS-Server. Ein nicht authentifizierter Angreifer kann durch ein speziell präpariertes Paket an den DNS-Dienst Code mit erhöhten Rechten ausführen, ohne jede Benutzerinteraktion.

AUSNUTZBARKEIT: Der Angriff erfolgt netzwerkbasiert, ohne Anmeldung und ohne Interaktion. Entscheidend für die Tragweite: Der Windows-DNS-Server läuft in aller Regel auf den Domänencontrollern. Eine erfolgreiche Ausnutzung trifft damit direkt das Herz des Active Directory.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Eine Remotecodeausführung auf einem Domänencontroller ist der Worst Case. Der Angreifer kontrolliert damit sowohl die Namensauflösung als auch das Verzeichnis selbst und kann sich praktisch beliebig domänenweit ausbreiten. Durch die Wurmfähigkeit besteht zudem die Gefahr, dass ein einmal entwickelter Exploit sich selbstständig von System zu System weiterträgt.

WORKAROUND: Höchste Priorität beim Patchen der Domänencontroller und DNS-Server. Der DNS-Dienst sollte niemals unnötig aus dem Internet erreichbar sein, und auch die interne Exposition sollte über Segmentierung so weit wie möglich reduziert werden.

DRINGLICHKEIT: Kritisch. Domänencontroller zuerst patchen.

5. Windows Deployment Services TFTP Server RCE (CVE-2026-62893)

CVSS-Score: 9,8

SCHWERWIEGENDKEIT: Kritisch

BEDROHUNG: Remote Code Execution (RCE / Remotecodeausführung)

EXPLOITS: Aktive Angriffe sind bislang nicht bekannt, allerdings stuft Microsoft die Ausnutzung als „eher wahrscheinlich” ein. Sowohl Action1 als auch die Zero Day Initiative heben diese Lücke ausdrücklich als besonders beachtenswert hervor.

TECHNISCHE ZUSAMMENFASSUNG: Die Schwachstelle ist ein Use-after-free-Fehler im TFTP-Server-Bestandteil der Windows-Bereitstellungsdienste (Windows Deployment Services, WDS). Ein nicht authentifizierter Angreifer kann durch präparierte Pakete an den TFTP-/WDS-Dienst eine Codeausführung auf dem Server auslösen.

AUSNUTZBARKEIT: Der Angriff erfolgt netzwerkbasiert und ohne Authentifizierung. Betroffen sind Umgebungen, die WDS für PXE-Boot und die automatisierte Betriebssystem-Bereitstellung einsetzen, in der öffentlichen Verwaltung und in größeren Domänen keineswegs selten.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Eine Remotecodeausführung auf dem Deployment-Server ist deshalb so gefährlich, weil dieser Server Betriebssystem-Images an neue Clients verteilt. Ein kompromittierter WDS-Server eignet sich hervorragend für eine flächendeckende Kompromittierung, gewissermaßen eine Supply-Chain-Attacke innerhalb des eigenen OS-Rollouts.

WORKAROUND: Patch einspielen. Der WDS-/TFTP-Dienst sollte nicht exponiert werden; PXE-Netzsegmente gehören isoliert. Wird WDS nicht benötigt, sollte der Dienst deaktiviert werden.

DRINGLICHKEIT: Hoch bis kritisch, insbesondere überall dort, wo WDS aktiv im Einsatz ist.

6. Windows DHCP Server Remote Code Execution (CVE-2026-62823)

CVSS-Score: 8,8

SCHWERWIEGENDKEIT: Kritisch

BEDROHUNG: Remote Code Execution (RCE / Remotecodeausführung)

EXPLOITS: Aktive Angriffe sind derzeit nicht bekannt, Microsoft bewertet die Ausnutzung jedoch als „eher wahrscheinlich”.

TECHNISCHE ZUSAMMENFASSUNG: Ursache ist ein Heap-based Buffer Overflow im Windows-DHCP-Server. Ein nicht authentifizierter Angreifer im benachbarten Netzwerk kann durch ein manipuliertes Paket eine Codeausführung auslösen. Ergänzend hat Microsoft in diesem Monat 13 weitere, jeweils als „wichtig” eingestufte DHCP-Server-Lücken geschlossen, darunter acht Schwachstellen zur Informationsoffenlegung (CVSS 6,5) und fünf Rechteausweitungen (CVSS 7,8).

AUSNUTZBARKEIT: Der Angriff setzt einen Standort im benachbarten Netzsegment voraus, benötigt aber keine Authentifizierung. Da der DHCP-Server-Dienst üblicherweise auf zentraler Server-Infrastruktur betrieben wird, nicht selten auf einem Domänencontroller, ist die Tragweite erheblich.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Eine Remotecodeausführung auf dem DHCP-Server bringt einen zentralen Netzdienst unter die Kontrolle des Angreifers. Von dort aus lässt sich die weitere Ausbreitung im Netzwerk vorbereiten, bis hin zur vollständigen Kompromittierung der Server-Infrastruktur.

WORKAROUND: Patch einspielen und den Zugriff auf den DHCP-Dienst konsequent auf vertrauenswürdige Netzsegmente beschränken.

DRINGLICHKEIT: Hoch.

Weitere kritische Schwachstellen im Überblick

Neben den sechs ausführlich behandelten Lücken lohnt ein Blick auf mehrere weitere kritische Schwachstellen, die alle über das Netzwerk und ohne Authentifizierung angreifbar sind. Die Microsoft QUIC Remote Code Execution (CVE-2026-62815) und die Windows iSCSI Target Service Remote Code Execution (CVE-2026-65791) erreichen ebenfalls jeweils einen CVSS-Score von 9,8. Action1 weist bei der QUIC-Lücke ausdrücklich darauf hin, dass exponierte, verwundbare Dienste ein erhebliches Risiko darstellen, da weder Authentifizierung noch Benutzerinteraktion erforderlich sind. Bei den Active Directory Certificate Services wurde mit CVE-2026-62818 eine kritische RCE geschlossen (CVSS 8,8, Use-after-free), für alle Betreiber einer eigenen PKI ein Pflicht-Patch.

Aufmerksamkeit verdient auch SharePoint. CVE-2026-65665 (CVSS 8,8, Deserialisierung nicht vertrauenswürdiger Daten) ist als „eher wahrscheinlich” eingestuft. Das wiegt schwer, denn bereits die aktiv ausgenutzte SharePoint-RCE des Vormonats wurde genutzt, um Machine Keys von On-Premises-Servern zu stehlen. Bei Exchange sticht CVE-2026-62911 heraus, eine kritische Rechteausweitung über einen Authentifizierungs-Bypass (CVSS 8,0). Action1 skizziert das Schadenspotenzial drastisch: Aus dem Zugriff auf ein einzelnes Exchange-Konto könne die Kontrolle über sämtliche Postfächer werden, samt E-Mails, Anhängen und vertraulichem Schriftverkehr. Ebenfalls beachtenswert ist eine kritische Office-RCE (CVE-2026-64898, Heap-based Buffer Overflow): Hier genügt bereits die Anzeige einer präparierten Datei im Vorschaufenster (Preview Pane), ein Klick zum Öffnen ist nicht nötig. Hinzu kommen kritische RCEs in der Grafik-Komponente (GDI+, CVE-2026-62822) sowie in der Device Health Attestation (CVE-2026-71331, CVE-2026-66802).

Ein interessanter Sonderfall ist der High Performance Computing (HPC) Pack (CVE-2026-59124): technisch ein CVSS-9,8-Fehler und als „eher wahrscheinlich” eingestuft, aber nur als „wichtig” klassifiziert, weil HPC nicht standardmäßig aktiv ist. Wer HPC einsetzt, sollte diese Lücke dennoch nicht auf die lange Bank schieben. Bemerkenswert ist außerdem, dass gleich drei Schwachstellen im AFD.sys-WinSock-Treiber behoben wurden. Der Treiber hat sich zu einem verlässlichen Einfallstor für Rechteausweitungen entwickelt.

Auch abseits von Microsoft war der August ein arbeitsreicher Monat. Die schwerste Lücke überhaupt fand sich bei SAP: eine Autorisierungsschwachstelle im Data Hub Adapter der SAP Commerce Cloud (CVE-2026-58231) mit dem Höchstwert CVSS 10,0. Hinzu kamen weitere kritische SAP-Fixes, darunter eine Code-Injection in Manufacturing Integration and Intelligence (CVE-2026-44772, CVSS 9,9). N-able patchte eine bereits aktiv ausgenutzte Authentifizierungs-Umgehung in N-central, Metabase eine aktiv ausgenutzte SQL-Injection. Dazu kamen Updates von Adobe, Cisco (unter anderem ClamAV), VMware (Avi Load Balancer) und TP-Link (Omada).

Patchmanagement im Zeitalter von KI: Die Spielregeln ändern sich

Der August bestätigt, was sich seit Monaten abzeichnet: Manuelles Patchmanagement „mal eben am Wochenende” ist endgültig Geschichte. Wenn Microsoft selbst KI einsetzt, um Schwachstellen schneller zu finden, dann tun Angreifer das erst recht. Sie nutzen dieselbe Technologie, um veröffentlichte Patches per Reverse Engineering in kürzester Zeit zu analysieren und passende Exploits zu bauen. Das Zeitfenster zwischen Veröffentlichung und aktiver Ausnutzung schrumpft rasant, wie die AFD.sys-Lücke in diesem Monat einmal mehr zeigt.

Für Organisationen, gerade in der öffentlichen Verwaltung und im KMU-Umfeld, ist ein strukturierter, automatisierter und priorisierter Rollout-Prozess damit keine Kür mehr, sondern überlebenswichtig. Nicht zuletzt die verschärften Anforderungen der NIS-2-Richtlinie machen einen nachweisbaren, dokumentierten Patch-Prozess zur Pflicht.

Handlungsempfehlungen für Ihre IT-Infrastruktur

Priorisieren Sie in diesem Monat zuerst Ihre zentrale Server-Infrastruktur. Die kritischen RCE-Lücken in DNS-Server, DHCP-Server und den Bereitstellungsdiensten betreffen Rollen, die typischerweise auf Ihren Domänencontrollern und zentralen Servern laufen. Ein kompromittierter DC bedeutet den Verlust der gesamten Domäne. Diese Systeme gehören daher an den Anfang jeder Rollout-Welle.

Kümmern Sie sich unmittelbar danach um die aktiv ausgenutzte AFD.sys-Zero-Day-Lücke auf Ihren Clients. Da diese Schwachstelle bereits nachweislich für Angriffe verwendet wird, sollten insbesondere exponierte und risikobehaftete Endgeräte zeitnah abgesichert werden. Ein reines „Später erledigen wir das im normalen Zyklus” ist bei einer aktiv ausgenutzten Lücke keine vertretbare Option.

Führen Sie den Rollout trotz der Dringlichkeit unbedingt in kontrollierten Wellen durch. Bei über 400 Schwachstellen und dem entsprechend großen Umfang an Codeänderungen ist das Risiko von Kompatibilitätsproblemen erhöht. Testen Sie die Updates zuerst auf einer repräsentativen Gruppe von Testgeräten, bevor Sie sie in der Fläche verteilen. Die Priorisierung nach Kritikalität und die schnelle Verteilung dürfen nicht zu Lasten der Betriebsstabilität gehen.

Verifizieren Sie zuletzt den tatsächlichen Update-Status. Verlassen Sie sich nicht allein auf die Standardanzeige von Windows Update, sondern nutzen Sie professionelle Asset- und Compliance-Werkzeuge, um sicherzustellen, dass die KB-Stände auf allen Systemen lückenlos aktiv sind. Gerade bei den serverseitigen Lücken zählt jeder ungepatchte Host.

Neuerungen abseits der Sicherheit

Neben den reinen Sicherheitsfixes bringt das August-Update auch die Funktionsneuerungen des optionalen Juli-Vorschauupdates in die Fläche und erreicht mit dem Pflichtupdate nun alle Nutzer. Die sichtbarste Änderung betrifft den Datei-Explorer: Dateigrößen werden endlich nicht mehr ausschließlich in Kilobyte angezeigt, sondern je nach Umfang auch in Megabyte und Gigabyte. Zusätzlich lassen sich Ordner jetzt per mittlerer Maustaste direkt als neuer Tab im selben Fenster öffnen, und auch die Dateivorschau wurde überarbeitet.

Darüber hinaus verbessert Microsoft die Windows-Suche, die nun auch bei unklaren oder fehlerhaften Eingaben treffsicherer arbeitet und erstmals Dateinamen mit nur zwei Zeichen unterstützt. Windows Hello Enhanced Sign-in Security (ESS) unterstützt ab sofort kompatible externe Fingerabdruckleser, für Umgebungen mit biometrischer Anmeldung eine praktische Erweiterung. Und die Sprachsteuerung Voice Access erhält mit „Voice Isolation” eine Funktion, die Hintergrundgeräusche und fremde Stimmen herausfiltert, um Sprachbefehle zuverlässiger zu erkennen. Wie immer bündeln die Updates zudem neue Secure-Boot-Zertifikate, deren Verteilung sich über die kommenden Monate erstreckt.

Exchange Server: ein separates Sicherheitsupdate

Für Exchange Server liefert Microsoft am August-Patchday wie üblich ein eigenständiges Sicherheitsupdate aus, das unabhängig von den kumulativen Windows-Updates eingespielt werden muss. Das August-SU schließt sieben Schwachstellen in Exchange Server, von denen Microsoft genau eine als kritisch einstuft: die bereits erwähnte Rechteausweitung CVE-2026-62911 (CVSS 8,0). Aktiv ausgenutzt wird nach aktuellem Stand keine der sieben Lücken.

Bereitgestellt werden die Updates für Exchange Server 2016, Exchange Server 2019 sowie die Exchange Server Subscription Edition (SE). Exchange Online ist bereits geschützt. Hier besteht kein Handlungsbedarf, abgesehen von der Aktualisierung vorhandener On-Premises-Server und der Workstations mit den Exchange-Verwaltungstools. Wichtig für Bestandsumgebungen: Für Exchange 2016 und 2019 gibt es die Updates ausschließlich über das kostenpflichtige ESU-Programm (Phase 2). Wer dort keine Lizenz gebucht hat, erhält das August-SU nicht und verbleibt sicherheitstechnisch auf dem Stand von Juli 2025, ein weiterer deutlicher Fingerzeig, den Umstieg auf Exchange Server SE einzuplanen.

Für das August-Update selbst sind bislang keine Probleme bekannt. Bestehen bleibt allerdings ein bereits mit dem Juni-SU eingeführtes Verhalten: In Hybrid-Umgebungen können nach dessen Installation sogenannte Wrapper-Nachrichten in Shared Mailboxes auftauchen; Microsoft führt dies weiterhin als bekanntes Problem. Wer eine Hybrid-Konfiguration betreibt, sollte nach der Installation ein Auge darauf haben. Wie bei jedem Exchange-SU gilt außerdem: Das Update über eine administrative Eingabeaufforderung installieren, um unvollständige Installationen durch fehlende Berechtigungen zu vermeiden.

Wer mehrere Exchange-Server betreibt, sollte den Patchday ohnehin zum Anlass nehmen, den Exchange Health Checker laufen zu lassen. Das Skript zeigt neben dem Patchstand auch gleich, ob noch manuelle Schritte offen sind. Seit dem Juli-2026-Update prüft es zusätzlich, ob die längst abgekündigten Sicherheitsgruppen Exchange Domain Servers und Exchange Enterprise Servers noch im Active Directory existieren. Beide stammen aus Zeiten von Exchange 2000/2003, werden seit Exchange 2007 nicht mehr verwendet und liegen in über Jahre gewachsenen Umgebungen häufig noch in der OU „Users”. Das ist ausdrücklich kein reines Aufräumthema: Die Gruppen besitzen im Active Directory teils weitreichende Berechtigungen wie Write All Properties, ListChildren oder vereinzelt WriteDacl auf OUs und Domänenobjekten, deutlich mehr, als die aktuellen Exchange-Sicherheitsgruppen benötigen. Solange sie existieren, sind sie ein lohnendes Angriffsziel: Wer ihre Mitgliedschaft manipulieren kann, erbt diese Altrechte gleich mit. Microsoft empfiehlt daher, die Gruppen zu entfernen, und zwar selbst dann, wenn der letzte On-Premises-Exchange bereits abgebaut wurde.

Update-Pakete für Windows-Clients und -Server

Die folgende Übersicht fasst die kumulativen Updates dieses Patchdays für die noch unterstützten Windows-Versionen zusammen. Alle Pakete sind kumulativ und enthalten sämtliche Sicherheitsfixes bis zum Patchday.

Zu beachten: Windows 10 22H2 ist seit Oktober 2025 aus dem regulären Support gefallen; Sicherheitsupdates gibt es nur noch im Rahmen des ESU-Programms. Für Windows Server 2012/R2 ist ebenfalls eine ESU-Lizenz erforderlich, und Windows Server 23H2 hat den Support im Mai 2026 verlassen.

Ausgewählte kritische Sicherheitsupdates vom Patch Tuesday im August 2026

Die folgende Tabelle listet eine Auswahl der wichtigsten kritischen Schwachstellen dieses Monats. Die vollständige Liste aller rund 400 behobenen CVEs finden Sie im Microsoft Security Update Guide sowie in der Gesamtübersicht bei BleepingComputer.

Hinweis: Diese Tabelle stellt eine kuratierte Auswahl dar und erhebt keinen Anspruch auf Vollständigkeit. Maßgeblich ist stets der offizielle Microsoft Security Update Guide.