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 Patchday ist keine 24 Stunden alt, da steht das erste bestätigte Problem im Release-Health-Dashboard. Microsoft hat laut BleepingComputer am 13. Oktober eingeräumt, dass Standardbenutzer nach den jüngsten Windows-Updates keine Remote-Desktop-Verbindung mehr zu bestimmten Windows-11-Rechnern aufbauen können. Die Verbindung bricht mit dem Fehler 0xC000000D ab, die Meldung lautet sinngemäß, das übergebene Token sei ungültig. Betroffen sind Hosts mit Windows 11 24H2, 25H2 und 26H2, auf denen das Vorschauupdate KB5124010 vom 22. September oder ein späteres Update installiert ist und die Sicherheitsfunktion „Administrator protection” aktiv ist.

Das Problem ist nicht die Lücke, sondern die Kombination. Administrator protection ist standardmäßig aus. Wer die Funktion nie angefasst hat, bekommt den Fehler nicht zu sehen. Wer aber Microsofts Sicherheits-Baselines nutzt, hat sie laut BleepingComputer mit dem Oktober-Sicherheitsupdate automatisch eingeschaltet bekommen. Und genau in dieser Konstellation, Baseline plus KB5124010 oder neuer, fällt der Remote-Desktop-Zugang für alle, die keine lokalen Administratoren sind.

Ich habe im September an dieser Stelle über Microsofts anhaltend schlechte Update-Qualität geschrieben. Dieser Fall ist eine Fortsetzung, und er ist ärgerlicher als die meisten, weil hier nicht ein Treiber oder ein Codec kaputtgegangen ist, sondern Microsofts eigene Sicherheitsempfehlung mit Microsofts eigenem Update kollidiert.

Was Administrator protection eigentlich tun soll

Administrator protection ist Microsofts Versuch, das alte Problem der Benutzerkontensteuerung zu lösen. Bisher bekam ein Mitglied der lokalen Administratorengruppe bei der Anmeldung ein geteiltes Token: ein Standard-Token für den Alltag und ein Admin-Token, das bei Bedarf über den UAC-Dialog aktiviert wurde. Beide Tokens hingen am selben Profil, und Schadsoftware, die im Benutzerkontext lief, konnte sich auf verschiedenen Wegen an das Admin-Token heranarbeiten.

Laut Microsofts Dokumentation ändert Administrator protection diese Architektur grundlegend. Der Benutzer bleibt dauerhaft ohne Rechte. Braucht ein Vorgang Administratorrechte, muss er sich über Windows Hello oder Passwort ausdrücklich dafür authentifizieren. Windows erzeugt dann über ein verstecktes, systemverwaltetes und profilgetrenntes Konto ein isoliertes Admin-Token, gibt es nur dem anfragenden Prozess und vernichtet es, sobald der Prozess endet. Es gibt keine automatischen Elevations mehr, und das Admin-Profil ist vom normalen Profil getrennt.

Das ist, ohne Ironie, eine gute Idee. Just-in-time-Elevation mit Profiltrennung ist das, was Sicherheitsleute seit Jahren fordern. Die Funktion lief seit Oktober 2025 als Vorschau in Windows 11 24H2 und 25H2 und ist laut Learn seit dem August-Vorschauupdate KB5120998 allgemein verfügbar, abgeschaltet per Default, aktivierbar über Intune, CSP, Gruppenrichtlinie oder die Windows-Sicherheit-App.

Microsoft listet in derselben Dokumentation auch, wo die Funktion ausdrücklich nicht hingehört: auf Windows 365 Cloud PCs, auf Azure-Virtual-Desktop-Sitzungshosts, auf Windows Server, auf Geräten mit Hyper-V, bei Roaming-Profilen und bei Anwendungen, die Dateien über Profilgrenzen hinweg teilen. Remote-Anmeldungen auf Cloud PCs und AVD-Hosts werden nicht unterstützt. Für klassisches Remote Desktop auf einem Windows-11-Client steht dort nichts. Das wäre der Moment gewesen, in dem Microsoft die Kombination hätte testen müssen.

Wie der Fehler zustande kommt

Der Fehlercode 0xC000000D entspricht dem NT-Status STATUS_INVALID_PARAMETER: Eine Funktion hat ein Argument oder eine Token-Struktur bekommen, die sie nicht validieren konnte. Microsoft hat die Ursache nicht im Detail erklärt. Nach der Architekturbeschreibung liegt der Schluss aber nahe, dass die Anmeldung über Remote Desktop ein Token in der alten Form erwartet, das es unter Administrator protection nicht mehr gibt, und die Sitzung deshalb beim Aufbau abgewiesen wird.

Bemerkenswert ist, wen es trifft: Standardbenutzer, nicht Administratoren. Das ist die Gruppe, die von Administrator protection eigentlich unberührt bleiben sollte, weil sie nie ein Admin-Token hatte. Ein Mitarbeiter, der sich per RDP auf seinen Arbeitsplatzrechner im Büro schaltet, hat mit der neuen Elevation-Logik nichts zu tun. Trotzdem ist er derjenige, der ausgesperrt wird.

Die Zeitlinie macht den Fall besonders unglücklich. KB5124010 ist vom 22. September. Die Oktober-Sicherheitsupdates vom 13. Oktober enthalten denselben Code, weil Vorschauupdates in den nächsten Patchday einfließen. Gleichzeitig schalten die Oktober-Baselines Administrator protection ein. Wer also Baselines nutzt und den Patchday pünktlich eingespielt hat, bekommt beide Hälften des Problems am selben Tag. Microsoft hat das Known Issue laut WindowsForum am 13. Oktober eröffnet und noch am selben Vormittag auf „Mitigated” gesetzt, also auf entschärft, nicht auf behoben.

Der Workaround und was er kostet

Eine Korrektur gibt es nicht. Microsoft arbeitet laut BleepingComputer an einem Fix für ein künftiges Update, ohne Termin. Bis dahin lautet die Empfehlung: Administrator protection auf den betroffenen Remote-Desktop-Hosts vorübergehend abschalten. Microsoft rät ausdrücklich davon ab, KB5124010 oder das Oktober-Update zu deinstallieren, weil damit auch die Sicherheitsfixes des Patchdays und mehrere Fehlerbehebungen aus dem Vorschauupdate verschwinden würden, darunter die Korrektur für die im September kaputtgegangene Vertrauensstellung zur Domäne.

Der Schalter sitzt in der Richtlinie „Benutzerkontensteuerung: Typ des Administratorgenehmigungsmodus konfigurieren” unter Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Lokale Richtlinien, Sicherheitsoptionen. Dort von „Administratorgenehmigungsmodus mit Administrator protection” zurück auf den Legacy-Modus. In Intune heißt die Einstellung im Settings Catalog „User Account Control Type Of Admin Approval Mode” unter „Local Policies Security Options”, per CSP ist es UserAccountControl_TypeOfAdminApprovalMode. In allen Fällen braucht es einen Neustart, Microsoft betont das in der Dokumentation ausdrücklich.

Der Preis ist offensichtlich. Wer die Baseline übernommen hat, hat damit eine Sicherheitsverbesserung eingeschaltet, die er jetzt auf einem Teil der Flotte wieder zurücknehmen muss. Und wer nicht sauber arbeitet, nimmt sie gleich überall zurück, weil das einfacher ist als eine eigene Richtlinie nur für die RDP-Hosts. Ich halte das für die eigentliche Gefahr an diesem Fall: nicht die ausgesperrten Benutzer, sondern die Workarounds, die in drei Monaten niemand mehr zurückbaut.

Die Gegenposition: Baselines sind keine Pflicht

Fairerweise: Microsoft hat Administrator protection nicht heimlich auf alle Geräte geschoben. Die Funktion ist auf einer normalen Installation aus und bleibt aus. Wer sie über die Baseline bekommen hat, hat sich für die Baseline entschieden, und Microsoft sagt seit Jahren, dass Baselines vor dem Ausrollen in der eigenen Umgebung getestet werden müssen. Man kann argumentieren, dass genau das hier passiert ist: Eine Organisation testet die neue Baseline, stellt den RDP-Fehler fest, nimmt die Einstellung für ihre Hosts heraus, fertig. Das ist der vorgesehene Prozess.

Das Argument trägt, aber nur halb. Eine Baseline ist Microsofts eigene Empfehlung, was sicher ist. Wenn diese Empfehlung mit Microsofts eigenem Vorschauupdate kollidiert, das drei Wochen vorher erschienen ist, dann hat niemand bei Microsoft die beiden Dinge zusammen getestet. Und das Vorschauupdate heißt Vorschau, weil es genau diese Fehler vorher finden soll. KB5124010 war drei Wochen lang in der Fläche, bevor es Teil des Pflichtupdates wurde. Das Problem ist erst aufgefallen, als die Baseline den Schalter umlegte. Vorschau und Baseline sind bei Microsoft offenbar zwei Teams, die nicht miteinander reden.

Warum das kein Einzelfall ist

Remote Desktop ist für Microsoft seit anderthalb Jahren ein wunder Punkt. Im März 2025 musste ein Fehler per Known Issue Rollback entschärft werden, der RDP- und RDS-Verbindungen nach den Januar-Updates abbrechen ließ. Im September 2026 brachte das Sicherheitsupdate KB5124008 laut Microsofts Release-Health-Seite Remote Desktop Services auf Windows Server zum Stillstand: Verbindungen brachen nach wenigen Minuten ab, Server hingen bei „Bitte warten Sie auf die Remotedesktopkonfiguration”, dazu reagierten MMC, der RDS-Lizenzierungsdiagnostiker und der Explorer nicht mehr. Microsoft brauchte ein Out-of-Band-Update (KB5129195) am 14. September, um das zu reparieren. Derselbe Patchday brachte eine verlorene Vertrauensstellung zur Domäne für Credential-Guard-geschützte Computerkonten, USB-Audio-Ausfälle, verschwundene Plan9-Freigaben in Hyper-V-Linux-VMs und schwarze Bildschirme nach der Anmeldung auf AVD-Hosts. Der AC-3-Codec-Fehler aus KB5124010 steht seit dem 2. Oktober als „Confirmed” ohne Lösung im Dashboard.

Das Muster ist immer dasselbe: Microsoft schiebt Sicherheitsänderungen mit tieferen Eingriffen ins System, Machine Identity Isolation, Administrator protection, Secure-Boot-Zertifikate, und die Nebenwirkungen zeigen sich erst im Betrieb. Ich bezweifle nicht, dass diese Änderungen nötig sind. Ich bezweifle, dass monatliche Pakete mit 1.400 Schwachstellen und gleichzeitigen Architekturänderungen noch so getestet werden, wie es früher der Fall war. Die Zero Day Initiative hat beim Oktober-Patchday angemerkt, dass die Zahl der Lücken schneller wächst als die der tatsächlichen Angriffe. Für die Update-Qualität gilt das Umgekehrte: Die Zahl der Known Issues wächst schneller als die der Lösungen.

Fazit

Wer Microsofts Sicherheits-Baselines nutzt und Windows-11-Rechner als Remote-Desktop-Hosts für Standardbenutzer betreibt, muss jetzt handeln. Nicht durch Deinstallation des Oktober-Updates, sondern durch eine eigene, eng begrenzte Richtlinie, die Administrator protection nur auf diesen Hosts auf den Legacy-Modus zurücksetzt. Diese Richtlinie gehört mit Datum und Grund dokumentiert, damit sie zurückgebaut wird, sobald Microsoft den Fix liefert. Wer Baselines nicht nutzt und die Funktion nie eingeschaltet hat, ist nicht betroffen und sollte sie auch jetzt nicht einschalten, bis die Lösung da ist.

Und Microsoft? Vorschauupdates und Baselines müssen zusammen getestet werden, bevor beide im selben Monat auf dieselben Geräte treffen. Sonst wird aus jedem „secure by default” ein „locked out by default”.

Quellen:

• Microsoft Learn: Administrator protection (Stand 23.09.2026),
• Microsoft: Windows 11, version 24H2 known issues and notifications (Stand 09.10.2026),
• Microsoft Support: KB5124010 (OS Builds 26300.9550, 26200.9550, 26100.9550) Preview (22.09.2026, Known Issue vom 13.10.2026),
• BleepingComputer: Microsoft: Recent Windows updates may trigger Remote Desktop failures (14.10.2026),
• BleepingComputer: Microsoft: September updates cause RDS failures on Windows Server (09/2026),
• WindowsForum: Windows 11 RDP 0xC000000D: Fix Non-Admin Logins Blocked by Administrator Protection (14.10.2026, KI-gestützt)

um zweiten Mal in Folge bricht Microsoft den eigenen Rekord: Der Patchday vom 13. Oktober 2026 schließt je nach Zählweise zwischen 1.407 und 1.415 Schwachstellen. Dustin Childs von der Zero Day Initiative hat das in seinem Review treffend eingeordnet: Dieser eine Monat übersteigt das Volumen jedes einzelnen Jahres, das Microsoft je veröffentlicht hat. Zum Vergleich: Das gesamte Jahr 2023 brachte es auf 914 CVEs. Vierstellige Patch-Zahlen mit sechsstelligen CVE-Nummern sind damit Realität, und ich sehe nichts, was diesen Trend in den nächsten Monaten umkehren würde.

Die Ursache ist dieselbe wie im September. Microsoft findet mit KI-gestützter Schwachstellensuche deutlich mehr Fehler als früher, und die Zero Day Initiative weist darauf hin, dass die Zahl der tatsächlich ausgenutzten Zero-Days nicht mitwächst: 15 Microsoft-Zero-Days von Januar bis Oktober 2026 gegenüber 17 im gleichen Zeitraum 2023. Die Entdeckung skaliert schneller als die Ausnutzung. Wer nach reiner CVE-Zahl priorisiert, verbrennt Ressourcen an den falschen Stellen.

Das heißt nicht, dass dieser Monat harmlos wäre. Es gibt einen aktiv ausgenutzten Zero-Day, der die Mark-of-the-Web-Schutzfunktion umgeht und für den laut Action1 bereits funktionsfähiger Exploit-Code existiert, eine kritische Remotecodeausführung in den Active Directory Domain Services, sechs kritische DHCP-Server-Lücken und eine Exchange-RCE, die technisch wurmfähig ist. Dazu kommt ein Stichtag, an dem gleich mehrere Produkte aus dem Support fallen. Dieser Überblick zeigt, was zuerst auf die Server gehört und was bis zur nächsten Rollout-Welle warten kann.

Die nackten Zahlen im Überblick

Wie jeden Monat weichen die Gesamtzahlen je nach Quelle ab, diesmal deutlicher als sonst. BleepingComputer zählt 1.411 Schwachstellen und schließt dabei 348 weitere aus, die Microsoft bereits früher im Monat für Azure-Dienste, Mariner, Dataverse und Partner Center veröffentlicht hatte. Tenable kommt auf 1.407 CVEs, davon 69 kritisch, 1.337 wichtig und eine mit niedriger Einstufung. Action1 nennt 1.409 Patches und 80 kritische Lücken, zählt dafür nur zwei Zero-Days. Die Zero Day Initiative sieht 1.415 neue CVEs. Günter Born gibt in seiner Security Update Summary 70 kritische an, ebenso BleepingComputer: 57 davon sind Remotecodeausführungen, 11 Rechteausweitungen und 2 Spoofing-Lücken. Ich verwende im Folgenden die BleepingComputer-Zahlen, weil sie sich auf die am Patchday selbst veröffentlichten Lücken beschränken. Die Abweichung bei den kritischen Lücken (69 bis 80) dürfte daran liegen, ob Azure- und Mariner-Einträge mitgezählt werden.

Nach Kategorien verteilt sich das Paket laut BleepingComputer ungefähr so: 677 Rechteausweitungen (Elevation of Privilege), 317 Remotecodeausführungen (RCE), 254 Fälle von Informationsoffenlegung, 73 Denial-of-Service-Lücken, 40 Umgehungen von Sicherheitsfunktionen und 28 Spoofing-Schwachstellen. Tenable rechnet das in Anteile um: 47,9 Prozent Rechteausweitungen, 22,3 Prozent RCE.

Für die Rollout-Planung ist die Produktverteilung interessanter. Tenable führt 301 betroffene Produkte und Komponenten auf. Ganz vorn liegt Excel mit 69 CVEs, gefolgt von der DNS-Server-Rolle mit 52, dem Windows-Kernel mit 46, dem Windows Installer mit 38 und dem Win32-Kernel-Subsystem mit 36. SharePoint bringt es auf 34, SQL Server auf 22. Dass die DNS-Server-Rolle auf Platz zwei steht, sollte jeden aufhorchen lassen, der Domänencontroller betreibt, denn dort läuft der DNS-Dienst in aller Regel.

Drei Zero-Days gibt es diesen Monat: einer wird aktiv angegriffen, zwei weitere waren vor dem Patch öffentlich bekannt. Die Zero Day Initiative hat zusätzlich 59 Lücken als wurmfähig identifiziert, also netzwerkbasiert ohne Authentifizierung und ohne Benutzerinteraktion ausnutzbar. Diese Zahl ist für mich die eigentliche Schlagzeile des Monats.

Risiko-Kohorten: Microsofts Antwort auf die eigene Flut

Neu in diesem Monat ist ein Versuch Microsofts, die Masse handhabbar zu machen. Unter dem Titel Using risk cohorts to prioritize security updates gruppiert das MSRC verwandte Schwachstellen in 15 Kohorten. Die größten für Oktober: 136 Lücken in Dateisystemen, Speicher und Backup, 135 in Office-Dokumenten und Mail-Clients, 131 in Grafik-, Medien- und Content-Verarbeitung, 109 an den Rechtegrenzen von Kernel und Core sowie 103 in Installation, Bereitstellung und Update-Diensten. Microsoft stellt klar, dass die Gruppen experimentell sind, keine offiziellen Kategorien darstellen und die Bewertung einzelner CVEs nicht ersetzen. Eine PDF-Zuordnung aller Oktober-CVEs zu ihren Kohorten liegt bei.

Dustin Childs merkt dazu trocken an, dass man so etwas früher Security Bulletin nannte: eine Komponente, mehrere CVEs, ein Dokument. Action1 geht in seinem Sysadmin-Brief einen ähnlichen Weg und sortiert nach dem, was man betreibt: Identitätsinfrastruktur zuerst (AD FS, AD, DNS, DHCP), dann SharePoint, dann Endgeräte, dann Geschäftsserver, dann die Appliances am Netzrand. Ich sehe das ähnlich. Der Kohorten-Ansatz ist richtig, kommt aber spät, und ob er in Patch-Management-Werkzeugen ankommt, muss sich erst zeigen. Für eine kleine Verwaltungs-IT ohne eigenes Security-Team ist jede Vorsortierung hilfreich, solange sie nicht dazu verführt, die Kohortengröße mit Gefährlichkeit zu verwechseln.

Die kritischsten Brennpunkte im Detail

Mehrere Lücken betreffen Server-Rollen, die in praktisch jeder Windows-Domäne laufen: Active Directory, DHCP, DNS, Remote Desktop Gateway. Dazu kommt der aktiv ausgenutzte Zero-Day auf den Clients. Es folgt die technische Aufarbeitung der Patches, die ich diesen Monat zuerst einspielen würde.

1. Windows Shell Security Feature Bypass (CVE-2026-96951)

CVSS-Score: 8,8

SCHWERWIEGENDKEIT: Hoch (==aktiv ausgenutzt==)

BEDROHUNG: Security Feature Bypass (Umgehung von Mark of the Web)

EXPLOITS: Dies ist die einzige nachweislich aktiv ausgenutzte Schwachstelle dieses Monats. Microsoft hat keine Angaben dazu gemacht, wer sie entdeckt hat oder wie die Angriffe im Detail ablaufen. Action1 führt die Exploit-Code-Reife als „Functional”, es existiert also funktionsfähiger Exploit-Code, nicht nur ein theoretischer Nachweis. Tenable ordnet die Lücke als dritte in freier Wildbahn ausgenutzte Windows-Shell-Lücke des Jahres 2026 ein, nach CVE-2026-21510 im Februar und CVE-2026-32202 im April. Die Zero Day Initiative verweist darauf, dass Angreifer seit 2024 immer wieder Wege um Mark of the Web herum gefunden haben; diesmal ist es die Shell statt SmartScreen, das Ergebnis ist dasselbe.

TECHNISCHE ZUSAMMENFASSUNG: Ursache ist eine unzureichende Neutralisierung von Sonderzeichen in Befehlen, also eine Command Injection (CWE-77) in der Windows-Shell. Ein Angreifer schickt dem Opfer eine präparierte Datei, etwa per E-Mail, Messenger oder über eine Webseite. Öffnet der Nutzer den Anhang oder Link, umgeht die Datei die Mark-of-the-Web-Kennzeichnung (MOTW), mit der Windows aus dem Internet stammende Dateien markiert und die nachgelagerte Schutzmechanismen wie SmartScreen oder die geschützte Office-Ansicht auslöst.

AUSNUTZBARKEIT: Der Angriff erfolgt über das Netzwerk, braucht keine Rechte, aber eine Benutzerinteraktion. Das ist in der Praxis keine Hürde: Phishing mit Dateianhang ist der häufigste Erstzugang überhaupt. Betroffen sind laut Action1 Windows 10 ab Version 1607, Windows 11 von 23H2 bis 26H1, Windows Server 2012 R2 bis 2025 sowie Visual Studio 2026. Ein Kommentator bei Born weist zu Recht darauf hin, dass MOTW ohnehin nur auf NTFS- und ReFS-Laufwerken existiert; auf FAT- oder exFAT-Datenträgern gibt es die Kennzeichnung gar nicht.

AUSWIRKUNGEN AUF DAS GESCHÄFT: MOTW ist der erste Baustein der Verteidigung gegen Dokument-Malware. Fällt er, laufen Makro-Sperren und Warndialoge ins Leere, und ein Anhang aus einer Bewerbungs- oder Rechnungsmail verhält sich wie eine lokal erstellte Datei. Für Verwaltungen mit hohem Mailaufkommen aus unbekannten Quellen, also für praktisch jedes Bürgerbüro, ist das der gefährlichste Patch des Monats.

WORKAROUND: Microsoft nennt keinen. Flankierend: Attack Surface Reduction Rules gegen Office-Kindprozesse, Application Control und ein EDR, das verdächtige Prozessketten nach dem Öffnen von Anhängen erkennt. Wer Anhänge aus dem Internet ohnehin in einer Sandbox öffnet, hat einen Puffer.

DRINGLICHKEIT: Höchste. Auf alle Clients, zuerst auf die, die externe Mails empfangen. Das Update erfordert einen Neustart.

2. .NET Framework Security Feature Bypass (CVE-2026-108398)

CVSS-Score: 8,8

SCHWERWIEGENDKEIT: Hoch (öffentlich bekannt)

BEDROHUNG: Security Feature Bypass (Umgehung von Windows Defender Application Control)

EXPLOITS: Die Lücke war vor Verfügbarkeit des Patches öffentlich bekannt. Entdeckt und gemeldet hat sie James Forshaw von Google Project Zero. Aktive Angriffe sind nicht bekannt, Microsoft stuft die Ausnutzung aber als „eher wahrscheinlich” ein.

TECHNISCHE ZUSAMMENFASSUNG: Ursache ist ein unsicherer Suchpfad (Untrusted Search Path, CWE-426) im .NET Framework. Ein authentifizierter Angreifer mit niedrigen Rechten platziert eine präparierte .NET-Assembly auf dem System und registriert sie so, dass ein geschützter Prozess sie lädt. Gelingt das, umgeht der Code die Richtlinien von Windows Defender Application Control (WDAC) und läuft im Kontext des geschützten Prozesses. Eine Benutzerinteraktion ist nicht erforderlich, der Scope ist „changed”, der Angreifer verlässt also die Sicherheitsgrenze der verwundbaren Komponente.

AUSNUTZBARKEIT: Lokaler Zugriff mit einem gültigen Konto genügt. Relevant ist die Lücke vor allem dort, wo WDAC die zentrale Verteidigungslinie ist, etwa auf gehärteten Verwaltungsarbeitsplätzen oder Admin-Workstations. Wichtig für den Rollout: Die .NET-Framework-Updates sind eigene Pakete außerhalb des kumulativen Windows-Updates. Action1 nennt für Windows 10 21H2 die KBs 5127689, 5127690, 5127692 und 5127694, für Windows Server 2022 KB5127693, für Windows Server 2025 KB5127690 und für Windows 11 26H1 KB5127691.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Wer Application Control einsetzt, verlässt sich darauf, dass nur freigegebener Code läuft. Diese Lücke höhlt genau diese Garantie aus. Als zweiter Baustein nach einem Phishing-Erstzugang ist sie eine saubere Möglichkeit, Schutzmaßnahmen stillzulegen.

WORKAROUND: Microsoft nennt keinen. Darüber hinaus die WDAC-Richtlinien auf überbreite Freigaben für .NET-Pfade prüfen.

DRINGLICHKEIT: Hoch, zumal Forshaw erfahrungsgemäß Details veröffentlicht, sobald der Patch verfügbar ist.

Der dritte Zero-Day, CVE-2026-92707, ist ein Denial-of-Service in MessagePack-CSharp (CVSS 5,3, moderat), der von dritter Seite veröffentlicht wurde und den Microsoft jetzt in sein Release aufgenommen hat. Action1 zählt ihn nicht mit, daher die „zwei Zero-Days” dort. Für die meisten Umgebungen ist das ein Entwicklerthema, kein Server-Notfall.

3. Active Directory Domain Services Remote Code Execution (CVE-2026-70229)

CVSS-Score: 8,1

SCHWERWIEGENDKEIT: ==Kritisch==

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

EXPLOITS: Aktive Angriffe sind nicht bekannt. Microsoft stuft die Ausnutzung als „eher wahrscheinlich” ein. Die Zero Day Initiative führt die Lücke in ihrer Liste wurmfähiger Schwachstellen.

TECHNISCHE ZUSAMMENFASSUNG: Ursache ist laut Action1 eine fehlerhafte Autorisierung (Incorrect Authorization, CWE-863) in AD DS. Ein nicht authentifizierter Angreifer schickt ein präpariertes Paket an den AD-DS-Dienst und erreicht damit Codeausführung auf dem Domänencontroller. Die Angriffskomplexität ist hoch: Es müssen bestimmte Netzwerkkonfigurationen und Timing-Bedingungen zusammenkommen. Vier weitere AD-DS-Lücken (CVE-2026-88165 als RCE, dazu drei Denial-of-Service-Fälle) wurden parallel geschlossen.

AUSNUTZBARKEIT: Netzwerkbasiert, ohne Anmeldung, ohne Interaktion. Der Angreifer muss den Domänencontroller erreichen können, was in flachen Verwaltungsnetzen ohne Segmentierung jeder kompromittierte Client kann. Betroffen sind Windows Server 2012 bis 2025 inklusive Server Core sowie die Clients, die den Code mitbringen.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Codeausführung auf dem Domänencontroller ist der Worst Case, ohne Umweg. Der Angreifer kontrolliert damit das Verzeichnis, alle Konten und über Gruppenrichtlinien jedes Gerät in der Domäne.

WORKAROUND: Keiner. Domänencontroller zuerst patchen und den Zugriff auf AD-Ports aus Client-Segmenten über Firewall-Regeln auf das Nötige beschränken.

DRINGLICHKEIT: Kritisch. Mit CVE-2026-96951 zusammen der Patch, den ich keinen Tag liegen lassen würde.

4. Windows DHCP Server Remote Code Execution (CVE-2026-96934)

CVSS-Score: 9,8

SCHWERWIEGENDKEIT: ==Kritisch==

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

EXPLOITS: Aktive Angriffe sind nicht bekannt. Insgesamt sind diesen Monat sechs DHCP-Server-Lücken wurmfähig (CVE-2026-96934, CVE-2026-88117, CVE-2026-88119, CVE-2026-88120, CVE-2026-96320, CVE-2026-69830), fünf davon stuft Microsoft als kritisch ein. CVE-2026-96934 ist mit 9,8 die schwerste; CVE-2026-88117, CVE-2026-88119, CVE-2026-88120 und CVE-2026-88171 erreichen jeweils 8,1, verlangen aber das Gewinnen einer Race Condition.

TECHNISCHE ZUSAMMENFASSUNG: CVE-2026-96934 ist ein Use-after-free-Fehler. Ein nicht authentifizierter Angreifer sendet präparierte Pakete an den DHCP-Server-Dienst und erreicht Codeausführung oder bringt den Dienst zum Stillstand. Die entscheidende Einschränkung, die nur Action1 nennt: Die Lücke betrifft DHCP-Server im Failover-Modus. Wer DHCP-Failover für Hochverfügbarkeit konfiguriert hat, hat damit genau die Konfiguration, die der Angriff braucht. Die drei 8,1er-Lücken sind ebenfalls Use-after-free-Fehler mit Race Condition, CVE-2026-88171 ein Double Free. Ergänzend gibt es eine kritische RCE im DHCP-Client (CVE-2026-70250, CVSS 8,8, Use-after-free plus Race Condition), die laut Action1 Windows Server 2012 bis 2025 sowie Windows 10 1607 und 1809 betrifft.

AUSNUTZBARKEIT: DHCP ist per Definition ein Dienst, der unauthentifizierte Anfragen aus dem lokalen Netz beantwortet. Jedes Gerät im selben Segment ist ein möglicher Absender, inklusive eines mitgebrachten Notebooks am Besprechungsraum-Port. Die Client-Lücke braucht einen Angreifer im benachbarten Netz.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Wie im September läuft der DHCP-Server-Dienst in kleinen Verwaltungen häufig direkt auf einem Domänencontroller, und DHCP-Failover zwischen zwei DCs ist ein verbreitetes Setup. Dann ist eine DHCP-RCE eine DC-RCE. Die Client-Lücke wiederum macht aus einem Rogue-DHCP-Server im Gästenetz ein Werkzeug zur Übernahme von Servern.

WORKAROUND: Patchen. DHCP-Server vom Domänencontroller trennen, wo das noch nicht geschehen ist. DHCP-Snooping auf den Switches aktivieren, um Rogue-Server zu blockieren; das hilft gegen die Client-Lücke. Failover abzuschalten ist laut Action1 eine Option, aber nur nach Abwägung der Verfügbarkeit.

DRINGLICHKEIT: Kritisch, unmittelbar nach den Domänencontrollern. Zuerst die Failover-Paare identifizieren.

5. Microsoft Exchange Server Remote Code Execution (CVE-2026-70571)

CVSS-Score: 8,1

SCHWERWIEGENDKEIT: ==Kritisch==

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

EXPLOITS: Aktive Angriffe sind nicht bekannt, Microsoft bewertet die Ausnutzung aber als „eher wahrscheinlich”. Die Zero Day Initiative nennt die Lücke technisch wurmfähig, hält eine tatsächliche Wurmwelle aber für unwahrscheinlich: Microsoft schreibt, der Angreifer brauche tiefes Wissen über die Zielumgebung, und ein Erfolg sei nicht garantiert.

TECHNISCHE ZUSAMMENFASSUNG: Es handelt sich um einen stapelbasierten Pufferüberlauf. Ein nicht authentifizierter Angreifer schickt eine präparierte E-Mail an einen verwundbaren Exchange-Server. Die Mail löst einen internen Prozess zur Inhaltskonvertierung aus, und in diesem Prozess kommt es zur Codeausführung. Eine Benutzerinteraktion ist nicht erforderlich, weil der Server die Mail selbst verarbeitet.

AUSNUTZBARKEIT: Jeder Exchange-Server, der Mails aus dem Internet annimmt, ist erreichbar. Das ist der Sinn eines Mailservers. Die Einschränkung „tiefes Wissen über die Zielumgebung” senkt die Wahrscheinlichkeit eines Massenangriffs, nicht die eines gezielten.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Codeausführung auf dem Mailserver bedeutet Zugriff auf jedes Postfach, jeden Anhang, jeden Kalender. Dazu kommt im selben Update eine Spoofing-Lücke mit CVSS 9,3 (CVE-2026-70279), ebenfalls als „eher wahrscheinlich” eingestuft: Ein Klick eines Administrators auf einen präparierten Link reicht, um Organisationsdaten lesen oder ändern zu können. Zwei Rechteausweitungen mit CVSS 8,8 (CVE-2026-96940, CVE-2026-77910) runden das Bild ab.

WORKAROUND: Das Exchange-SU einspielen (siehe eigener Abschnitt). Admin-Konten für Exchange nicht zum Surfen oder Mailen verwenden; das entschärft die Spoofing-Lücke.

DRINGLICHKEIT: Hoch bis kritisch für jeden On-Premises-Exchange, der aus dem Internet erreichbar ist.

6. Microsoft SharePoint Elevation of Privilege (CVE-2026-102866)

CVSS-Score: 8,1

SCHWERWIEGENDKEIT: ==Kritisch==

BEDROHUNG: Elevation of Privilege (Authentifizierung als beliebiger Benutzer)

EXPLOITS: Aktive Angriffe sind nicht bekannt. Die Zero Day Initiative hebt die Lücke aus den 34 SharePoint-CVEs dieses Monats heraus, weil sie die einzige kritische und die einzige ohne Authentifizierung ausnutzbare ist.

TECHNISCHE ZUSAMMENFASSUNG: Ursache ist eine fehlerhafte Prüfung kryptografischer Signaturen (CWE-347). Wer ein gültiges Proof-Token eines bestimmten Benutzers in die Hände bekommt, kann es verändern, an den Server schicken und sich als dieser Benutzer authentifizieren. Die Angriffskomplexität ist hoch, weil laut Action1 bestimmte Protokolleinstellungen vorliegen müssen. Betroffen ist ausschließlich SharePoint Server Subscription Edition, das Update ist KB5002927.

AUSNUTZBARKEIT: Die Hürde ist das Token. Die ZDI merkt an, dass es dafür mehrere Wege gibt. Wer sich an die SharePoint-Vorfälle der letzten Monate erinnert, bei denen Machine Keys von On-Premises-Servern gestohlen wurden, weiß, wie realistisch das ist.

AUSWIRKUNGEN AUF DAS GESCHÄFT: SharePoint ist in vielen Verwaltungen das Dokumentenmanagement. Ein Angreifer, der sich als Sachgebietsleiter authentifizieren kann, liest, was dieser lesen darf, und das ist in der Regel viel.

WORKAROUND: Patchen. SharePoint-Server grundsätzlich nicht direkt aus dem Internet erreichbar machen.

DRINGLICHKEIT: Hoch für alle SharePoint-SE-Installationen.

Weitere kritische Schwachstellen im Überblick

Die Liste der kritischen Netzwerk-RCEs ist diesen Monat lang. Microsoft QUIC bringt zwei Lücken mit CVSS 9,8 (CVE-2026-100219, CVE-2026-105016), die neben Windows auch .NET 8 bis 11 und Visual Studio betreffen. Der PostScript-Druckertreiber hat ebenfalls zwei (CVE-2026-70147, CVE-2026-70153), ausgelöst durch einen präparierten Druckauftrag über das Netz, dazu eine dritte mit 8,8 (CVE-2026-108467), für die ein authentifizierter Benutzer mit niedrigen Rechten genügt. Das Message Queuing hat eine 9,8er-RCE (CVE-2026-100202), Windows Text Shaping ebenfalls (CVE-2026-97814). Im Remote Desktop Gateway sind drei Lücken wurmfähig, darunter die kritische CVE-2026-70187, ein Use-after-free im Gateway-Dienst; wer RD Gateway als Homeoffice-Zugang betreibt, sollte das vor dem Wochenende erledigen. Hyper-V erhält zwei kritische RCEs (CVE-2026-102214, CVE-2026-105733), bei denen ein Angreifer mit niedrigen Rechten in einer VM Code auf dem Host ausführt, die zweite auch aus verschachtelter Virtualisierung heraus. Der Network Policy Server, in vielen Verwaltungen die RADIUS-Instanz für WLAN und VPN, bringt vier wurmfähige Lücken. Die Windows Deployment Services bekommen erneut eine kritische RCE (CVE-2026-88174), der Network Device Enrollment Service eine kritische RCE durch schwache Authentifizierung (CVE-2026-69802). Und im DNS-Server steckt neben den beiden wurmfähigen Lücken eine weitere kritische RCE (CVE-2026-96113), für die Microsoft keinen CVSS-Score veröffentlicht hat; Action1 führt sie trotzdem in der Kategorie „Same Day Deployment”.

Zwei Lücken verdienen aus Verwaltungssicht einen eigenen Satz. CVE-2026-108457 ist eine kritische RCE in Windows PDF (CVSS 8,1): Ein präparierter PDF-Anhang per E-Mail löst sie auf Systemen aus, die PDF-Inhalte automatisch verarbeiten, ohne dass jemand die Datei öffnet. Wer einen digitalen Posteingang mit automatischer Dokumentenerfassung betreibt, hat hier ein Thema. Und CVE-2026-108471, eine kritische Rechteausweitung in den VBS-Enklaven, betrifft laut Action1 ausschließlich Windows Server 2019 und Windows 10 1809, also genau die Server-Generation, die in Kommunen noch am längsten läuft.

Bemerkenswert sind mehrere Lücken, die nur als „wichtig” eingestuft sind, aber CVSS 9,8 erreichen: Failover Cluster (CVE-2026-88102) und der zugehörige virtuelle Treiber (CVE-2026-96864), PowerShell (CVE-2026-83578) und OpenSSH für Windows (CVE-2026-97816). Die Einstufung „wichtig” sagt hier wenig über das Risiko. Die SQL-Server-RCE CVE-2026-65674 (CVSS 8,8, Deserialisierung, authentifiziert) hat laut ZDI die beste Ausnutzbarkeitsbewertung aller 22 SQL-Lücken des Monats; Fachverfahren mit eigenem SQL-Backend sind damit betroffen.

Office ist diesmal selbst eine Kohorte. Fünf Outlook-RCEs erreichen CVSS 9,8 (CVE-2026-70242, CVE-2026-70291, CVE-2026-88156, CVE-2026-97016, CVE-2026-97749), und bei allen fünf reicht laut Action1 die Anzeige der Mail im Lesebereich; kein Klick, kein Anhang. Dazu kommt eine Word-RCE mit 9,8 (CVE-2026-70300), ausgelöst durch ein WordPerfect-Dokument mit verknüpfter Grafik im Vorschaufenster, und eine PowerPoint-RCE mit 9,8 (CVE-2026-88178), die über eine an Office Online Server eingereichte Präsentation zündet. Die rund zwei Dutzend kritischen Excel-RCEs mit CVSS 8,8 brauchen dagegen alle das Öffnen der Datei; das Vorschaufenster ist dort laut Microsoft kein Angriffsvektor. Zwei Dinge zum Rollout: Office Online Server bekommt KB5002928, und für Office LTSC for Mac 2021 und 2024 waren die Updates am Patchday noch nicht verfügbar. Die Office-Updates laufen separat vom kumulativen Windows-Update und werden in Verwaltungen, die Office per Click-to-Run verteilen, gern vergessen.

Tenable hebt außerdem eine Reihe als „eher wahrscheinlich” eingestufter Rechteausweitungen hervor, darunter fünf im Windows-Update-Stack (CVE-2026-69673, CVE-2026-69718, CVE-2026-69733, CVE-2026-69783, CVE-2026-69882, jeweils 7,8), WebDAV (CVE-2026-102217, 8,8) und eine RCE im Background Intelligent Transfer Service (CVE-2026-88159, 8,8).

Abseits von Microsoft war der Oktober nicht ruhiger. Adobe hat laut ZDI 11 Bulletins mit 174 CVEs veröffentlicht; die dringendsten betreffen ColdFusion (32 CVEs, bis CVSS 10,0, Pre-Auth-RCE-Profil), Commerce und Experience Manager. Aktiv ausgenutzt wurden im Oktober Zero-Days bei Citrix NetScaler (CVE-2026-88779), Fortinet FortiMail (CVE-2026-104286), Ivanti Connect Secure und laut Action1 ein Authentifizierungs-Bypass in Cisco Identity Services Engine (CVE-2026-76460); eine kritische Atlassian-Lücke (CVE-2026-21589) und eine SonicWall-SMA1000-SSRF wurden jeweils kurz nach Veröffentlichung eines Proof-of-Concept angegriffen. SAP schließt 20 Lücken, darunter eine mit Höchstwertung im Cloud SDK für Python. Action1 bringt es auf den Punkt: Die Appliances am Netzrand gehören in denselben Patch-Plan wie Windows, nicht in den danach.

Support-Ende: Der 13. Oktober als Stichtag

Dieser Patchday ist gleichzeitig ein Lifecycle-Termin, und zwar ein umfangreicher. Microsoft hat in seinem Message Center bestätigt, dass Windows 11 24H2 in den Editionen Home und Pro sowie Windows 10 Enterprise LTSB 2016 mit dem Oktober-Update ihr letztes Sicherheitsupdate erhalten haben. Die Enterprise- und Education-Editionen von 24H2 bleiben bis zum 12. Oktober 2027 unterstützt. Microsoft empfiehlt den Umstieg auf Windows 11 26H2, das seit September 2026 als Enablement Package ausgerollt wird und für Consumer bis Oktober 2029 unterstützt ist.

Mit dem November-Patchday folgt die nächste Welle: Windows 11 23H2 Enterprise, Education und IoT Enterprise erhalten ab dann keine Sicherheitsupdates mehr. Wer in der Verwaltung noch 23H2-Geräte hat, weil der Hardware-Rollout hinterherhinkt, hat genau einen Patchday Zeit.

Auf der Server-Seite endet laut Tenable am 13. Oktober das letzte ESU-Jahr für Windows Server 2012 und 2012 R2. Die Oktober-Pakete KB5126835 und KB5126836 sind damit die letzten Updates für diese Systeme, in keinem Programm gibt es danach noch Patches. Windows Server 2022 wechselt am selben Tag vom Mainstream- in den Extended Support, der bis zum 14. Oktober 2031 läuft; Sicherheitsupdates gibt es weiterhin, Funktionsupdates nicht. Dazu fallen Office 2021, Office LTSC 2021 und Skype for Business LTSC 2021 aus dem Support. Für Verwaltungen, die Office 2021 wegen der Kaufmodell-Lizenzierung gewählt haben, ist das die ungemütlichste Nachricht des Tages.

Exchange Server: letztes Update für 2016 und 2019

Microsoft hat am Patchday das Oktober-SU für Exchange Server veröffentlicht, Details stehen im Techcommunity-Beitrag. Bereitgestellt wird es für Exchange Server Subscription Edition RTM (KB5128895), Exchange Server 2019 CU14 (KB5128897) und CU15 (KB5128896) sowie Exchange Server 2016 CU23 (KB5128898). Für 2016 und 2019 ist der Zugang weiterhin an das kostenpflichtige ESU-Programm der Phase 2 gebunden. Exchange Online ist bereits geschützt; dort beschränkt sich der Handlungsbedarf auf verbliebene On-Premises-Server und Workstations mit Exchange-Verwaltungstools. Laut Action1 erfordert das SU keinen Neustart, und bekannte Probleme sind nicht verzeichnet.

Günter Born hält in seinem Exchange-Beitrag fest, dass dies das letzte Update für Exchange Server 2016 und 2019 ist; ab November erscheinen Sicherheitsupdates nur noch für die Subscription Edition. Wer jetzt noch auf 2016 oder 2019 steht, betreibt ab dem nächsten Patchday einen Mailserver ohne Patches. Das ist keine Option, die ich in einer Verwaltung verantworten würde.

Das SU schließt die oben beschriebene RCE CVE-2026-70571 sowie laut ZDI-Liste sechs weitere Exchange-Lücken, darunter die Spoofing-Lücke CVE-2026-70279 (CVSS 9,3) und zwei Rechteausweitungen mit 8,8. Zusätzlich werden zwei Fehler behoben: Veröffentlichte Kalender im ICS-Format lieferten für Kalender-Anwendungen einen HTTP-500-Fehler (KB5126672), und die ContentEngine konnte wegen fehlender koreanischer WordBreaker-Regeldateien in einen Deadlock laufen (KB5130098). Born erwähnt bekannte Probleme des Updates, ohne sie im Detail zu nennen, Action1 verzeichnet keine; die FAQ im Techcommunity-Beitrag ist vor der Installation trotzdem Pflichtlektüre. Wie immer gilt: SU aus einer administrativen Eingabeaufforderung installieren und danach den Exchange Health Checker laufen lassen.

Handlungsempfehlungen für Ihre IT-Infrastruktur

Beginnen Sie mit den Domänencontrollern. Die AD-DS-RCE, die DHCP-Server-Lücken und die 52 DNS-Server-CVEs treffen alle dieselben Maschinen, und ein kompromittierter DC ist das Ende der Domäne. Prüfen Sie dabei zuerst, ob Ihr DHCP im Failover-Modus läuft, denn das ist die Voraussetzung für die 9,8er-Lücke. Diese Systeme gehören an den Anfang der ersten Rollout-Welle, noch vor den Clients.

Direkt danach kommt der aktiv ausgenutzte MOTW-Bypass auf die Clients. Die Lücke wird nachweislich angegriffen, Exploit-Code existiert, und der Angriffsweg ist der Dateianhang in der Mail, also der Alltag jeder Poststelle. Ich würde diesen Patch nicht bis zum regulären Client-Zyklus liegen lassen, sondern ihn als eigenen Durchlauf auf alle Geräte bringen, die externe Mails empfangen. Die Outlook-Lücken, die im Lesebereich zünden, gehören in denselben Durchlauf.

Vergessen Sie die Nebenschauplätze nicht. Exchange, SharePoint, SQL Server und Office haben eigene Updates, das .NET Framework ebenfalls. RD Gateway, NDES und Network Policy Server sind in kleinen Verwaltungen oft einzelne Server, die niemand auf dem Schirm hat, bis sie fehlen. Die ZDI-Liste mit 59 wurmfähigen Lücken ist ein guter Abgleich gegen die eigene Server-Inventur.

Führen Sie den Rollout trotz der Dringlichkeit in Wellen durch. Bei 1.400 Schwachstellen ändert sich viel Code gleichzeitig, und die September-Updates haben mit kaputten Always-On-VPN-Verbindungen, defekter Dateiversionsverlauf-Sicherung und USB-Audio-Ausfällen gezeigt, was dann passiert. Ich habe das in der Patchday-Nachlese September 2026 zusammengefasst. Testgruppe zuerst, dann die Fläche, dann prüfen, ob Anmeldung, Fernzugriff, Mail und DNS nach dem Neustart noch funktionieren.

Nutzen Sie den Stichtag für eine Inventur. Server 2012, Windows 11 24H2 Home/Pro, Office 2021, Exchange 2016/2019: Alles, was heute das letzte Update bekommen hat, muss auf eine Liste mit Ablöseterminen. Nicht in drei Monaten, sondern diese Woche.

Neuerungen abseits der Sicherheit

Die Oktober-Updates für Windows 11 bringen die Funktionen des September-Vorschauupdates KB5124010 in die Fläche. BleepingComputer hat die vollständige Liste zusammengestellt. Die aus Sicherheitssicht interessanteste Änderung betrifft ausgerechnet den Vorschaubereich des Datei-Explorers: Für aus dem Web heruntergeladene HTML-Dateien gibt es einen neuen Button „Trotzdem Vorschau anzeigen”, andere Dateitypen wie PDFs werden ab sofort automatisch in der Vorschau gerendert. Im selben Monat, in dem ein MOTW-Bypass aktiv angegriffen wird und eine Windows-PDF-RCE bei automatischer Verarbeitung zündet, finde ich das eine fragwürdige Komfortentscheidung. Wer die Vorschau per Gruppenrichtlinie abschaltet, hat dieses Thema nicht.

Darüber hinaus: Emoji 17.0, ein Tipps-Widget, eine Einstellung zum Umbelegen der Copilot-Taste auf Rechts-Strg oder Kontextmenü, die Barrierefreiheitsoption „Apps maximiert öffnen”, neue Touchpad-Gesten, ein Remote-Management-Plug-in für WinRE für MDM-Anbieter, deaktivierte Windows-Tastenkürzel im Kiosk-Modus und eine lange Liste von Bluetooth-Fixes, darunter ein Absturz mit Fehlercode 0x139 beim Streamen. Die PC-zu-PC-Migration ist entfernt worden. Als bekanntes Problem bleibt die seit September bestehende Störung bei USB-Audio-Class-1.0-Geräten; Microsoft hat sie nur teilweise behoben.

Für Windows Server 2025 bringt KB5126646 die Quick Machine Recovery, standardmäßig deaktiviert und per Gruppenrichtlinie zuschaltbar, sowie ML-KEM als Post-Quantum-Schlüsselaustausch in TLS 1.3, cURL 8.21.0 und eine Korrektur für Netlogon-Secure-Channel-Verbindungen zu älteren Domänencontrollern. Alle Server-Versionen erhalten eine ReFS-Überwachung für extern angeschlossene Datenträger (Auditing an, Erzwingung aus, Details in KB5130741) und die automatische Härtung der AD-FS-DKM-Container-ACL gegen CVE-2026-56155, abschaltbar über RemediateDkmAcl. Server 2019 und 2022 bekommen das erweiterte NTLM-Auditing, das zeigt, wer NTLM warum und wo noch verwendet. Für den anstehenden NTLMv1-Abschied ist das die Vorbereitung, die man jetzt starten sollte. Dazu kommen neue Zeitzonen für Manitoba sowie die dauerhafte Sommerzeit in British Columbia und Alberta ab November 2026. Born merkt für Server 2022 und 2025 an, dass WSUS bei Fehlern keine Details zurückmeldet.

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; Sicherheitsupdates gibt es nur im ESU-Programm, das Microsoft für Privatanwender kostenlos bis Oktober 2027 verlängert hat. Die .NET-Framework-Updates (siehe CVE-2026-108398) sind eigene Pakete und müssen separat freigegeben werden.

Ausgewählte kritische Sicherheitsupdates vom Patch Tuesday im Oktober 2026

Die folgende Tabelle listet eine Auswahl der wichtigsten Schwachstellen dieses Monats. Die vollständige Liste aller rund 1.400 behobenen CVEs finden Sie im Microsoft Security Update Guide sowie in den Gesamtübersichten bei BleepingComputer, der Zero Day Initiative und bei Action1.

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.

Wer das September-Sicherheitsupdate für Exchange Server SE installiert hat, hat sich damit womöglich ein neues Problem eingehandelt. Auf dem Server fehlen danach zwei Dateien, und Microsoft nennt als mögliche Folgen fehlende Suchergebnisse, verzögerte Zustellung und hängende Outlook-Verbindungen. Die Neuauflage Exchange SE SU10V2 vom 2. Oktober schließt eine weitere Sicherheitslücke, bringt die beiden Dateien aber nicht mit.

Die Reparatur überlässt Microsoft den Admins. Wer sich an die offizielle Anleitung hält, lädt ein SQL-Server-Paket von rund 714 MB herunter, um zwei Dateien mit zusammen 773.924 Bytes herauszuholen. Frank Carius hat das auf MSXFAQ auseinandergenommen und kommt zu dem Satz: „Das wirkt alles wie mit der heißen Nadel gestrickt.“ Ich habe die Primärquellen nachgelesen und sehe das genauso.

Dieser Artikel sortiert, was passiert ist, wo Microsofts eigene Dokumente sich widersprechen und was Sie jetzt tun sollten. Am Ende steht ein PowerShell-Skript, das den Server prüft und die Reparatur Schritt für Schritt mit Rückfragen durchführt.

Was das Exchange-Sicherheitsupdate vom September 2026 schließt

Am 8. September 2026 hat Microsoft das Sicherheitsupdate SU10 für Exchange Server SE veröffentlicht (KB5121608, Build 15.2.2562.49). Der KB-Artikel nennt acht CVEs. Darunter ist CVE-2026-69356, eine Spoofing-Lücke mit CVSS 9.3: Ein Angreifer ohne Anmeldung schickt eine präparierte Kalendereinladung, und wenn das Opfer den Join-Link anklickt, kann Skriptcode in dessen angemeldeter OWA-Sitzung laufen. Dazu kommt mit CVE-2026-69641 eine Rechteausweitung mit CVSS 9.1. Liegenlassen kann man dieses Update nicht.

Am 2. Oktober folgte SU10V2 (KB5129955, Build 15.2.2562.53). Laut dem Blogpost des Exchange-Teams unterscheidet sich die zweite Fassung von der ersten in genau einer zusätzlichen Lücke: CVE-2026-96940, eine Rechteausweitung mit CVSS 8.8. Ein angemeldeter Angreifer könnte damit auf Postfächer anderer Benutzer derselben Organisation zugreifen und Mails samt Anhängen lesen. Microsoft stuft die Ausnutzung als „Exploitation More Likely“ ein. Angriffe sind laut Microsoft bisher nicht bekannt, die Lücke wurde intern gefunden.

Für Exchange 2016 und 2019 gibt es beide Fassungen nur im ESU-Programm. Den Dateifehler, um den es hier geht, dokumentiert Microsoft nur für Exchange Server SE.

KB5130098: Zwei fehlende Dateien und ein ContentEngine-Deadlock

Die Ursache steht in KB5130098 in einem Satz: Das September-Update installiert die Dateien nicht, die der aktualisierte koreanische WordBreaker braucht. Ein WordBreaker zerlegt Text für den Suchindex in Wörter, für jede Sprache gibt es einen eigenen. Es fehlen ko.token.rule.bin und ko.complex.rule.bin im Verzeichnis Bin\Search\Ceres\Native.

Betroffen sind laut Microsoft Umgebungen, die Mails mit koreanischem Text verarbeiten. Dort kann die ContentEngine in einen Deadlock laufen, also der Teil der Exchange-Suche, der Inhalte verarbeitet. Microsoft nennt drei Symptome: Suchergebnisse fehlen, die Zustellung verzögert sich, und MAPI- oder Outlook-Clients reagieren nicht mehr oder verlieren die Verbindung.

„Koreanisch haben wir nicht“ ist als Entwarnung zu dünn. Microsoft knüpft den Fehler an den Inhalt der Mails und nicht an die Sprache der Benutzer. Ob eine einzelne koreanische Spam-Mail genügt, sagt der KB-Artikel nicht. Ausschließen würde ich es nicht.

Dass der Fehler hierzulande ankommt, legen die Kommentare unter dem Borncity-Beitrag zum September-Update nahe. Am 15. September meldet dort ein Leser „extreme Performanceprobleme“ nach dem Patch, am 23. September beschreibt ein anderer ein zähes Outlook und eine Suche, die nicht mehr funktioniert. Am 30. September verlinkt der erste Leser KB5130098 als Lösung. Carius berichtet von mehreren Kunden mit sporadischen Problemen bei Suche, Versand und Outlook-Verbindungen. Ob jede dieser Meldungen auf die fehlenden Dateien zurückgeht, lässt sich von außen nicht sagen.

Unangenehm ist das Fehlerbild. Der Server fällt nicht aus, er wird unzuverlässig. Wer so etwas sieht, sucht zuerst im Netzwerk, am Client, am Proxy oder in der Virtualisierung, und darauf weist auch Carius hin.

Wo SU10V2 nach heißer Nadel aussieht

Erst die Befunde, dann meine Bewertung.

Microsoft kannte den Fehler vor der Neuauflage. Der Blogpost zum September-Update führt ihn seit dem 24. September als bekanntes Problem. SU10V2 erschien acht Tage später und listet denselben Fehler wieder als bekannt, mit dem Vermerk, er werde in einem künftigen Update behoben. Zwischen erster und zweiter Fassung lagen 24 Tage.

Die Neuauflage tauchte auf, bevor es Informationen gab. Am Vormittag des 2. Oktober wunderten sich Leser bei Borncity über ein Exchange-Update im Microsoft Update Catalog, zu dem sie auf Microsofts Seiten nichts fanden. Das Exchange-Team hat die Frage nach der seltsamen Veröffentlichungsreihenfolge in die FAQ seines Blogposts aufgenommen und antwortet dort, das Update sei „published ahead of its intended schedule“.

Die Dokumente passen nicht zusammen. Der KB-Artikel zu SU10V2 nennt für das Installationspaket denselben SHA256-Wert wie der Artikel zur ersten Fassung, obwohl es zwei verschiedene Dateien mit verschiedenen Builds sind (Stand 10. Oktober). Außerdem führt das Exchange-Team den Free/Busy-Fehler aus KB5127092 in seinem Blogpost unter den behobenen Problemen. Der KB-Artikel zu SU10V2 listet denselben Fehler unter den bekannten Problemen, und KB5127092 selbst nennt weiterhin nur einen Workaround.

Dann der Workaround. Microsoft verlangt, SQL Server 2025 Express herunterzuladen (748.772.024 Bytes), Signatur und Hash zu prüfen, das Paket im Extract-Modus zu entpacken, daraus SQL_FULLTEXT.MSI als administratives Image auszupacken, die zwei Dateien herauszusuchen und wieder die Hashes zu prüfen. Danach geht es auf dem Exchange-Server weiter: Build und DLL prüfen, kopieren, Hashes prüfen, Dienst neu starten. Carius hat nachgemessen, dass das entpackte Paket 1,67 GB belegt. Die beiden gesuchten Dateien machen rund ein Tausendstel des Downloads aus.

Und der HealthChecker, den Microsoft nach jedem Update empfiehlt, hilft hier nicht. In den Änderungen des Release vom 2. Oktober stehen die neue CVE und die neuen Build-Nummern. Eine Prüfung auf die fehlenden Dateien finde ich dort nicht, und Carius schreibt ebenfalls, dass der HealthChecker den Fehler noch nicht erkennt.

Jeder dieser Punkte ist für sich klein. Zusammen lese ich daraus, dass hier ein Paket unter Zeitdruck hinausgeschoben und die Dokumentation hinterhergetragen wurde. Den doppelten Hash halte ich für einen Kopierfehler, belegen kann ich das nicht. Mehr ärgert mich der Workaround. Zwei Dateien von zusammen keinen 800 KB hätte Microsoft als signierten Download oder als Hotfix anbieten können. Stattdessen bekommen Admins eine Anleitung mit Abbruchbedingungen an fast jedem Schritt und dem Hinweis, im Zweifel den Support anzurufen.

Was für Microsofts Vorgehen spricht

Fairerweise: Es gibt gute Gründe, ein Sicherheitsupdate lieber früh als vollständig auszuliefern. CVE-2026-96940 erlaubt den Zugriff auf fremde Postfächer, und Microsoft hält eine Ausnutzung für wahrscheinlich. Wer so eine Lücke kennt, soll den Fix nicht zurückhalten, bis ein Problem im Suchindex gelöst ist. Die fehlenden Dateien nachzuliefern hätte neue Tests gebraucht und den Sicherheitspatch verzögert.

Das Exchange-Team hat außerdem Mitte August erklärt, warum die Schlagzahl gestiegen ist. Microsoft sucht konzernweit mit KI-Werkzeugen nach Schwachstellen, die Teams arbeiten die Funde ab, und seit Mai kam für Exchange jeden Monat ein Update. Sicherheit habe Vorrang vor allem anderen, deshalb lässt auch CU1 auf sich warten.

Auch der umständliche Workaround hat eine Logik. Die Dateien stammen aus einem signierten Microsoft-Paket, und jede Prüfung in der Anleitung verhindert, dass jemand die falsche Datei in ein produktives Exchange kopiert.

Mein Einwand bleibt. Das erklärt die Reihenfolge, die Qualität erklärt es nicht. Wer Admins auffordert, ein Update bei erster Gelegenheit einzuspielen, muss Pakete liefern, die vollständig installieren.

Was das für Kommunen und kleine IT-Abteilungen bedeutet

Ich schreibe das als jemand, der die IT einer Gemeinde betreut. In Verwaltungen dieser Größe gibt es selten einen Exchange-Spezialisten. Das Update läuft nach Feierabend, und wenn am nächsten Morgen Outlook hakt, beginnt die Fehlersuche bei null. Ein Fehler, der nur manchmal auftritt und nach Netzwerk aussieht, kostet dort Tage.

Meine Reihenfolge wäre diese:

1. SU10V2 trotzdem installieren. Die Sicherheitslücken wiegen schwerer als der Dateifehler, und der lässt sich beheben.
2. Danach prüfen, ob die beiden Dateien fehlen. Das dauert Sekunden und ändert nichts am System.
3. Wenn sie fehlen, die Reparatur einplanen. Maßgeblich sind laut Microsoft Build, DLL-Version und die fehlenden Dateien. Symptome allein reichen als Begründung nicht.
4. Den Neustart des Dienstes in ein Wartungsfenster legen und bei mehreren Servern einzeln vorgehen.
5. Nach dem Patchday am 13. Oktober erneut prüfen. Ob das nächste Update die Dateien mitbringt und wie es mit bereits kopierten Dateien umgeht, hat Microsoft nicht gesagt.

Skript: fehlende WordBreaker-Dateien prüfen und reparieren

Frank Carius bietet auf MSXFAQ ein Prüfskript und ein ZIP mit den beiden Dateien an. Ich wollte einen Schritt weitergehen und den ganzen Workaround aus KB5130098 in ein Skript packen, das vor jedem Eingriff fragt. Repair-ExchangeKoreanWordBreaker.ps1 arbeitet in neun Schritten:

1. Exchange-Installation und Build prüfen (nur 15.02.2562.049 und 15.02.2562.053)
2. Installierte korwbrkr.dll prüfen: Version, Größe, SHA256
3. Prüfen, ob die beiden Regeldateien fehlen
4. Regeldateien beschaffen
5. Beschaffte Dateien gegen Microsofts Hashes prüfen und in einen Staging-Ordner legen
6. Dateien in das Exchange-Verzeichnis kopieren
7. Kopien am Zielort verifizieren: SHA256, Größe, vererbte Berechtigungen
8. Dienst HostControllerService neu starten
9. Wiederanlauf des ContentEngine-Prozesses kontrollieren

Die Schritte 1 bis 3 lesen nur. Vor dem Download, vor dem Kopieren und vor dem Dienstneustart erklärt das Skript, was es vorhat, und macht ohne ein J nichts. Weicht ein Wert von Microsofts Angaben ab, bricht es ab und ändert nichts – so verlangt es auch der KB-Artikel, der in diesen Fällen an den Support verweist. Ist nur eine der beiden Dateien vorhanden, gilt dasselbe.

Woher die Dateien kommen, wählen Sie selbst. Sie können einen lokalen Ordner angeben, das ZIP von MSXFAQ laden lassen oder den offiziellen Weg über das SQL-Paket gehen, den das Skript dann komplett abwickelt. In allen drei Fällen verwendet es nur Dateien, die in Größe und SHA256 exakt Microsofts Angaben entsprechen. Dem ZIP muss man deshalb nicht blind vertrauen.

Microsoft empfiehlt, Download und Entpacken auf einer Admin-Workstation zu erledigen und nicht auf dem Exchange-Server. Dafür gibt es den Schalter -PrepareOnly.

powershell

# Nur prüfen, nichts ändern (Exit-Code 10 = Server ist betroffen)
.\Repair-ExchangeKoreanWordBreaker.ps1 -CheckOnly

# Prüfen und interaktiv reparieren, die Quelle der Dateien wird abgefragt
.\Repair-ExchangeKoreanWordBreaker.ps1

# Auf der Admin-Workstation: Dateien aus dem ZIP-Archiv von MSXFAQ holen und prüfen
.\Repair-ExchangeKoreanWordBreaker.ps1 -PrepareOnly -Source MSXFAQ

# Auf der Admin-Workstation: Dateien aus dem Microsoft-Paket holen und prüfen
.\Repair-ExchangeKoreanWordBreaker.ps1 -PrepareOnly -Source Microsoft

# Auf dem Exchange-Server: die übertragenen Dateien verwenden
.\Repair-ExchangeKoreanWordBreaker.ps1 -Source Local -SourcePath D:\Transfer\KoreanRules

Gestartet wird in einer Windows PowerShell 5.1 mit Administratorrechten. Jeder Lauf schreibt ein Protokoll nach C:\Temp\KoreanRules\Lauf-<Zeitstempel>\Protokoll.log. Die Meldungen sind absichtlich ohne Umlaute geschrieben, damit das Skript unabhängig von der Dateikodierung läuft.

Das Skript kommt ohne Gewähr. Fangen Sie mit -CheckOnly an und lassen Sie die Reparatur zuerst auf einem einzelnen Server laufen. Die Sollwerte stammen aus KB5130098 mit Stand 6. Oktober. Ändert Microsoft den Artikel oder liefert ein Update die Dateien nach, ist das Skript überholt.

Ein laufender Prozess beweist noch keine Erholung, das betont auch Microsoft. Stellen Sie nach dem Neustart über OWA eine normale Mail und eine mit koreanischem Text zu, suchen Sie danach und behalten Sie den Rückstau der Indizierung im Auge.

Fazit

Das Sicherheitsupdate gehört auf den Server, in der zweiten Fassung. Der Dateifehler ist kein Grund, eine Lücke offen zu lassen, über die jemand fremde Postfächer lesen könnte. Er ist aber ein Grund, nach der Installation ein paar Minuten zu investieren, bevor sich die ersten Kollegen über die Outlook-Suche beschweren.

Von Microsoft erwarte ich mehr als den Hinweis auf ein künftiges Update. Zwei Dateien nachzuliefern kann nicht so schwer sein, und eine Anleitung, die einen SQL-Server-Download voraussetzt, ist für kleine IT-Abteilungen eine Zumutung.

Prüfen Sie Ihren Exchange-Server heute mit -CheckOnly. Wenn die Dateien fehlen, planen Sie die Reparatur für das nächste Wartungsfenster ein. Und wenn Sie einen Supportvertrag haben, machen Sie ein Ticket auf. Je mehr Kunden nachfragen, desto eher bekommt das künftige Update ein Datum.

Quellen:

• Microsoft Support, KB5130098 (Stand 06.10.2026),
• KB5129955, SU10V2 (02.10.2026),
• KB5121608, SU10 (08.09.2026),
• KB5127092 (Stand 16.09.2026),
• Exchange Team Blog: September 2026 V2 Security Updates (02.10.2026),
• Exchange Team Blog: September 2026 Security Updates (08.09.2026, aktualisiert 24.09.2026),
• Exchange Team Blog: Where is Exchange SE CU1 anyway? (13.08.2026),
• MSRC: CVE-2026-96940 (02.10.2026),
• MSRC: CVE-2026-69356 (08.09.2026),
• MSRC: CVE-2026-69641 (08.09.2026),
• Microsoft Learn: Exchange Server build numbers (Stand 02.10.2026),
• GitHub, microsoft/CSS-Exchange: Release v26.10.02.1939 (02.10.2026),
• MSXFAQ, Frank Carius: Exchange SE SU10/SU10V2 Bugs (09.10.2026),
• Borns IT- und Windows-Blog: Exchange Server: Sicherheitsupdates 8. September 2026, Leserkommentare bis 02.10.2026 (09.09.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)