Kategorie: IT-Sicherheit

„Wird über die Verfügbarkeit von RZ gesprochen, werden häufig Prozentwerte von 99 % und mehr angeführt […].“ So beginnt das BSI ein Kapitel seiner Handlungsempfehlungen für Rechenzentren und fügt hinzu, dass mitunter auch die vier Tier-Klassen des Uptime Institute herangezogen werden. Für den Kunden seien solche Angaben hilfreich, um seinen Bedarf zu beschreiben. Für den Betreiber sei es „praktisch unmöglich“, ein Rechenzentrum exakt auf eine bestimmte Prozentzahl auszulegen (BSI, RZ-Verfügbarkeitsmaßnahmen, Kap. 14.2, S. 73). Wer ein Hosting auswählt und auf „Tier III“, „EN 50600“ oder „TSI Level 3“ stößt, liest also drei verschiedene Arten von Aussagen, von drei verschiedenen Stellen.

Tier: vier Stufen, ein Herausgeber

Die Tier-Klassifizierung stammt vom Uptime Institute. Es beschreibt vier Stufen über die Technik für Strom und Kühlung. Tier I ist Grundkapazität, für Wartung muss die Anlage abgeschaltet werden. Tier II ergänzt redundante Kapazitätskomponenten. Tier III ist „concurrently maintainable“, im laufenden Betrieb wartbar: Jede Komponente und jeder Verteilungspfad kann geplant herausgenommen werden, ohne den Betrieb zu stören. Tier IV fügt Fehlertoleranz hinzu, ein einzelner Geräteausfall oder eine unterbrochene Leitung soll den IT-Betrieb nicht beeinträchtigen.

Zertifizieren darf das nach eigener Aussage nur das Uptime Institute selbst („the only licensed firm“). Und es zertifiziert in Etappen: die Planungsunterlagen (Tier Certification of Design Documents), das gebaute Rechenzentrum (Tier Certification of Constructed Facility) und den Betrieb (Tier Certification of Operational Sustainability). Für Sie heißt das: Ein Zertifikat für die Planung belegt noch nicht, dass das Gebäude so gebaut wurde.

Und die Prozentzahlen, die man im Netz oft neben den Tiers findet? Auf den Seiten des Uptime Institute, die wir am 06.11.2026 gelesen haben, stehen keine Prozentwerte. Wir drucken sie deshalb nicht ab.

EN 50600: eine Norm, keine Marke

Die Normenreihe EN 50600 beschreibt Einrichtungen und Infrastrukturen von Rechenzentren. In Deutschland erscheint sie als DIN EN 50600, der allgemeine Teil zuletzt als DIN EN 50600-1 (VDE 0801-600-1):2019-08. Weitere Teile behandeln unter anderem Stromversorgung, Klimatisierung, Verkabelung und physische Sicherung. Die Normtexte sind kostenpflichtig, für diesen Beitrag haben wir sie nicht im Volltext gelesen.

Die Norm kennt vier Verfügbarkeitsklassen. Prozentwerte nennt sie nach einer Verlautbarung des für die Norm zuständigen Gremiums DKE/GK 719 vom März 2019 bewusst nicht, weil solche Zahlen „statistischer Grundlagen entbehren“. Die Klassen beruhen auf Gestaltungsprinzipien wie Mehrpfadigkeit und Komponentenredundanz.

Eine Norm ist kein Zertifikat. Nach EN 50600 prüfen verschiedene Stellen, und wer „nach EN 50600 gebaut“ schreibt, sagt noch nicht, wer das geprüft hat und mit welchem Ergebnis.

TSI: der Prüfkatalog aus der TÜV-NORD-Gruppe

Trusted Site Infrastructure, kurz TSI, ist eine Methodik der TÜV NORD GROUP zur Bewertung und Zertifizierung der physischen Sicherheit und Verfügbarkeit von Rechenzentren, etabliert seit 2001. Aktuell ist der Kriterienkatalog TSI.STANDARD in Version 4.6 vom 1. November 2024. Seit Version 4.0 deckt er nach Angabe von TÜV NORD die Anforderungen der EN 50600 ab.

TSI kennt vier Level, von „Mittlerer Schutzbedarf / Mittlere Verfügbarkeit“ bei Level 1 bis „Sehr hoher Schutzbedarf / Höchstverfügbarkeit“ mit dediziertem Rechenzentrumsgebäude bei Level 4. Ab Level 2 sind die Anforderungen mit den Verfügbarkeitsklassen der EN 50600 harmonisiert, Level 3 entspricht dort Klasse 3. Geprüft werden neun Bereiche, vom Umfeld über Baukonstruktion, Brandschutz, Sicherheit, Verkabelung, Energieversorgung und Klimatechnik bis zu Organisation und Dokumentation. Optional lassen sich zwei gleichwertige Rechenzentren als Verbund bewerten.

Und dann noch die Klassen des BSI

Für zusätzliche Verwirrung sorgt ein vierter Begriff. Das BSI arbeitet in seinem Hochverfügbarkeits-Kompendium mit eigenen Verfügbarkeitsklassen und setzt dort Zielwerte an: „hochverfügbar“ mit 99,99 Prozent im Jahr, also einer knappen Stunde Ausfall, und „höchstverfügbar“ mit 99,999 Prozent, gut fünf Minuten (RZ-Standortkriterien, Kap. 5.1, S. 18). Das sind die Klassen VK3 und VK4 des BSI. Mit den Verfügbarkeitsklassen der EN 50600 sind sie nach unserer Lesart nicht gleichzusetzen: Das BSI setzt Prozentziele, die Norm Gestaltungsprinzipien. Die Nummern sehen trotzdem gleich aus.

Was die Siegel nebeneinander sagen

Ob Tier III, Verfügbarkeitsklasse 3 und TSI Level 3 dasselbe meinen? Eine offizielle Gleichsetzung von Tier und den beiden anderen Systemen haben wir nicht gefunden. Belegt ist nur die Harmonisierung zwischen TSI und EN 50600, und die stammt von TÜV NORD selbst.

Was keines dieser Siegel sagt

Alle drei bewerten Gebäude, Technik und Betrieb des Rechenzentrums. Über die IT-Sicherheit Ihres Hosting-Pakets, also Server, Software und Zugänge, über Ihren Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO oder darüber, welchem Recht Ihre Daten unterliegen, sagen sie nichts. Dafür gibt es andere Nachweise, etwa ein Zertifikat nach ISO/IEC 27001 mit seinem Geltungsbereich. Die physische Sicherheit des Gebäudes prüft TSI dagegen mit.

Gesetzlich vorgeschrieben ist keine der Stufen; verlangen kann sie ein Vertrag oder eine Ausschreibung. Das BSI-Gesetz verlangt von Einrichtungen unter NIS2, dass ihre Maßnahmen den Stand der Technik einhalten und die einschlägigen europäischen und internationalen Normen berücksichtigen sollen (§ 30 Abs. 2 BSIG). Welche Normen, sagt das Gesetz nicht. Weder das BSIG noch die NIS2-Richtlinie noch DORA nennen die Tier-Klassifizierung des Uptime Institute oder die Normenreihe EN 50600.

Fünf Fragen an Ihren Hoster

Steht auf der Website Ihres Anbieters eines dieser Siegel, lohnt die Nachfrage. Für welchen Standort gilt das Zertifikat, und läuft Ihre Website genau dort? Wer hat es ausgestellt? Welche Stufe: Planung, gebautes Rechenzentrum oder Betrieb? Bis wann ist es gültig? Und gilt es für das Rechenzentrum des Hosters selbst oder für ein angemietetes Rechenzentrum eines Dritten?

Wenn die Antwort ein PDF mit Datum, Aussteller und Standort ist, haben Sie etwas in der Hand. Wenn sie „nach Tier-III-Standard“ lautet, eher nicht. Für Ihre Website selbst gibt es den Website-Compliance-Check von Experto Mundi; das Rechenzentrum dahinter prüft er nicht.

Quellen (Abrufdatum: 06.11.2026)

• BSI, Handlungsempfehlungen zu baulich-technischen Maßnahmen für Rechenzentren mit erhöhtem Verfügbarkeitsbedarf (RZ-Verfügbarkeitsmaßnahmen), Version 1.0 vom 21.06.2023, Kap. 14.2, S. 73 (PDF): bsi.bund.de
• BSI, Kriterien für die Standortwahl von Rechenzentren, Version 2.1, Dezember 2024, Kap. 5.1, S. 18 (PDF): bsi.bund.de
• Uptime Institute, Tier Classification System: uptimeinstitute.com/tiers
• Uptime Institute, Tier Certification: uptimeinstitute.com/tier-certification
• DKE/GK 719, Normauslegung zum BSI-Dokument „Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren“, 20.03.2019: dke.de
• VDE Verlag, DIN EN 50600-1 (VDE 0801-600-1):2019-08, Produktseite: vde-verlag.de
• TÜV NORD, TSI.STANDARD Trusted Site Infrastructure: tuev-nord.de
• TÜV NORD, TSI-Zertifizierungsmethodik: tuev-nord.de
• BSI-Gesetz (BSIG) vom 02.12.2025, BGBl. 2025 I Nr. 301, § 30 Abs. 2: gesetze-im-internet.de

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Fach- und Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er bewertet keinen Anbieter und kein einzelnes Rechenzentrum und ersetzt keine Beratung im Einzelfall. Maßgeblich sind die Dokumente der jeweiligen Herausgeber in ihrer geltenden Fassung; Stand: 06.11.2026.

Ca. 200 Kilometer. So weit sollen zwei Rechenzentren nach dem Bundesamt für Sicherheit in der Informationstechnik (BSI) mindestens auseinander liegen, wenn das eine den Betrieb übernehmen soll, falls das andere ausfällt. Weniger als 100 Kilometer sollen es keinesfalls sein. Die Zahl steht in den „Kriterien für die Standortwahl von Rechenzentren“, Version 2.1 vom Dezember 2024, und ist eine Empfehlung, kein Gesetz. DORA, die EU-Verordnung für die Finanzbranche, nennt gar keine Kilometerzahl. Und für Angriffe mit Kriegswaffen, zu denen auch Atomwaffen zählen, verlangt das BSI eigene Sicherheitsbetrachtungen, die über den Rahmen des Dokuments hinausgehen.

Was das BSI wörtlich empfiehlt

Das BSI unterscheidet zwei Arten von Standortredundanz. Liegen zwei Rechenzentren nah beieinander, geben sie einander nur Betriebsredundanz. Liegen sie so weit auseinander, dass „selbst ein Großschadensereignis nicht gleichzeitig oder zeitnah mehrere RZ“ trifft, sprechen die Standortkriterien von Georedundanz (Kap. 4, S. 15). Als Beispiele für solche Ereignisse nennt das Dokument die Schneekatastrophe im Münsterland 2005 und die Jahrhunderthochwasser an Elbe und Donau 2013.

Für Georedundanz „sollten“ die Rechenzentren einen Mindestabstand von ca. 200 km haben (Kap. 4.1, S. 15). Das BSI begründet den Wert mit Erfahrungen zur flächigen Ausdehnung von Großschadensereignissen, mit der Überlegung, dass die Wahrscheinlichkeit eines gleichzeitigen Treffers mit wachsendem Abstand sinkt, und mit der begrenzten Fläche Deutschlands. Weniger ist erlaubt, wenn es im Einzelfall „unabweisbar“ ist. Dann muss der Betreiber das schriftlich begründen und einer Risikoanalyse unterziehen, und auch dann nie unter 100 km. Was „unabweisbar“ heißt, steht in Kap. 1.4 (S. 6 und 7): zwingende technische oder betriebliche Gründe. Dass ein geringerer Abstand billiger ist, zählt ausdrücklich nicht.

Für nahe Standorte gibt es eigene Werte. Ein Bombenfund aus dem Zweiten Weltkrieg kann eine Sperrung im Radius von bis zu 1.500 m auslösen, deshalb sollen betriebsredundante Rechenzentren rund 5 km auseinander liegen, wegen der Folgen für den Verkehr in der Umgebung besser 10 bis 15 km (Kap. 3, S. 14).

Zur Einordnung, eigene Rechnung als Luftlinie zwischen den Stadtzentren: Köln und Frankfurt am Main liegen ca. 150 km auseinander, Frankfurt und München ca. 300 km. Ob das BSI in Kap. 4.1 Luftlinie oder Leitungslänge meint, sagt es nicht ausdrücklich; da es um die Fläche eines Großschadensereignisses geht, liegt die Luftlinie nahe. Ein Paar Köln/Frankfurt läge also über der Untergrenze von 100 km, aber unter der Empfehlung von 200 km.

Kurzer Exkurs, weil er zeigt, wie weit das BSI denkt: Werden georedundante Rechenzentren vom selben Caterer versorgt, soll das Essen für mehr als ein Rechenzentrum nicht in derselben Küche zubereitet werden (Kap. 4.4, S. 17). Zur Begründung verweist der Anhang auf den Brechdurchfall-Ausbruch 2012 mit über 10.000 Betroffenen in fünf Bundesländern (Kap. 5.4.13, S. 25).

Und die Bombe?

Haben die 200 Kilometer etwas mit Bombenangriffen zu tun? Nach dem Dokument nicht. Kap. 1.5 (S. 7) klammert solche Szenarien ausdrücklich aus. Wer Ereignisse wie die Anschläge vom 11. September 2001 berücksichtigen will, braucht „spezielle Sicherheitsbetrachtungen“, die über die Standortkriterien hinausgehen. „Entsprechendes gilt“, so das BSI, wenn Angriffe mit Waffen als realistisch angenommen werden, die dem Gesetz über die Kontrolle von Kriegswaffen unterliegen. Atomwaffen stehen dort in Teil A der Kriegswaffenliste.

Kerntechnik kommt in den Standortkriterien trotzdem vor, nur an anderer Stelle. Ein einzelnes Rechenzentrum soll 40 km Abstand zu Anlagen halten, bei denen Ereignisse ab Stufe 5 der Internationalen Bewertungsskala für nukleare Ereignisse (INES) möglich sind, und 5 km zu Anlagen bis Stufe 4 (Kap. 2.1.1, S. 8 und 9). Begründet wird das mit den Evakuierungsradien von Tschernobyl (37 km) und Fukushima (20 km Sperrzone), nicht mit Waffenwirkung (Kap. 5.4.1, S. 21).

Und noch ein Satz, der in Diskussionen über die Zahl selten fällt: „Zu keinem der in diesem Dokument genannten Abstandswerte gibt es zwingende physikalische Gründe“ (Kap. 5.4, S. 21). Das BSI nennt seine Werte selbst „vernünftige plausible Vorgaben“.

Umstritten ist die Zahl trotzdem

Das BSI räumt ein, dass die Literatur zum Abstand weit auseinandergeht (Kap. 5.4.12, S. 25). Zitiert werden Angaben von „mehrere Kilometer“ bis „≥ 5.000 km“ für einen katastrophentoleranten Verbund. Das für die Normenreihe DIN EN 50600 zuständige Gremium DKE/GK 719 hat die erste Fassung der Standortkriterien im März 2019 kritisiert: Die 200 km seien nicht hergeleitet. Statt eines festen Abstands solle eine qualifizierte Risikoanalyse zeigen, ob zwei Standorte gemeinsame Risiken haben. Das BSI ist in der Fassung von 2024 bei den 200 km geblieben.

Dazu kommt ein technischer Zielkonflikt, den das BSI offen benennt. Ab mehr als 100 km Leitungslänge können nach dem BSI Probleme bei der synchronen Datenhaltung auftreten, und die Leitung ist immer länger als die Luftlinie (Kap. 2.2, S. 10). Großer Abstand schützt besser, macht aber eine verlustfreie Spiegelung schwerer. Beides zugleich optimal zu haben, hält das BSI für kaum möglich, der Betreiber muss im Sicherheitskonzept begründen, was zurücksteht (Kap. 1.3, S. 6). Als Ausweg nennt das Dokument, Datenbestände betriebsredundanter Rechenzentren zusätzlich in einem tatsächlich georedundanten Rechenzentrum zu sichern (Kap. 3, S. 14).

Wer hat also recht, das BSI mit der festen Zahl oder die Normungsleute mit der Risikoanalyse? Das lässt sich nicht pauschal entscheiden. Die Zahl ist leicht prüfbar, die Risikoanalyse genauer, aber nur so gut wie ihr Verfasser.

Was DORA verlangt

Für Banken, Versicherer und andere Finanzunternehmen gilt seit dem 17. Januar 2025 die Verordnung (EU) 2022/2554, kurz DORA (Art. 64). Art. 12 Abs. 4 verlangt von Finanzunternehmen, die keine Kleinstunternehmen sind, redundante IKT-Kapazitäten, die für den Geschäftsbedarf ausreichen. Eine Entfernung steht dort nicht.

Konkreter wird DORA nur für Zentralverwahrer. Sie brauchen nach Art. 12 Abs. 5 einen sekundären Verarbeitungsstandort „in geografischer Entfernung“, damit er „ein eigenes Risikoprofil“ hat und vom Ereignis am Hauptstandort nicht betroffen ist. Für zentrale Gegenparteien verlangt die Delegierte Verordnung (EU) 2024/1774 in Art. 24 Abs. 2 Buchst. c Ziff. ii einen sekundären Verarbeitungsstandort, der „ein anderes geografisches Risikoprofil“ aufweisen muss als der Primärstandort. Eine Kilometerzahl nennt keine der beiden Vorschriften. Auch das deutsche BSI-Gesetz verlangt von Einrichtungen unter NIS2 in § 30 Abs. 2 Nr. 3 Backup-Management und Wiederherstellung nach einem Notfall, ohne Abstandsangabe.

Und Ihre Website?

Die Standortkriterien richten sich vor allem an Rechenzentren mit hohem oder sehr hohem Schutzbedarf bei der Verfügbarkeit (Kap. 1, S. 5). Das BSI schreibt aber auch, dass ein Kunde anhand des Dokuments prüfen kann, ob ein Dienstleistungs-Rechenzentrum zu seinen Anforderungen passt (Kap. 1.1, S. 5). Genau dafür taugt es.

Unsere Einschätzung als Experto Mundi: Für die Website eines kleinen Betriebs ist die Frage nach zwei Rechenzentren im Abstand von 200 km selten die wichtigste. Wichtiger ist, wo die Datensicherung liegt und ob sie im selben Gebäude steht wie die Website. Fragen Sie Ihren Hoster, an welchen Standorten Website und Sicherung liegen, wie weit diese voneinander entfernt sind und ob das im Vertrag steht. Ein Prospekt mit dem Wort „georedundant“ ersetzt diese Angaben nicht.

Wie Ihre Website technisch dasteht, zeigt der Website-Compliance-Check von Experto Mundi. Die Frage nach den Rechenzentren beantwortet Ihr Hoster.

Quellen (Abrufdatum: 06.11.2026)

• BSI, Kriterien für die Standortwahl von Rechenzentren (RZ-Standortkriterien), Version 2.1, Dezember 2024, Kap. 1, 1.1, 1.3, 1.4, 1.5, 2.1.1, 2.2, 3, 4, 4.1, 4.4, 5.4, 5.4.1, 5.4.12, 5.4.13 (PDF): bsi.bund.de
• DKE/GK 719, Normauslegung zum BSI-Dokument „Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren“, veröffentlicht 20.03.2019: dke.de
• Verordnung (EU) 2022/2554 (DORA), Art. 12 Abs. 4 und 5, Art. 64, CELEX 32022R2554: EUR-Lex
• Delegierte Verordnung (EU) 2024/1774, Art. 24 Abs. 2 Buchst. c Ziff. ii, CELEX 32024R1774: EUR-Lex
• BSI-Gesetz (BSIG) vom 02.12.2025, BGBl. 2025 I Nr. 301, § 30 Abs. 2 Nr. 3: gesetze-im-internet.de
• Gesetz über die Kontrolle von Kriegswaffen, Anlage (Kriegswaffenliste), Teil A, Abschnitt I: gesetze-im-internet.de

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechts- und Fachfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche oder technische Beratung. Maßgeblich sind allein die Rechtstexte und Dokumente in ihrer geltenden Fassung; Stand: 06.11.2026.

NIS2 trifft das Rechenzentrum selbst. DORA trifft seine Kunden aus der Finanzbranche und erreicht das Rechenzentrum über deren Verträge. Wer ein Rechenzentrum betreibt, muss beide Wege auseinanderhalten, weil Pflichten, Fristen und Aufsicht verschieden sind. Wer nur eine Website hostet, sollte wissen, welcher Weg seinen Anbieter betrifft. Stand der Rechtslage ist der 06.11.2026.

Wen NIS2 erfasst

Die EU-Richtlinie (EU) 2022/2555, kurz NIS2, gilt in Deutschland über das BSI-Gesetz in der Fassung des NIS2-Umsetzungsgesetzes. Das neue BSIG ist am 6. Dezember 2025 in Kraft getreten. In seiner Anlage 1 stehen unter „Digitale Infrastruktur“ ausdrücklich die Anbieter von Rechenzentrumsdiensten (Nr. 6.1.5), daneben Anbieter von Cloud-Computing-Diensten (Nr. 6.1.4) und Managed Services Provider (Nr. 6.1.10). Ob ein Webhoster unter die eine oder die andere Nummer fällt, hängt von seinem Angebot ab. Die Anlage nennt alle drei.

Ein Rechenzentrumsdienst ist nach § 2 Nr. 35 BSIG ein Dienst, dessen Strukturen vorrangig der zentralen Unterbringung, Zusammenschaltung und dem Betrieb von IT- oder Netzwerkausrüstungen dienen, samt Stromverteilung und Umgebungskontrolle. Das eigene Rechenzentrum eines Unternehmens, das nur der eigenen IT dient, soll nach Erwägungsgrund 35 der NIS2-Richtlinie nicht darunter fallen. Erwägungsgründe erläutern die Richtlinie, sie sind selbst kein verbindlicher Gesetzestext.

Dann entscheidet die Größe. Besonders wichtige Einrichtung ist nach § 28 Abs. 1 Nr. 4 BSIG, wer mindestens 250 Mitarbeiter hat oder über 50 Millionen Euro Jahresumsatz und zugleich über 43 Millionen Euro Jahresbilanzsumme. Wichtige Einrichtung ist nach § 28 Abs. 2 Nr. 3 BSIG, wer mindestens 50 Mitarbeiter hat oder jeweils über 10 Millionen Euro Umsatz und Bilanzsumme. Ein kleines Rechenzentrum mit 20 Leuten und 3 Millionen Euro Umsatz liegt unter beiden Schwellen, solange es keine kritische Anlage betreibt und nicht zu einer größeren Unternehmensgruppe gehört; Partner- und verbundene Unternehmen werden grundsätzlich mitgezählt (§ 28 Abs. 4 BSIG).

Unabhängig von der Größe besonders wichtig sind Betreiber kritischer Anlagen (§ 28 Abs. 1 Nr. 1 BSIG). Die Schwellen für Rechenzentren stehen in der BSI-Kritisverordnung, Anhang 4 Teil 3: Housing ab 3,5 MW vertraglich vereinbarter Leistung, Hosting ab 10.000 physischen oder 15.000 virtuellen Instanzen für Nutzer im Jahresdurchschnitt (abgerufen am 06.11.2026). Für den Begriff der kritischen Anlage gilt nach § 66 BSIG eine Übergangsregel, bis eine Rechtsverordnung nach dem KRITIS-Dachgesetz in Kraft ist. Bis dahin gilt die alte Begriffsbestimmung weiter, nach der die Rechtsverordnung nach § 56 Abs. 4 BSIG die kritischen Anlagen bestimmt, und das ist die BSI-Kritisverordnung. Ob sich die Werte dann ändern, ist offen.

Was NIS2 vom Betreiber verlangt

Die Kernpflicht steht in § 30 BSIG. Der Betreiber muss geeignete, verhältnismäßige und wirksame Maßnahmen ergreifen und das dokumentieren. Abs. 2 zählt die Mindestinhalte auf: Risikoanalyse und Sicherheitskonzepte, Bewältigung von Sicherheitsvorfällen, Aufrechterhaltung des Betriebs mit Backup-Management, Wiederherstellung und Krisenmanagement, Sicherheit der Lieferkette, Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen, Prüfung der Wirksamkeit, Schulungen, Kryptografie, Zugriffskontrolle und Personalsicherheit sowie Multi-Faktor-Authentifizierung. Für Rechenzentrumsdienste hat ein Durchführungsrechtsakt der EU-Kommission nach Art. 21 Abs. 5 NIS2 Vorrang (§ 30 Abs. 3 BSIG). Dessen Inhalt behandelt dieser Beitrag nicht.

Bei einem erheblichen Sicherheitsvorfall laufen nach § 32 Abs. 1 BSIG drei Uhren: unverzüglich, spätestens 24 Stunden nach Kenntnis eine frühe Erstmeldung, unverzüglich, spätestens 72 Stunden nach Kenntnis die eigentliche Meldung, spätestens einen Monat danach die Abschlussmeldung. Eine Zwischenmeldung gibt es nur, wenn das BSI darum bittet. Gemeldet wird an die gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe.

Registrieren müssen sich betroffene Einrichtungen spätestens drei Monate, nachdem sie erstmals als solche gelten (§ 33 Abs. 1 BSIG). Wer schon seit dem Inkrafttreten erfasst ist, war rechnerisch Anfang März 2026 dran. Wer die Frist verpasst hat, sollte das nicht liegen lassen: Eine fehlende oder falsche Registrierung kann mit bis zu 500.000 Euro geahndet werden (§ 65 Abs. 2 Nr. 6, Abs. 5 Satz 1 Nr. 5 BSIG).

Und die Geschäftsleitung? Sie muss die Maßnahmen umsetzen und überwachen, haftet bei schuldhafter Pflichtverletzung nach Gesellschaftsrecht und muss regelmäßig an Schulungen teilnehmen (§ 38 BSIG). Die Pflicht liegt damit bei der Leitung selbst.

Die Bußgelder, nüchtern gelesen

Für Verstöße gegen Risikomanagement, Dokumentation und Meldepflichten nennt § 65 Abs. 5 BSIG bis zu 10 Millionen Euro bei besonders wichtigen und bis zu 7 Millionen Euro bei wichtigen Einrichtungen. Die prozentualen Obergrenzen von 2 und 1,4 Prozent des weltweiten Gesamtumsatzes greifen nach § 65 Abs. 6 und 7 erst bei mehr als 500 Millionen Euro Gesamtumsatz.

Woher kommt diese Schwelle? Die Richtlinie selbst verlangt in Art. 34 Abs. 4 und 5 einen „Höchstbetrag von mindestens 10 000 000 EUR“ oder von „mindestens 2 %“ des Umsatzes, „je nachdem, welcher Betrag höher ist“. Gemeint ist die Obergrenze, die das nationale Gesetz mindestens vorsehen muss, kein Mindestbußgeld. 2 Prozent von 500 Millionen sind genau 10 Millionen. Unterhalb dieser Umsatzgrenze ist der feste Betrag ohnehin der höhere, das deutsche Gesetz bildet das also nur ab.

Wie DORA ins Rechenzentrum kommt

DORA, die Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025 unmittelbar (Art. 64). Sie richtet sich an 20 Arten von Finanzunternehmen, von Kreditinstituten über Versicherer bis zu Krypto-Dienstleistern (Art. 2 Abs. 1 Buchst. a bis t). Ausgenommen sind unter anderem Versicherungsvermittler, die Kleinst-, kleine oder mittlere Unternehmen sind (Art. 2 Abs. 3 Buchst. e). Die BaFin hat ihre IT-Rundschreiben für Versicherer (VAIT), Kapitalverwaltungsgesellschaften (KAIT) sowie Zahlungs- und E-Geld-Institute (ZAIT) mit Ablauf des 16. Januar 2025 aufgehoben, die BAIT der Banken laufen mit Ablauf des 31. Dezember 2026 vollständig aus.

Das Rechenzentrum taucht in DORA als IKT-Drittdienstleister auf, also als „Unternehmen, das IKT-Dienstleistungen bereitstellt“ (Art. 3 Nr. 19). DORA nennt IKT-Drittdienstleister in Art. 2 Abs. 1 Buchst. u zwar selbst als Adressaten; eigene Pflichten gegenüber der Aufsicht entstehen aber vor allem, wenn sie als kritisch eingestuft werden (Art. 31). IKT-Dienstleistungen schließen ausdrücklich „Hardware als Dienstleistung“ ein (Art. 3 Nr. 21). Ob reine Flächen- und Stromvermietung ohne IT-Betrieb darunter fällt, beantwortet der Wortlaut nicht eindeutig. Eine Aussage der Aufsicht dazu haben wir nicht gefunden.

Die Pflichten treffen zuerst den Kunden. Er bleibt nach Art. 28 Abs. 1 Buchst. a voll verantwortlich, führt ein Informationsregister über alle IKT-Verträge (Art. 28 Abs. 3) und braucht für kritische oder wichtige Funktionen eine Ausstiegsstrategie (Art. 28 Abs. 8). Beim Rechenzentrum kommt das als Vertragstext an. Art. 30 Abs. 2 schreibt für jeden IKT-Vertrag unter anderem vor: eine vollständige Leistungsbeschreibung mit Regeln zur Unterauftragsvergabe, die Standorte der Leistung und der Datenspeicherung samt Vorabinformation bei Änderungen, Zugang zu den Daten bei Insolvenz oder Vertragsende, Unterstützung bei IKT-Vorfällen ohne zusätzliche oder zu vorab festgelegten Kosten, Zusammenarbeit mit den Behörden und Kündigungsrechte. Eine Pflicht, die Daten in der EU zu halten, enthält Art. 30 nicht. Geht es um kritische oder wichtige Funktionen, kommen nach Abs. 3 präzise Leistungsziele, getestete Notfallpläne, die Mitwirkung an bedrohungsgeleiteten Penetrationstests (TLPT), uneingeschränkte Zugangs-, Inspektions- und Auditrechte sowie Ausstiegsregeln mit Übergangszeit dazu.

Die europäischen Aufsichtsbehörden können einen IKT-Drittdienstleister als kritisch einstufen und dann direkt überwachen (Art. 31 Abs. 1). Maßgeblich sind unter anderem die systemischen Auswirkungen einer Störung, gemessen auch an der Zahl der betroffenen Finanzunternehmen und deren Aktiva (Art. 31 Abs. 2 Buchst. a).

Gilt dann beides?

Für den Finanzkunden nicht. Nach § 28 Abs. 6 Nr. 1 BSIG gelten die §§ 30, 31, 32, 35, 36, 38 und 39 BSIG nicht für Finanzunternehmen im Sinne von DORA. Das Rechenzentrum selbst ist kein Finanzunternehmen, für es gilt diese Ausnahme nicht. Ein Betreiber mit Bankkunden erfüllt also, wenn er die Schwellen erreicht, die NIS2-Pflichten für sich selbst und die DORA-Vertragspflichten gegenüber seinen Kunden. Eine Ausnahme gibt es bei der Meldepflicht: Betreibt ein Betreiber kritischer Anlagen eine Anlage für ein Finanzunternehmen, gilt § 32 BSIG insoweit nicht (§ 28 Abs. 7 BSIG). Dann meldet der Finanzkunde nach DORA an seine Aufsicht, und das Rechenzentrum unterstützt ihn nach Art. 30 Abs. 2 Buchst. f DORA. In den übrigen Fällen meldet das Rechenzentrum erhebliche Sicherheitsvorfälle selbst nach § 32 BSIG.

Was das für Hosting-Kunden heißt

Wenn Sie einen kleinen Betrieb führen und kein Finanzunternehmen im Sinne von DORA sind, also keine Bank, kein Versicherer, kein Zahlungs-, E-Geld- oder Krypto-Dienstleister, treffen Sie die DORA-Pflichten der Finanzunternehmen nicht. Ob NIS2 für Sie gilt, hängt von Ihrer eigenen Branche nach den Anlagen 1 und 2 des BSIG und Ihrer Größe ab, nicht davon, bei wem Ihre Website liegt.

Für Ihren Hoster kann das anders aussehen. Sie dürfen ihn fragen, ob er nach dem BSIG als wichtige oder besonders wichtige Einrichtung gilt und registriert ist, wie er Sie bei einem Vorfall informiert und wo Ihre Daten gespeichert werden. Die Antworten gehören in den Vertrag zur Auftragsverarbeitung oder in die Leistungsbeschreibung. Eine Antwort, die nur „wir sind sicher“ lautet, ist keine.

Den technischen Stand Ihrer eigenen Website können Sie mit dem Website-Compliance-Check von Experto Mundi prüfen lassen. Was NIS2 und DORA technisch für Websites bedeuten, steht im Beitrag NIS2 und DORA technisch.

Quellen (Abrufdatum: 06.11.2026)

• BSI-Gesetz (BSIG) vom 02.12.2025, BGBl. 2025 I Nr. 301, Stand der Textfassung zuletzt geändert durch Art. 8 G v. 22.10.2026, §§ 2 Nr. 35, 28 Abs. 4, 6 und 7, 30, 32, 33, 38, 65, 66 und Anlage 1 Nr. 6: gesetze-im-internet.de
• Richtlinie (EU) 2022/2555 (NIS2), Art. 21, Art. 34 Abs. 4 und 5, Erwägungsgrund 35, CELEX 32022L2555: EUR-Lex
• Verordnung (EU) 2022/2554 (DORA), Art. 2, 3 Nr. 19 und 21, 28, 30, 31, 64, CELEX 32022R2554: EUR-Lex
• Verordnung zur Bestimmung Kritischer Infrastrukturen nach dem BSI-Gesetz (BSI-Kritisverordnung), Anhang 4 Teil 3: gesetze-im-internet.de
• BaFin, Meldung „DORA kommt: Änderungen bei den aufsichtlichen Anforderungen an die IT“, 10.01.2025: bafin.de

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Ob Ihr Unternehmen erfasst ist, hängt von Umständen ab, die nur eine Einzelfallprüfung klären kann. Maßgeblich sind allein die Rechtstexte in ihrer geltenden Fassung; Stand: 06.11.2026.

Am 7. Oktober 2026, abends um 21:47 Uhr UTC, sah der Sicherheitsanbieter Patchstack nach eigenen Angaben den ersten Angriff auf ein WordPress-Plugin namens Bricksforge. Insgesamt zählte der Anbieter 63 verschiedene IP-Adressen. Drei Meldungen sollten Sie als Betreiber einer Website kennen: diese Plugin-Lücke, einen Fehler im Webserver nginx und ein Urteil des Bundesgerichtshofs zur SCHUFA.

1. Bricksforge: Dateien hochladen ohne Anmeldung (CVE-2026-85097)

Was ist passiert?

Bricksforge ist ein Zusatz für den WordPress-Seitenbaukasten Bricks. In älteren Versionen kann ein Angreifer ohne Anmeldung beliebige Dateien auf den Server laden. Lädt er eine PHP-Datei hoch und ruft sie auf, läuft sein Code auf Ihrem Server. Die Fehlernummer lautet CVE-2026-85097. Streng genommen ist das keine „Codeausführung per Fernzugriff“ in einem Schritt, sondern ein Upload, der danach die Ausführung möglich macht. Für Sie macht das praktisch keinen Unterschied.

Die Schwachstelle liegt im Parameter temporaryFileUploads, genauer in dessen Feld url. Laut Patchstack holt sich der Angreifer zuerst einen Sicherheitsschlüssel von einem Endpunkt, der ohne Anmeldung antwortet, und schickt dann eine Datei hoch.

Die Bewertung: Wordfence, das die Nummer vergeben hat, bewertet mit CVSS 3.1 und 9,8 von 10. Die US-Datenbank NVD hat den Eintrag am 8. Oktober 2026 veröffentlicht und führt die Wertung von Wordfence mit 9,8 von 10 auf (eine eigene Analyse der NVD steht noch aus). Patchstack kommt auf 10,0. Die Anbieter bewerten unterschiedlich, beide Werte liegen in der Stufe „kritisch“.

Wer ist betroffen?

Alle Seiten, auf denen Bricksforge in der Version 3.1.8.9 oder älter installiert ist. Wer das Plugin nicht nutzt, ist nicht betroffen. Seiten mit 4.0.0 oder 3.1.8.10 sind von dieser Nummer nicht mehr erfasst. Laut Changelog schließt 4.0.1 aber eine Lücke im Datei-Upload der Pro Forms, die jede Seite mit aktivem Pro Forms betrifft, deshalb empfehlen wir mindestens 4.0.1. Ist es installiert, gehört es aktualisiert oder entfernt.

Wie ist der Stand der Updates?

Laut Patchstack ist die Lücke in Version 3.1.8.10 behoben. Der Changelog des Herstellers nennt 3.1.8.10 nur im Eintrag zu Version 4.0.1, ohne eigenen Eintrag und ohne Datum, und führt dort aus, dass die Lücke bereits in 3.1.8.10 und im 4er-Zweig mit Version 4.0.0 vom 17. September 2026 behoben wurde. Version 4.0.1 vom 8. Oktober 2026 schließt nach Angabe des Herstellers eine Sicherheitslücke im Datei-Upload der Pro Forms. Betroffen ist jede Seite mit aktivem Pro Forms, auch wenn die Formulare keine Upload-Felder haben, ein Update wird ausdrücklich empfohlen. Am 13. Oktober 2026 erschien 4.0.2, die unter anderem Bilder wieder annimmt, die die Prüfung aus 4.0.1 fälschlich abgelehnt hatte, und gespeicherte Zugangsdaten stärker filtert. Aktualisieren Sie deshalb auf 4.0.2 oder neuer, mindestens auf 4.0.1.

Dass die Lücke tatsächlich ausgenutzt wird, stammt aus einer einzigen Quelle: Patchstack selbst. Danach gingen die Angriffe an die Adressen /wp-json/bricksforge/v1/form_submit und admin-ajax.php. Eine unabhängige Bestätigung haben wir nicht gefunden. Der SSVC-Eintrag der US-Behörde CISA in der NVD führt die Ausnutzung (Stand 8. Oktober, bei unserer Prüfung am 25. Oktober 2026 unverändert) mit „none“. Das widerspricht der Patchstack-Meldung nicht zwingend, die Einstufungen stammen aus unterschiedlichen Quellen und Zeitpunkten.

Was Sie tun

1. Prüfen Sie im WordPress-Backend unter „Plugins“, ob Bricksforge installiert ist und in welcher Version.

1. Aktualisieren Sie auf Version 4.0.2 oder neuer, mindestens auf 4.0.1. Vorher eine Sicherung ziehen, nachher die Seite testen, denn der Sprung von 3.x auf 4.x ist ein Hauptversionswechsel. (Sicherung und Test: eigene Einschätzung.)
2. Lassen Sie Anfragen an /wp-json/bricksforge/v1/form_submit und admin-ajax.php im Zugriffsprotokoll prüfen, möglichst weiter zurück als bis zum 7. Oktober. Ob der Parameter temporaryFileUploads im Anfragekörper stand, zeigt ein übliches Zugriffsprotokoll meist nicht. Das klären Sie mit dem Hoster oder einer Firewall, die auch den Körper protokolliert. Kein Treffer im Protokoll ist keine Entwarnung. (Eigene Einschätzung, nicht Inhalt der Quellen.)
3. Lassen Sie mindestens das Verzeichnis /wp-content/uploads/bricksforge/tmp/ auf PHP-Dateien durchsehen, besser den ganzen Ordner wp-content/uploads (auch auf Endungen wie .php5 oder .phtml). Unerwartete PHP-Dateien sind ein Warnzeichen. Ein Fund wird nicht selbst gelöscht, sondern erst gesichert und dokumentiert. Können dadurch personenbezogene Daten betroffen sein, läuft die Meldefrist von 72 Stunden nach Art. 33 DSGVO. (Eigene Einschätzung.)
4. Laut Changelog zu 4.0.2 werden im Plugin gespeicherte Zugangsdaten nun stärker gefiltert. Wer dort API-Schlüssel hinterlegt hat, soll sie vorsorglich bei den Anbietern erneuern. Das gilt erst recht, wenn Sie nicht ausschließen können, dass die Lücke vor dem Update ausgenutzt wurde. Erst Seite bereinigen und aktualisieren, dann die Schlüssel erneuern, sonst landet der neue Schlüssel wieder in einer möglicherweise kompromittierten Umgebung. (Reihenfolge: eigene Einschätzung.)

2. nginx: Speicherfehler bei alias und rewrite (CVE-2026-15176)

Kurzer Einschub: Die Einstufung dieser Lücke fällt je nach Quelle sehr unterschiedlich aus. Am 14. Oktober 2026 hat das nginx-Projekt die Versionen 1.31.7 (Mainline) und 1.30.6 (Stable) veröffentlicht. 1.31.7 schließt insgesamt fünf Sicherheitsfehler. Einer davon ist CVE-2026-15176, ein Überlauf im Speicher eines Arbeitsprozesses.

Was ist passiert?

Der Fehler tritt auf, wenn die Konfiguration mehrere Dinge zugleich enthält: einen location-Block mit alias, ein rewrite, das die Adresse ändert, und die Variable $request_filename in einer der Anweisungen set oder return oder im Log-Format. Dann reicht eine präparierte Anfrage ohne Anmeldung. Die Folge ist in der Regel, dass der Arbeitsprozess abstürzt und neu startet (Dienst kurz gestört). Fremden Code auszuführen ist laut NVD nur möglich, wenn der Speicherschutz ASLR deaktiviert oder umgangen ist. Das ist nach unserer Einschätzung auf gängigen Servern eher die Ausnahme.

Die Einstufung ist uneinheitlich. Im NVD-Eintrag (Wertung durch den Hersteller F5) stehen CVSS 3.1 mit 8,1 und CVSS 4.0 mit 9,2. Das nginx-Projekt selbst stuft den Fehler als „Medium“ ein. Eine mögliche Erklärung sind unterschiedliche Maßstäbe.

Wer ist betroffen?

Betroffen sind laut nginx.org die Versionen 0.1.29 bis 1.31.6. Gefixt sind 1.31.7 und 1.30.6, in der Stable-Reihe sind also die Versionen bis 1.30.5 betroffen. Das gilt nur bei der Kombination aus der Konfiguration oben. Auch NGINX Plus ist laut NVD betroffen, die Fixstände dazu haben wir nicht geprüft, sie erfragen Sie beim Hersteller. Wir gehen davon aus, dass viele Installationen die Kombination nie enthalten. Wer nur Webspace mietet, kann die Konfiguration meist nicht selbst ändern, dann ist der Hoster am Zug. Wer einen eigenen Server oder einen Docker-Container mit nginx betreibt, sollte nachsehen.

Hinweis: Linux-Distributionen übernehmen Sicherheitskorrekturen oft in ältere Versionen, ohne die Nummer zu ändern. Dass bei Ihnen „1.24“ steht, heißt deshalb nicht automatisch „nicht gefixt“. Ob Ihr Paket den Fix enthält, steht im Sicherheitsverzeichnis der Distribution. Das haben wir nicht für einzelne Distributionen geprüft.

Was Sie tun

• Eigener Server: auf 1.31.7 oder 1.30.6 oder neuer aktualisieren. Wer nicht sofort kann, sucht in der Konfiguration nach der Kombination aus alias, rewrite und $request_filename, auch in eingebundenen Dateien (nginx -T zeigt die gesamte wirksame Konfiguration). Das ist eine Prüfung, kein Schutz: Workarounds nennt nginx.org nicht.
• Webspace beim Hoster: nachfragen, ob nginx dort eingesetzt wird und ob der Fix eingespielt ist.

3. BGH zur SCHUFA: Revisionen erfolgreich, Beweiserleichterung für Betroffene

Am 21. Oktober 2026 hat der Bundesgerichtshof in vier Verfahren (I ZR 227/25 bis I ZR 230/25) über Klagen von Privatpersonen gegen die SCHUFA entschieden. Es ging um Auskunft über die Berechnung der Scorewerte und um die Erstattung außergerichtlicher Rechtsanwaltskosten. Das betrifft Sie als Website-Betreiber, wenn Ihr Shop Bonitätsauskünfte einholt, etwa für den Kauf auf Rechnung. Die Landgerichte Chemnitz, Leipzig und Görlitz hatten die Auskunftsanträge abgewiesen. Das Oberlandesgericht Dresden hatte am 7. Oktober 2025 teilweise Auskunft und die Erstattung außergerichtlicher Kosten zugesprochen.

Der BGH hat den Revisionen der SCHUFA stattgegeben, die Berufungsurteile in diesem Punkt aufgehoben und die Sachen an das OLG Dresden zurückverwiesen. Einen Auskunftsanspruch aus Art. 15 Abs. 1 Buchst. h DSGVO (Information über die Logik hinter automatisierten Entscheidungen) gibt es danach nur, wenn alle Voraussetzungen von Art. 22 Abs. 1 DSGVO erfüllt sind. Das folgt der Linie des Europäischen Gerichtshofs, der in der Rechtssache C-634/21 (Urteil vom 7. Dezember 2023) die Berechnung eines Scorewerts unter Umständen als automatisierte Entscheidung ansieht.

Zwei Punkte aus der Pressemitteilung (Nr. 198/2026) sind für die Praxis wichtig:

• Ein Scorewert kann eine automatisierte Entscheidung sein, wenn die Entscheidung eines Dritten (unsere Beispiele: ein Vermieter, eine Bank oder ein Händler) maßgeblich davon abhängt. Ob die Betroffenen dadurch erheblich beeinträchtigt wurden, hat der BGH mangels Feststellungen nicht beurteilt.
• Die Betroffenen müssen darlegen und beweisen, dass die Entscheidung des Dritten maßgeblich auf dem Score beruht. Dafür gibt es nach der Pressemitteilung erhebliche Erleichterungen. Es genügt vorzutragen, dass der Score übermittelt wurde und danach eine nachteilige Entscheidung folgte. Dann besteht eine tatsächliche Vermutung dafür, dass sie auf dem Score beruhte.

Wie sich das für Betroffene auswirkt, entscheidet nun das OLG Dresden. Zu den vier Entscheidungen liegen inzwischen Volltexte als PDF vor (verlinkt auf der Seite der Pressemitteilung). Die Pressemitteilung nennt keine Leitsätze. Wir haben die Volltexte bisher nicht ausgewertet und stützen uns auf die Pressemitteilung.

Was das für Betreiber heißt

Der BGH hat über den Auskunftsanspruch gegen die SCHUFA entschieden, nicht über Pflichten von Unternehmen, die Scorewerte einholen. Folgendes ist unsere Einschätzung und nicht Inhalt der Entscheidung: Für solche Unternehmen kann die Frage wichtig sein, ob eine Entscheidung ausschließlich automatisiert und maßgeblich auf dem Score beruht, denn nur dann greift Art. 22 Abs. 1 DSGVO. Entscheidet bei Ihnen am Ende ein Mensch, ist das möglicherweise anders zu beurteilen. Das ist keine Rechtsberatung. Lassen Sie Ihre Praxis von einer Fachperson für Datenschutzrecht prüfen.

Wen Sie fragen

• Bricksforge und andere WordPress-Plugins: Ihr Webdesigner oder die Agentur, die die Seite pflegt.
• nginx: Ihr Hoster oder die Person, die den Server betreut.
• Scoring und DSGVO: Ihre Datenschutzbeauftragte oder Ihr Anwalt.

Quellen

• NVD, CVE-2026-85097
• NVD, CVE-2026-15176
• nginx.org, Security Advisories
• Bricksforge, Versions-Changelog
• Patchstack, Beitrag zu Bricksforge
• Bundesgerichtshof, Pressemitteilung Nr. 198/2026 vom 21.10.2026

9,2 von 10 Punkten. So hoch bewertet das PHP-Projekt die beiden Sicherheitslücken, die es am 21. Oktober 2026 geschlossen hat. Unter bestimmten Bedingungen kann ein Angreifer damit ohne Passwort eigenen Code auf dem Webserver ausführen. Ein Netzwerk- und Sicherheitsdienst meldet bereits Angriffe auf Kundenseiten. Wenn Ihre Webseite mit WordPress läuft, sollten Sie heute noch die PHP-Version prüfen. Das geht in zwei Minuten.

Update 28.10.2026: Die US-Behörde CISA hat beide PHP-Lücken, CVE-2026-109618 und CVE-2026-109619, am 26.10.2026 in ihren Katalog „Known Exploited Vulnerabilities“ aufgenommen, kurz KEV, auf Deutsch „bekannte ausgenutzte Schwachstellen“. In diesem öffentlichen Verzeichnis stehen Lücken, die nach Einschätzung der CISA bereits in echten Angriffen genutzt werden. US-Bundesbehörden müssen sie bis zum 29.10.2026 beheben. Über Erpressungskampagnen macht der Eintrag keine Angabe. Für Sie heißt das: Läuft Ihre Seite noch auf einer PHP-Version unter 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, fragen Sie Ihren Hoster jetzt nach dem Update; für PHP 8.1 und älter erscheint kein Fix. Quelle: CISA, KEV-Katalog, Version 2026.10.27, abgerufen am 28.10.2026.

Was passiert ist

PHP ist die Programmiersprache, mit der WordPress, Joomla, Shopware, Magento und viele andere Systeme auf dem Server laufen. In PHP selbst steckten zwei Fehler im Umgang mit dem Arbeitsspeicher. Sie tragen die Nummern CVE-2026-109618 und CVE-2026-109619, die Forscher nennen das Ganze „PHP2Shell“. Laut den Sicherheitshinweisen des PHP-Projekts lässt sich über eine präparierte Anfrage, zum Beispiel ein manipuliertes Formular- oder Upload-Paket (Fachbegriff: multipart/form-data), Schadcode einschleusen.

Wichtig für das Verständnis: Die Lücke liegt nicht in WordPress und nicht in einem Plugin. Sie liegt eine Ebene darunter. WordPress ist nur das bekannteste Beispiel. Sicherheitsforscher haben den Angriff auf einer aktuellen WordPress-Installation vorgeführt, andere Forscher nennen dazu Drupal, Joomla, Magento, Nextcloud und weitere Systeme. Betroffen ist im Grunde jede Seite, die eine ungepatchte PHP-Version nutzt.

Zur Ausnutzung gibt es unterschiedliche Angaben, und die sollten Sie kennen. Das PHP-Projekt, die US-Datenbank NVD und das EU-Notfallteam CERT-EU sagen nichts über laufende Angriffe. In der Liste der US-Behörde CISA für aktiv ausgenutzte Lücken standen beide Nummern am 21.10.2026 noch nicht, seit dem 26.10.2026 stehen sie dort (siehe Update oben). Ein Netzwerk- und Sicherheitsdienst schreibt dagegen am 21.10.2026, man habe „Angriffsverkehr gegen unsere Kunden beobachtet“. Ein Sicherheitsunternehmen rechnet mit massenhaften Angriffen, seit die Fehlerbeschreibungen öffentlich sind. Wir gehen davon aus, dass angegriffen wird.

Betrifft mich das? Die Zwei-Minuten-Prüfung

Sie brauchen die genaue PHP-Version Ihrer Seite. Zwei Wege führen dahin.

In WordPress melden Sie sich als Administrator an und öffnen Werkzeuge, dann Website-Zustand, dann den Reiter Info. Dort klappen Sie den Bereich „Server“ auf. In der Zeile „PHP-Version“ steht die Nummer, zum Beispiel 8.3.36.

Alternativ zeigt das Kundenmenü Ihres Hosters die PHP-Einstellung, meist unter „PHP-Version“ oder „PHP-Konfiguration“ beim jeweiligen Webspace.

Den Fix enthalten laut PHP-Projekt diese Stände und alle neueren: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Steht bei Ihnen eine kleinere Nummer in derselben Reihe, etwa 8.3.30, fehlt der offizielle Fix. Für 8.1, 8.0 und 7.x erscheint keine neue Version mehr. Das PHP-Projekt hat für 7.4, 8.0 und 8.1 nur Korrekturen am Quellcode nachgereicht, die ein Hoster selbst einbauen müsste. Offiziell unterstützt werden diese Versionen nicht mehr.

Kurzer Einschub zu älteren Nummern: Laut PHP-Projekt spielen manche Linux-Distributionen und Anbieter mit Langzeit-Support die Korrekturen auch in ältere Versionen ein. In WordPress steht dann unter Umständen weiterhin die alte Nummer. Eine ältere Nummer heißt also nicht zwingend, dass Ihre Seite ungeschützt ist. Klären lässt sich das nur mit einer kurzen Nachfrage beim Hoster.

Was Sie jetzt tun

Schreiben Sie Ihrem Hoster heute noch und fragen Sie, ob der PHP-Fix vom 21.10.2026 eingespielt ist. Viele Hoster aktualisieren von selbst. Bei Ihnen hängt aber die Frist davon ab, wann Ihr Anbieter das tut.

Läuft Ihre Seite noch auf 8.0 oder 8.1, stellen Sie im Kundenmenü auf 8.3 oder 8.4 um. 8.4 erhält laut php.net noch bis Ende 2028 Sicherheitsupdates, 8.2 nur noch bis 31.12.2026. Machen Sie vorher eine Sicherung. Ältere Plugins und Themes laufen auf neuem PHP nicht immer, deshalb gehört ein kurzer Test der Seite danach dazu.

Geht das Update nicht sofort, gibt es Zwischenlösungen auf Serverebene. Ihr Dienstleister kann solche Upload-Anfragen am Webserver sperren oder die PHP-Einstellung session.upload_progress.enabled abschalten. Letztere nennt das PHP-Projekt selbst als Ausweichlösung für einen Teil des Problems. Beides sollten Sie nicht auf eigene Faust einrichten. Gerade das Sperren der Upload-Anfragen legt Formulare, Bild-Uploads oder Shop-Funktionen lahm. Das PHP-Projekt sagt klar, dass nur das Update verlässlich schützt.

Was Ihr Sicherheits-Plugin nicht abfängt

Naheliegender Einwand: „Ich habe doch ein Sicherheits-Plugin“ oder „die Seite ist im Wartungsmodus“. Hilft beides nicht. Der Fehler sitzt in PHP selbst und greift, wenn PHP die Anfrage verarbeitet, also bevor WordPress und seine Plugins überhaupt starten. Der Netzwerk- und Sicherheitsdienst, der die Angriffe meldet (Quelle in der Liste unten), schreibt ausdrücklich, dass ein Update der Webseite oder einzelner Plugins diese Lücken nicht schließt.

Wer die Web-Firewall (einen Filter vor der Seite) dieses Dienstes vorgeschaltet hat, bekommt seit dem 21.10.2026 Schutzregeln. Der Dienst beschreibt aber, dass Angreifer bereits versuchen, diese Regeln mit umgebauten Anfragen zu umgehen. Ein Notbehelf, mehr nicht. Ob der Server zusätzlich direkt über seine IP erreichbar ist, entscheidet, wie viel der Filter überhaupt bringt.

War die Seite ungeschützt? Spuren prüfen

Lief Ihre Seite in den letzten Tagen auf einer alten Version, lohnt nach dem Update ein Blick auf typische Spuren. Allgemeine Einbruchsspuren, nicht speziell für diese Lücke: Neue PHP-Dateien im Ordner wp-content/uploads gehören dort in der Regel nicht hin, dort liegen normalerweise Bilder und Dokumente. Unbekannte Administrator-Konten in WordPress unter Benutzer sind ein Warnsignal. Sicherheitsforscher nennen außerdem Häufungen von Speicherfehlern („memory_limit“) und Fehlerseiten mit Code 500 im Server-Protokoll. Ob ein Angreifer schon drin war, lässt sich aus der Ferne nicht immer sicher sagen. Das ist unangenehm, aber ehrlicher als eine schnelle Entwarnung.

Checkliste

• Optional zuerst den kostenlosen Selbsttest für die eigene Domain nutzen. Bei „Nicht ermittelbar“ die Version wie folgt ablesen:
• PHP-Version in WordPress (Werkzeuge, Website-Zustand, Info, Server) oder im Hosting-Menü ablesen
• Mit 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 vergleichen
• Hoster fragen, ob der Fix vom 21.10.2026 eingespielt ist
• Bei 8.1 oder älter: Sicherung anlegen, auf 8.3 oder 8.4 umstellen, Seite testen
• Nach dem Update: uploads-Ordner auf PHP-Dateien und Benutzerliste auf fremde Admins prüfen

Wenn Sie das nicht selbst machen wollen

Der erste Schritt ist der kostenlose Selbsttest. Er zeigt, welche PHP-Version Ihre Seite nach außen meldet. Bleibt das Ergebnis gelb oder „Nicht ermittelbar“, ist unsere persönliche Prüfung der zweite Schritt. Kostenlos ist bei uns die Prüfung der PHP-Version, auch für Betriebe im Westerwald und Umgebung. Mit Ihrem Zugang zu WordPress oder zum Hosting-Menü sehen wir uns auf Wunsch auch nach den genannten Spuren um. Das gibt es nur nach schriftlicher Beauftragung samt Vereinbarung zur Auftragsverarbeitung (AV-Vereinbarung) und nach vorheriger Kostenabsprache. Von außen allein lassen sich Einbruchsspuren nicht prüfen. Schreiben Sie uns eine E-Mail an mpeter@expertomundi.de oder nutzen Sie die Schaltfläche „WhatsApp“.

Quellen (abgerufen am 21.10.2026)

• PHP-Projekt, Release-Meldung „PHP 8.4.27 Released!“ vom 21.10.2026: https://www.php.net/archive/2026.php#2026-10-21-3
• PHP-Projekt, Sicherheitshinweis vom 21.10.2026: https://www.php.net/archive/2026.php#2026-10-21-5
• PHP-Projekt, ChangeLog PHP 8: https://www.php.net/ChangeLog-8.php
• PHP-Projekt, unterstützte Versionen: https://www.php.net/supported-versions.php
• GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GitHub Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NVD, CVE-2026-109618: https://nvd.nist.gov/vuln/detail/CVE-2026-109618
• NVD, CVE-2026-109619: https://nvd.nist.gov/vuln/detail/CVE-2026-109619
• CERT-EU, Security Advisory 2026-018 „Critical Vulnerabilities in PHP“: https://cert.europa.eu/publications/security-advisories/2026-018/
• CISA, Known Exploited Vulnerabilities Catalog (Version 2026.10.27, Abruf 28.10.2026): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Cloudflare, „Cloudflare deploys protections against php2shell vulnerability“: https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
• Wiz Research: https://www.wiz.io/blog/php2shell-php-rce
• Sansec, PHP2Shell: https://sansec.io/research/php2shell

Stand: 28.10.2026, aktualisiert um die CISA-Aufnahme.

Neun von zehn neu in unsere Datenbank aufgenommenen Sicherheitslücken stehen bereits im Known Exploited Vulnerabilities Catalog der CISA, der US-Behörde führt dort nur Schwachstellen, für die reale Angriffe dokumentiert sind, keine theoretischen Risikobewertungen. Wer WordPress betreibt, Microsoft SharePoint oder AD FS im Einsatz hat, oder Oracle E-Business Suite, Fortinet FortiSandbox beziehungsweise Check Point Quantum nutzt, sollte diese Liste nicht überfliegen, sondern gegen die eigene Systemlandschaft abgleichen.

Zwei der zehn Lücken betreffen direkt unser WordPress-Kundensegment, eine davon im WordPress-Kern selbst. Die übrigen acht liegen in Software, die vor allem mittelständische und größere Unternehmen mit eigener IT-Infrastruktur einsetzen. Alle Angaben stammen aus den jeweiligen CVE-Records unter cve.org und dem CISA-KEV-Katalog, Stand der Prüfung ist der 27. Juli 2026.

WordPress-Kern: SQL-Injection als Teil einer RCE-Kette

CVE-2026-60137 sitzt im author__not_in-Parameter von WP_Query, dem zentralen Abfrage-Mechanismus des WordPress-Kerns. Schwachstellenklasse CWE-89, SQL-Injection. Beim CVSS-Wert klaffen zwei Bewertungen auseinander: Die CISA setzt in ihrer eigenen Anreicherung 9.1 an, der zuweisende CNA (WPScan) selbst vergibt nur 5.9 MEDIUM (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N). Die Spreizung entsteht, weil die Lücke isoliert eine Vorbedingung braucht, in der weiter unten beschriebenen Verkettung aber nicht. Die CISA hat die Lücke am 21. Juli 2026 in den KEV-Katalog aufgenommen, laut Rapid7 und SecurityWeek kursierte ein öffentlicher Proof of Concept bereits wenige Stunden nach der Offenlegung am 17. Juli.

Was die Lücke besonders macht: Sicherheitsforscher haben sie als Teil einer Kette bezeichnet, die unter dem Namen „wp2shell“ kursiert. In Kombination mit CVE-2026-63030, selbst seit dem 21. Juli im KEV-Katalog, CVSS 9.8, CWE-436 (fehlerhafte Typumwandlung), lässt sich daraus eine unauthentifizierte Remote Code Execution bauen, also die vollständige Übernahme der Webseite ohne jeden Zugangsdatensatz. Bei der SQL-Injection allein sind die Versionsreihen 6.8.0 bis 6.8.5, 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1 betroffen. Der zur RCE verkettbare zweite Teil, CVE-2026-63030, betrifft laut offizieller WordPress-Release-Notiz dagegen nur die Reihen 6.9.x und 7.0.x, WordPress 6.8 ist davon ausdrücklich ausgenommen. Der Fix liegt in 6.8.6, 6.9.5 beziehungsweise 7.0.2.

GF-Klartext: Läuft Ihre Webseite auf WordPress und wurde seit Mitte Juli kein Update eingespielt, ist das kein Punkt für die nächste Wartungsrunde. WordPress.org hat für die drei betroffenen Versionsreihen inzwischen erzwungene Auto-Updates aktiviert, viele Installationen dürften also bereits automatisch auf 6.8.6, 6.9.5 oder 7.0.2 stehen. Trotzdem gilt: aktiv ausgenutzte Lücke, öffentlicher Exploit-Code, und bei 6.9.x/7.0.x zusätzlich die Kombination zu einer kompletten Serverübernahme. Prüfen Sie aktiv bei Ihrer Agentur oder Ihrem Hoster den eigenen Versionsstand, statt sich allein auf das Auto-Update zu verlassen.

Kirki-Plugin: Kontoübernahme über den Passwort-Reset

Themeum Kirki ist mit 500.000 aktiven Installationen laut Plugin-Verzeichnis ein weit verbreiteter WordPress-Page-Builder. CVE-2026-8206, CVSS 9.8, betrifft eine fehlerhafte Rechteverwaltung nach CWE-269 beim Passwort-Zurücksetzen: Sobald ein Angreifer den Benutzernamen kennt, kann er beim Reset eine beliebige E-Mail-Adresse angeben und übernimmt damit das Konto, im schlimmsten Fall ein Administratorkonto.

Anders als die WordPress-Kern-Lücke steht Kirki nach aktuellem Stand nicht im CISA-KEV-Katalog, es gibt also keine bestätigten aktiven Angriffe. Bei einem CVSS-Wert von 9.8 und einem derart einfach auszuführenden Angriffsweg, ein Benutzername reicht als Vorwissen, würde ich mich darauf trotzdem nicht verlassen. Betroffen sind die Versionen 6.0.0 bis 6.0.6, gefixt in 6.0.7.

Microsoft SharePoint: drei Lücken, eine Schwachstellenklasse

Drei der zehn CVEs betreffen SharePoint Server in den Editionen 2016, 2019 und Subscription Edition, alle drei stehen im CISA-KEV-Katalog:

CVE-2026-50522 und CVE-2026-58644 teilen sich dieselbe Schwachstellenklasse, Deserialisierung nicht vertrauenswürdiger Daten nach CWE-502, beide mit CVSS 9.8 und beide unauthentifiziert über das Netz ausnutzbar für Remote Code Execution. Die CISA hat 50522 am 22. Juli, 58644 bereits am 16. Juli in den KEV-Katalog aufgenommen. CVE-2026-56164 liegt mit CVSS 5.3 deutlich niedriger, betrifft aber eine fehlende Authentifizierung für eine kritische Funktion nach CWE-306 und führt zu unauthentifizierter Rechteausweitung, Aufnahme in den KEV-Katalog am 14. Juli.

Die betroffenen Build-Untergrenzen unterscheiden sich je nach CVE und Edition, grob liegen sie bei SharePoint 2016 unterhalb Build 16.0.5561.1001 beziehungsweise 16.0.5556.1005, bei SharePoint 2019 unterhalb 16.0.10417.20175 beziehungsweise 16.0.10417.20153, bei der Subscription Edition unterhalb 16.0.19725.20434 beziehungsweise 16.0.19725.20384. Wer SharePoint on-premises betreibt, sollte die genaue Build-Nummer der eigenen Installation gegen den jeweiligen CVE-Record prüfen, nicht gegen diese vereinfachte Zusammenfassung.

Techniker-Klartext: Zwei kritische Deserialisierungslücken mit CVSS 9.8 in derselben Produktfamilie, beide aktiv ausgenutzt, das ist kein Zufall, sondern deutet auf systematisches Scannen von SharePoint-Farmen durch Angreifergruppen hin. Wer noch keinen aktuellen Patch-Stand hat, sollte den Zugriff auf SharePoint-Endpunkte von außen zusätzlich über eine Web Application Firewall einschränken, bis das Update läuft.

Active Directory Federation Services: die Ausnahme mit lokalem Angriffsvektor

CVE-2026-56155 betrifft Microsofts AD FS, CVSS 7.8, unzureichende Zugriffskontroll-Granularität nach CWE-1220, führt zu lokaler Rechteausweitung. Die CISA hat die Lücke am 14. Juli in den KEV-Katalog aufgenommen, sie ist damit die einzige der neun KEV-Lücken in diesem Artikel mit lokalem statt Remote-Angriffsvektor, ein Angreifer braucht bereits eine gewisse Position im System, bevor er sie ausnutzen kann.

Für einen reinen Website-Scan von außen ist das kein direkt sichtbares Risiko. Relevant wird es für jeden, der Windows Server zwischen 2012 und 2025 mit AD FS betreibt, die genauen Build-Grenzen stehen im CVE-Record. Der Fix liegt im Juli-2026-Kumulativupdate von Microsoft.

Oracle E-Business Suite: unauthentifizierte Vollübernahme über HTTP

CVE-2026-46817 betrifft das Zahlungsmodul Oracle Payments innerhalb der Oracle E-Business Suite, CVSS 9.8. Der Oracle-eigene Record führt keine CWE-Klassifizierung, die CISA-Anreicherung in der NVD ordnet die Lücke CWE-269, CWE-287 und CWE-306 zu, der KEV-Titel selbst spricht von „Improper Privilege Management“ (CWE-269). Ein Angreifer braucht kein Konto, keine Anmeldedaten, nur einen präparierten HTTP-Request, und kann das betroffene System vollständig übernehmen. Aufnahme in den CISA-KEV-Katalog am 15. Juli, die CISA-Frist lief bereits am 18. Juli ab. Betroffen sind die Versionen 12.2.3 bis 12.2.15. Der Patch liegt seit dem Oracle Critical Security Patch Update vom Mai 2026 vor, wer noch nicht aktualisiert hat, hängt also nicht auf einen künftigen Termin, sondern einer bereits verfügbaren Lösung hinterher.

Oracle E-Business Suite ist typischerweise tief in Buchhaltung, Personalwesen und Lieferkette eines Unternehmens verankert, eine Kompromittierung betrifft selten nur eine Anwendung, sondern den gesamten Datenbestand dahinter.

Fortinet FortiSandbox: zwei Lücken, ein Muster

CVE-2026-25089 und CVE-2026-39808 betreffen beide FortiSandbox, jeweils CVSS 9.1, Betriebssystem-Command-Injection nach CWE-78. Ein Angreifer ohne Zugangsdaten kann Code auf dem System ausführen. Bei CVE-2026-25089 nennt der CVE-Record dafür explizit präparierte HTTP-Requests als Angriffsweg; bei CVE-2026-39808 ist dieser Weg im Record nicht so benannt, der Mechanismus ist dieselbe Schwachstellenklasse, aber nicht identisch dokumentiert. Beide stehen seit dem 16. Juli im CISA-KEV-Katalog.

CVE-2026-25089 betrifft die Versionsreihen 5.0.0 bis 5.0.5, 4.4.0 bis 4.4.8 sowie 4.2.1 bis 4.2.8, gefixt in 5.0.6, 5.2.0 beziehungsweise 4.4.9, hier ist auch die Cloud-/PaaS-Variante betroffen. CVE-2026-39808 betrifft nur 4.4.0 bis 4.4.8, gefixt in 4.4.9 beziehungsweise, bei der PaaS-Variante, 5.0.2, hier ist ausschließlich die PaaS-Variante betroffen, nicht die reguläre Cloud-Variante. FortiSandbox wird eingesetzt, um verdächtige Dateien in einer isolierten Umgebung zu analysieren, die Ironie einer Sicherheitslösung mit einer eigenen kritischen Lücke muss ich an dieser Stelle nicht weiter ausführen.

Check Point Quantum: Admin-Zugriff ohne Anmeldedaten

CVE-2026-16232 betrifft Check Point Quantum und Multi-Domain Security Management über die SmartConsole, CVSS 9.1 nach Version 3.1, 9.3 nach der neueren Version 4.0. Schwachstellenklasse CWE-287, Authentifizierungs-Bypass: ein unauthentifizierter Angreifer aus der Ferne erlangt einen Admin-Token. Aufnahme in den CISA-KEV-Katalog am 22. Juli, damit die aktuellste Aufnahme unter den zehn hier behandelten Lücken.

Betroffen sind mehrere Versionslinien gleichzeitig: R82.10 bis einschließlich Jumbo-Take 36, R82 bis Take 118, R81.20 bis Take 158, sowie die älteren Linien R81.10, R81, R80.x und R77.30. Check Point stellt den Fix über einen Jumbo Hotfix bereit, dokumentiert unter der Support-Kennung sk185169.

GF-Klartext: Eine Security-Management-Konsole ohne Zugangsdaten öffnen zu können, ist der worst case innerhalb einer Sicherheitsinfrastruktur. Wer Check Point Quantum einsetzt, sollte beim eigenen IT-Dienstleister aktiv nachfragen, ob der Jumbo Hotfix bereits eingespielt ist, nicht warten, bis die nächste reguläre Wartung ansteht.

Patch-Priorisierung: Reihenfolge statt Gleichbehandlung

Zehn neue Lücken auf einmal lassen sich nicht alle am selben Nachmittag abarbeiten. Eine sinnvolle Reihenfolge orientiert sich am CISA-KEV-Status und am Angriffsvektor, nicht am CVSS-Wert allein:

Zuerst die neun Lücken mit bestätigter aktiver Ausnutzung, priorisiert nach Erreichbarkeit von außen: WordPress-Kern und SharePoint zuerst, weil beide unauthentifiziert über das offene Netz erreichbar sind, danach Oracle E-Business Suite und Fortinet FortiSandbox aus demselben Grund, dann Check Point Quantum. AD FS mit seinem lokalen Angriffsvektor kann etwas später folgen, ohne dass dadurch das Risiko verschwindet. Kirki steht zwar nicht im KEV-Katalog, der CVSS-Wert von 9.8 und der triviale Angriffsweg rechtfertigen trotzdem eine zeitnahe statt eine aufgeschobene Behandlung. Zusätzliches Dringlichkeitsargument: Bei acht der neun KEV-Einträge aus diesem Artikel ist die von der CISA gesetzte Behebungsfrist bereits verstrichen, wer hier noch nicht gepatcht hat, arbeitet nicht mehr gegen ein Datum in der Zukunft, sondern gegen eine bereits überschrittene Deadline.

Wer WordPress im Einsatz hat, für den ist die Reihenfolge ohnehin klar: Kern-Update zuerst, weil hier bereits ein öffentlicher Exploit kursiert, Kirki-Update direkt danach.

Vollständige Datenbank statt Einzelartikel

Dieser Artikel behandelt zehn von inzwischen mehreren hundert Einträgen in unserer CVE-Sammlung. Wer prüfen will, ob eine bestimmte Software, ein bestimmter Hersteller oder eine bestimmte Schweregrad-Kategorie in unserer Datenbank vertreten ist, findet die durchsuchbare Vollliste unter expertomundi.de/wissen/cve-datenbank/, mit Filterfunktion nach Hersteller, Plattform und CVSS-Bereich.

Quellen

• CVE-2026-60137 (WordPress Core): cve.org/CVERecord?id=CVE-2026-60137, CISA-KEV-Aufnahme 21.07.2026
• CVE-2026-63030 (WordPress Core, RCE-Teil der wp2shell-Kette): cve.org/CVERecord?id=CVE-2026-63030, CISA-KEV-Aufnahme 21.07.2026
• CVE-2026-8206 (Themeum Kirki): cve.org/CVERecord?id=CVE-2026-8206
• CVE-2026-50522 (Microsoft SharePoint): cve.org/CVERecord?id=CVE-2026-50522, CISA-KEV-Aufnahme 22.07.2026
• CVE-2026-58644 (Microsoft SharePoint): cve.org/CVERecord?id=CVE-2026-58644, CISA-KEV-Aufnahme 16.07.2026
• CVE-2026-56164 (Microsoft SharePoint): cve.org/CVERecord?id=CVE-2026-56164, CISA-KEV-Aufnahme 14.07.2026
• CVE-2026-56155 (Microsoft AD FS): cve.org/CVERecord?id=CVE-2026-56155, CISA-KEV-Aufnahme 14.07.2026
• CVE-2026-46817 (Oracle E-Business Suite): cve.org/CVERecord?id=CVE-2026-46817, CISA-KEV-Aufnahme 15.07.2026
• CVE-2026-25089 (Fortinet FortiSandbox): cve.org/CVERecord?id=CVE-2026-25089, CISA-KEV-Aufnahme 16.07.2026
• CVE-2026-39808 (Fortinet FortiSandbox): cve.org/CVERecord?id=CVE-2026-39808, CISA-KEV-Aufnahme 16.07.2026
• CVE-2026-16232 (Check Point Quantum/Multi-Domain): cve.org/CVERecord?id=CVE-2026-16232, CISA-KEV-Aufnahme 22.07.2026
• CISA Known Exploited Vulnerabilities Catalog: cisa.gov/known-exploited-vulnerabilities-catalog
• Vollständige, filterbare Datenbank: expertomundi.de/wissen/cve-datenbank/

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 27.07.2026. Er ersetzt keine individuelle Sicherheitsprüfung der eigenen Systeme und keine anwaltliche Einschätzung etwaiger Meldepflichten.

Ein Cookie mit dem Namen .AspNetCore.Cookies beendet die Diskussion, bevor sie angefangen hat. Wer dieses Cookie im Entwicklertools-Fenster einer Website sieht, weiß mit Sicherheit: Hier läuft ASP.NET Core. Keine Vermutung, kein Bauchgefühl, sondern ein Beweis, der sich in Sekunden prüfen lässt, ohne einen einzigen Scan zu starten. Die meisten Fragen zum eingesetzten Tech-Stack sind allerdings nicht so eindeutig zu beantworten, und genau darum geht es hier: um die vielen kleinen Spuren, die ein Microsoft-Stack im Alltag hinterlässt, und um die Frage, wie belastbar jede einzelne davon eigentlich ist.

Warum das überhaupt jemanden interessiert

Für IT-Verantwortliche ist die Antwort naheliegend: Was von außen über die eigene Infrastruktur erkennbar ist, sollten sie kennen, bevor es jemand anderes für sie herausfindet. Wer weiß, dass sein Server-Header offenherzig Kestrel verrät, kann eine bewusste Entscheidung treffen, ob das so bleiben soll. Für Auditoren und technisch Interessierte ist die Fragestellung aus einem anderen Grund relevant: Stack-Erkennung ist die Grundlage jeder seriösen technischen Bestandsaufnahme, und die Qualität dieser Erkennung hängt komplett davon ab, wie gut man zwischen sicherem Beweis und bloßer Vermutung unterscheidet.

Klartext für Geschäftsführer: Ihre Website verrät im Hintergrund technische Details, die für Sie unsichtbar sind, aber für jeden, der sie ansieht, öffentlich einsehbar. Das ist erst einmal kein Sicherheitsproblem, viele dieser Signale lassen sich mit vertretbarem Aufwand reduzieren, ohne dass ein Techniker die Seite umbauen muss. Ein Signal aus diesem Artikel ist allerdings kein bloßes Detail, sondern ein handfestes Risiko: eine öffentlich sichtbare Fehlerseite mit Stacktrace, dazu gleich mehr.

Die direkten Spuren: Header, Cookies, Pfade

Ein Response-Header ist der ehrlichste Ort, um nach einem Microsoft-Stack zu suchen, weil der Server hier oft ungefragt Auskunft gibt. Server: Kestrel oder Microsoft-IIS/10.0 steht in vielen Fällen einfach so im Klartext in der Antwort, X-Powered-By: ASP.NET ebenso. Etwas versteckter, aber genauso aussagekräftig sind X-AspNet-Version und X-AspNetMvc-Version, die konkrete Framework-Versionen preisgeben, sowie x-ms-request-id und x-azure-ref, zwei Header, die praktisch nur bei Azure-gehosteten Diensten auftauchen. Der Header Request-Context: appId=cid-v1:xxxxxxxx gehört zu Application Insights, Microsofts Telemetrie-Dienst, und verrät damit gleich zwei Dinge auf einmal: den Stack und das Monitoring-Setup dahinter.

Cookies sind die zweite große Kategorie direkter Spuren, und sie sind oft noch eindeutiger als Header, weil sie an sehr spezifische Frameworks gebunden sind. .AspNetCore.Cookies, .AspNetCore.Antiforgery oder .AspNetCore.Session bedeuten ASP.NET Core, Punkt. ARRAffinity und die zugehörige ARRAffinitySameSite-Variante gehören zum Load Balancing von Azure App Service. ai_user und ai_session stammen vom Browser-SDK von Application Insights. Und ein Cookie namens idsrv deutet auf Duende IdentityServer oder dessen Vorgänger hin, den De-facto-Standard für Identity- und Auth-Server im .NET-Ökosystem.

Bei den Pfaden und Assets wird es noch konkreter, weil hier ganze Frameworks ihre Fingerabdrücke im Verzeichnisbaum hinterlassen. /_framework/blazor.web.js gehört zu Blazor, Microsofts Web-UI-Framework, /_framework/dotnet.js speziell zur WebAssembly-Variante davon, und /_blazor markiert einen Blazor-Server-Endpunkt mit einer dauerhaften SignalR-Verbindung zum Server. Endet ein Pfad auf /negotiate, handelt es sich fast immer um SignalR, Microsofts Echtzeit-Kommunikationsbibliothek. Und wo /swagger oder /openapi.json erreichbar sind, liegt darunter fast immer eine ASP.NET-Core-Web-API, die ihre eigene Dokumentation öffentlich mitliefert.

Eine vierte, oft übersehene Signalquelle ist das Telemetrie-JavaScript selbst. Skripte mit Namen wie ai.2.min.js oder Referenzen auf applicationinsights im Quellcode, Requests an dc.services.visualstudio.com oder an *.in.applicationinsights.azure.com, der traceparent-Header nach dem W3C-Trace-Context-Standard, und ein globales window.appInsights-Objekt im Browser-Kontext: All das läuft unter der Haube, sobald eine Seite Application Insights zum Monitoring einsetzt, und ist mit den Bordmitteln jedes Browsers sichtbar.

Indirekte Spuren: DNS und Zertifikat

Wo direkte Spuren fehlen, hilft ein Blick auf die Infrastruktur dahinter. Ein CNAME-Eintrag, der auf eine Subdomain unter azurewebsites.net zeigt, verrät App Service, azure-api.net steht für API Management, azurefd.net für Azure Front Door, blob.core.windows.net für Blob Storage und azureedge.net für das CDN. Auch ein TLS-Zertifikat kann sprechen: Taucht im Subject Alternative Name eine interne azurewebsites.net-Subdomain auf, die eigentlich nicht für die Öffentlichkeit gedacht war, ist das ein klarer Hinweis auf die zugrunde liegende Hosting-Plattform, unabhängig davon, welcher Domainname vorne im Browser steht.

Verhaltens-Signale: wie der Server auf Fehler reagiert

Manchmal verrät sich ein Stack nicht durch das, was er sendet, sondern durch das, wie er auf Fehler reagiert. Eine 400er-Antwort im ProblemDetails-Format nach RFC 7807, erkennbar am charakteristischen JSON mit den Feldern type, title, status und detail, ist das Standard-Fehlerformat von ASP.NET Core. Ein Endpunkt unter /health oder /healthz, der mit dem einzelnen Wort „Healthy“ antwortet, folgt der Namenskonvention der .NET-Health-Checks-Bibliothek.

Der wichtigste Punkt in dieser Kategorie ist aber keine reine Erkennungshilfe, sondern ein eigenständiges Sicherheitsproblem: eine öffentlich erreichbare Developer-Exception-Page. Diese Seite ist in ASP.NET Core standardmäßig für die Entwicklungsumgebung gedacht und zeigt im Fehlerfall den vollständigen Stacktrace, interne Dateipfade und teilweise sogar Umgebungsvariablen an. Landet sie versehentlich in der Produktion, verrät sie nicht nur den Stack, sondern liefert einem Angreifer eine Bauanleitung für die eigene Infrastruktur frei Haus. Wer diese Seite bei einem eigenen Dienst öffentlich erreichbar findet, sollte das nicht als Kuriosität behandeln, sondern als High-Finding in jedem ernst gemeinten Bericht.

Klartext für Techniker: Die Developer-Exception-Page lässt sich mit einer einzigen Zeile in Program.cs abschalten (app.UseExceptionHandler statt app.UseDeveloperExceptionPage() außerhalb der Development-Umgebung). Trotzdem taucht sie in der Praxis immer wieder produktiv auf, meist weil eine Umgebungsvariable falsch gesetzt ist oder ein Staging-Deployment versehentlich zum Live-System wurde.

Wie sicher ist ein Fund wirklich? Die vier Stufen

Nicht jedes Signal ist gleich viel wert, und genau hier passiert der häufigste Fehler bei technischer Bestandsaufnahme: ein einzelnes schwaches Indiz wird als Gewissheit verkauft. Vier Stufen helfen, das sauber zu trennen.

Sicher ist ein Fund, wenn ein einzelnes Signal keine andere Erklärung zulässt. Das Cookie .AspNetCore.Cookies gehört in diese Kategorie: Es existiert nur, wenn ASP.NET Core Authentication tatsächlich läuft.

Stark indiziert ist ein Fund, wenn mehrere unabhängige Signale in dieselbe Richtung zeigen, aber theoretisch auch anders erklärbar wären. Ein ARRAffinity-Cookie zusammen mit einem CNAME auf eine azurewebsites.net-Domain ergibt zusammen ein sehr stimmiges Bild, auch wenn keines der beiden Signale für sich allein hundertprozentig wäre.

Bloße Vermutung ist ein Fund, wenn sich eine Website wie eine typische ASP.NET-Core-Anwendung verhält, ohne dass ein einziger harter Marker auftaucht, kein passendes Cookie, kein verräterischer Header. Solche Vermutungen gehören in einen Bericht, aber klar als Vermutung gekennzeichnet, nicht als Tatsache formuliert.

Intern bestätigt ist die höchste Stufe, aber sie erfordert einen Blick hinter die Fassade, der von außen gar nicht möglich ist: Ein Eintrag wie Microsoft.ApplicationInsights.AspNetCore in der .csproj-Datei des Projekts belegt den Stack zweifelsfrei, setzt aber internen Zugriff auf den Quellcode voraus. Für externe Betrachter bleibt diese Stufe unerreichbar, und genau das ist der entscheidende Unterschied zu den ersten drei Stufen.

Klartext für Geschäftsführer: Wenn Ihnen jemand sagt „Ihre Seite läuft auf Azure“, fragen Sie nach, worauf sich das stützt. Ein Cookie-Name ist ein Beweis. Ein „sieht danach aus“ ist eine Meinung. Der Unterschied entscheidet darüber, ob eine Aussage in einem Bericht Gewicht hat oder nicht.

Die Grenze, die zählt: nur passiv, nie ohne Freigabe

Alle bisher genannten Signale lassen sich beobachten, ohne einen einzigen ungewöhnlichen Request abzusetzen. Ein Header lesen, ein Cookie im Browser ansehen, einen DNS-Eintrag abfragen, eine ohnehin öffentlich erreichbare Seite mit ihrem regulären Aufruf laden: Das sind passive, nicht-invasive Checks, die technisch nicht anders aussehen als ein gewöhnlicher Website-Besuch.

Damit endet aber auch die Grenze dessen, was ohne Zustimmung des Betreibers vertretbar ist. Wer testet, ob ein /swagger-Endpunkt existiert, bewegt sich noch im passiven Bereich. Wer beginnt, Pfade systematisch durchzuprobieren, Authentifizierung zu umgehen oder gezielt nach ausnutzbaren Schwachstellen zu suchen, verlässt diesen Bereich und braucht eine ausdrückliche Freigabe des Betreibers. Brute-Forcing, Fuzzing oder gar der Versuch, eine erkannte Schwäche tatsächlich auszunutzen, sind ohne diese Freigabe nicht bloß eine Stilfrage, sondern strafrechtlich relevant. Diese Grenze gilt unabhängig davon, wie interessant ein gefundenes Signal aussieht.

Was das für die eigene Website bedeutet

Wer diese Signale kennt, kann sie an der eigenen Infrastruktur gegenprüfen. Bei vielen Unternehmens-Webseiten, die auf Azure App Service laufen, reicht schon ein Blick in die Browser-Entwicklertools, um ARRAffinity, einen x-azure-ref-Header und mitunter sogar den Application-Insights-Instrumentation-Key im Quelltext zu finden, ganz ohne dass jemand danach gesucht hätte. Keines dieser Signale ist für sich genommen ein Sicherheitsproblem, aber in der Summe zeichnen sie ein Bild der eingesetzten Technik, das nicht jeder Betreiber bewusst so öffentlich stehen lassen wollte. Wer die eigene Angriffsfläche kennt, kann selbst entscheiden, welche Header verzichtbar sind und welche Fehlerseite in der Produktionsumgebung wirklich nichts zu suchen hat.

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 26.07.2026. Aktives Testen fremder Systeme ohne Zustimmung des Betreibers kann strafrechtlich relevant sein (§ 202a ff. StGB).