Am Montagmorgen, dem 11. Mai 2026 um 8:47 Uhr deutscher Zeit, sass Markus Petersen, IT-Leiter eines mittelstaendischen Maschinenbauers mit 480 Mitarbeitenden im westfaelischen Hinterland, vor seinem zweiten Espresso, als die Push-Benachrichtigung kam. Heise hatte einen Artikel veroeffentlicht: "Google: Cyberkriminelle haben erstmals KI fuer Zero-Day-Exploit eingesetzt". Petersen las die ersten zwei Absaetze. Er las sie noch einmal. Dann lehnte er sich zurueck, schaute aus dem Fenster auf den Mitarbeiterparkplatz und sagte halblaut: "Das war es dann mit den ruhigen Wochen."

Petersen arbeitet seit 14 Jahren bei der Firma. Er kennt jeden Server, jede Datenbank, jeden VPN-Konzentrator persoenlich. Er hat den NIS2-Antrag im Februar abgegeben, das ISMS nach BSI IT-Grundschutz Profil-Mittelstand letzten Sommer zertifiziert, den jaehrlichen Pentest mit drei kritischen Findings hinter sich gebracht. Sein Sicherheitsbudget liegt fuer 2026 bei knapp 1,1 Millionen Euro, das ist ueberdurchschnittlich fuer seine Branche, und er weiss es. Trotzdem las er den GTIG-Bericht und hatte das Gefuehl, dass eine Saeule seiner Verteidigung gerade ihren Belastbarkeitsausweis verloren hat.

Diese User Story ist fiktiv, aber sie ist nicht erfunden. Wir haben in den letzten Wochen mit einem guten Dutzend Petersen-Aequivalenten gesprochen. Die Gespraeche kreisen alle um dieselbe Frage: Was bedeutet es konkret, dass Maschinen jetzt Bugs in fremder Software finden und in funktionierende Exploits verwandeln? Und welche Konsequenzen muss eine Sicherheitsarchitektur ziehen, die in den fruehen 2010ern fuer eine andere Bedrohungslage entworfen wurde?

Der GTIG-Befund in einer Zeile

Google Threat Intelligence Group hat am 11. Mai 2026 mit hoher Konfidenz dokumentiert, dass ein krimineller Akteur ein Sprachmodell genutzt hat, um eine 2FA-Umgehung in einer populaeren Open-Source-Plattform fuer Web-Systemadministration zu finden und in einen funktionierenden Python-Exploit zu verwandeln. Geplant war ein Massenausbruch gegen exponierte Installationen. Google koordinierte mit dem Hersteller, ein Patch wurde gezogen, die Welle blieb aus. Diesmal.

Die forensischen Indizien fuer den KI-Einsatz waren unter anderem ein halluzinierter CVSS-Score, der nicht zur Schwachstelle passte, eine textbuchartige Python-Struktur und paedagogische Docstrings, die kein Menschen-Entwickler in ein Untergrund-Tool schreibt. Wir haben den technischen Hergang in unserem aktuellen Blogbeitrag zum Vorfall ausfuehrlich beschrieben. Was bislang fehlte, ist die Einordnung: Wie veraendert sich eine mittelstaendische Sicherheitsarchitektur, wenn man diesen Befund ernst nimmt?

Petersens Architektur: Was er heute hat

Bleiben wir bei Markus Petersen. Sein Mittelstandsunternehmen produziert Sondermaschinen fuer Verpackungstechnik. Drei Werke in Deutschland, zwei Niederlassungen in Polen und Tschechien, 480 Mitarbeitende, davon 65 in der Entwicklung. Petersens IT-Setup ist typisch:

Er hat einen Microsoft-365-Tenant fuer Mail und Office, ein lokales Active Directory mit Verbund nach Azure AD, ein SAP-S/4HANA on-premises, ein Engineering-Cluster fuer CAD und Simulation, ein Werks-OT-Netzwerk mit Profinet-Bus, ein Customer-Portal auf Basis eines Open-Source-CMS, einen SonicWall-SSL-VPN fuer Homeoffice und externe Berater, einen Cisco-Router-Stack als Perimeter und einen Splunk-SIEM mit drei Vollzeitkraeften im Security Operations Center, das von einem Partner aus Hannover gestellt wird.

Dazu kommt ein Wildwuchs an Werkzeugen, die ueber die Jahre dazugekommen sind: ein Confluence fuer Doku, eine Jira-Instanz fuer Tickets, ein GitLab-Server fuer Steuerungssoftware, eine Bookstack-Instanz im Vertrieb, ein Nextcloud-Server fuer Lieferantenaustausch, ein Mailcow-Server fuer Newsletter, ein Portainer-Adminpanel fuer die Container-Hosts in der Entwicklung, ein Grafana-Stack fuer Werks-OEE-Dashboards, ein selbst gehostetes n8n fuer Automatisierungs-Workflows zwischen SAP und CRM. Petersen kennt jede dieser Komponenten. Er kann auch fuer jede sagen, wer sie installiert hat, wann zuletzt gepatcht wurde, ob 2FA aktiv ist.

Was er nicht zuverlaessig sagen kann, ist: Hat jede dieser Komponenten einen einzigen, durchgaengigen 2FA-Erzwingungspfad? Oder gibt es API-Endpunkte, Webhook-Handler, Mobile-Backends, Service-Tokens, die unter der Haube anders authentifizieren? Genau diese Frage stellt der GTIG-Bericht.

Der erste Bruch: Das Vertrauensmodell stimmt nicht mehr

Die klassische Mittelstandsarchitektur baut auf einer Hierarchie der Vertrauenszonen auf. Internet ist boese, DMZ ist halb-boese, internes Netz ist gut, Server-VLAN ist sehr gut. Patches werden eingespielt, weil bekannte CVEs existieren und Scanner sie melden. 2FA wird aktiviert, weil der Auditor es verlangt. Und das interne Netz bleibt das Reservat, in dem Software vertrauenswuerdig sein darf, weil es ja kein Fremder erreichen kann.

Dieses Modell hat zwei stille Annahmen, die der GTIG-Vorfall aufruettelt. Annahme eins: Schwachstellen werden gefunden, weil Forscher menschliche Stunden investieren, und Menschen sind teuer. Annahme zwei: Was nicht aus dem Internet erreichbar ist, wird auch nicht entdeckt. Beide Annahmen halten in einer Welt mit KI-gestuetzter Code-Analyse nicht. Wenn ein Sprachmodell eine offene Codebasis lesen kann – und Open-Source-Code ist per Definition offen – dann kann es Schwachstellen finden, ohne dass jemand sie aktiv suchen muss. Und wenn der Exploit einmal existiert, dann ist die Frage nicht mehr, ob ein Angreifer Ihr internes Bookstack erreicht, sondern wie er es erreicht. Phishing-Mail, Browser-Exploit, kompromittiertes Lieferanten-Login, missbrauchter Service-Account.

Petersen erkannte das, als er nach dem Heise-Artikel ein internes Inventar aller Open-Source-Werkzeuge anlegte. Er kam auf 31 Komponenten. Von diesen 31 waren acht direkt aus dem Internet erreichbar (durch absichtliche Veroeffentlichung oder durch Konfigurationsdrift), elf waren ueber das VPN erreichbar und 12 nur intern. Auf der Liste standen zwei Tools, deren letzte Aktualisierung mehr als sechs Monate zurueck lag. Eines davon: ein Portainer mit eigenem 2FA-Stack, das sein Entwicklerkollege "wegen der API-Anbindung" mal anders konfiguriert hatte.

Der zweite Bruch: Geschwindigkeit

Mandiants M-Trends-Report fuer 2026 berichtet, dass 28,3 Prozent aller CVEs innerhalb von 24 Stunden nach Veroeffentlichung in freier Wildbahn ausgenutzt werden. Diese Zahl war vor zwei Jahren bei knapp ueber zehn Prozent. Mit KI-gestuetzter Exploit-Entwicklung wird sie weiter steigen. Praktisch heisst das: Ihr Patch-Fenster fuer kritische Schwachstellen ist 24 Stunden, nicht eine Woche, nicht ein Monat, nicht das naechste Wartungsfenster.

Petersens IT-Abteilung kann das in der Theorie. In der Praxis schliesst sein OT-Wartungsfenster fuer die Werks-SCADA monatlich, sein SAP-Patchfenster quartalsweise, sein VPN-Patchfenster freitags. Wenn am Dienstag eine kritische SonicWall-Luecke veroeffentlicht wird, kann er entweder das Wartungsfenster brechen (mit Produktionsrisiko) oder vier Tage warten (mit Ausnutzungsrisiko). Das war schon vor dem 11. Mai 2026 ein ungeloestes Problem. Es wird durch KI-gebaute Exploits scharfer, nicht milder.

Die Antwort kann nicht "schneller patchen" sein, weil das Wartungsfenster nicht aus Bequemlichkeit existiert, sondern aus Risiko. Die Antwort muss lauten: Reduzieren Sie die Angriffsoberflaeche, sodass weniger Komponenten kritische Patch-Pflichten haben. Konkret bedeutet das: Web-Adminoberflaechen hinter einen Zero-Trust-Proxy, exponierte VPN-Konzentratoren durch identitaetsbasierte Zugaenge ersetzen, Dienste, die nicht aus dem Internet erreichbar sein muessen, nicht aus dem Internet erreichbar machen.

Die User Story: 12 Tage nach dem GTIG-Bericht

Petersen entschied sich nach drei Tagen Lesen und Nachdenken fuer einen 90-Tage-Plan. Wir haben die Schritte mit ihm durchgesprochen. Sie sind nicht spektakulaer, aber sie sind aufwendig. Hier der Verlauf der ersten zwoelf Tage:

Tag 1 (12. Mai): Inventar aller Web-Adminoberflaechen mit Zugriff aus dem Internet oder dem VPN. 19 Komponenten gefunden, davon 8 direkt internet-exponiert. Liste an die Geschaeftsleitung und das SOC verschickt.

Tag 2: Notfall-Patching der drei aeltesten Komponenten. Ein Portainer (Version 14 Monate alt), eine Bookstack-Instanz (8 Monate alt), eine Mailcow (5 Monate alt). Drei abendliche Wartungsfenster spontan eingelegt.

Tag 3: Anfrage an den Identity-Provider, ob FIDO2-Passkeys als zweiter Faktor fuer Microsoft 365 und das SonicWall-VPN umgesetzt werden koennen. Antwort: ja, Setup-Aufwand vier Wochen, Rollout-Aufwand sechs Wochen.

Tag 4: Pruefung der Webhook- und API-Endpunkte des Customer-Portals. Identifikation einer Schnittstelle fuer ERP-Sync, die mit einem statischen API-Token authentifiziert und keine 2FA kennt. Risiko-Ticket im Backlog priorisiert.

Tag 5: Telefonat mit dem MSP-Partner aus Hannover. Vereinbarung, dass das SOC ab sofort auf folgende drei Anomalien zusaetzlich alarmiert: erfolgreiche Logins ohne vorausgehenden 2FA-Schritt, Webhook-Aufrufe ausserhalb der bekannten Quell-IP-Bereiche, Service-Account-Tokens mit ungewoehnlicher Tag-Zeit-Verteilung.

Tag 6 (Samstag): Geplante Migration des Portainer-Adminpanels hinter einen Cloudflare-Access-Proxy mit IdP-gestuetztem Login. Vier Stunden Arbeit, zwei Stunden Test, eine Stunde Doku.

Tag 8 (Montag): Geschaeftsleitungs-Sitzung. Petersen stellt das 90-Tage-Programm vor. Budgetbedarf: 180.000 Euro fuer Hardware-Schluessel, MSP-Mehrkosten, externe Architekturberatung. Geschaeftsleitung genehmigt unter der Bedingung, dass die NIS2-Compliance-Liste weiterlaeuft.

Tag 10: Erstes Pilot-FIDO2-Rollout in der Entwicklungsabteilung. 12 Mitarbeitende mit YubiKey 5C NFC ausgestattet. Erfahrungssammlung beginnt.

Tag 12: Petersen erhaelt vom MSP-SOC einen Alert: ein Service-Account des Confluence-Servers hat um 03:14 Uhr Tokens mit ungewoehnlicher Quell-IP angefragt. Erste Verdachtspruefung negativ, aber das Logging hat sich gelohnt. Die Anomalie haette vor dem Tuning des SOC niemand gesehen.

Die fuenf Schichten, die der Mittelstand jetzt umbauen muss

Was Petersen in seinem 90-Tage-Plan adressiert, ist nicht zufaellig. Es entspricht den fuenf Schichten, die wir bei pleXtec in Kundenprojekten als die kritischsten fuer die naechsten 18 Monate identifiziert haben. Sie ueberlappen sich, aber jede hat einen eigenen Reifegrad.

Schicht 1: Identity

FIDO2/WebAuthn-Passkeys sind die einzige weit verbreitete Authentifizierungsmethode, die gegen die heutigen Angriffsklassen (AiTM-Phishing, Credential-Stuffing, OTP-Phishing) gleichzeitig robust ist. Anders als TOTP-Codes funktionieren sie domain-gebunden, das heisst, ein Angreifer auf einer Phishing-Seite kann den zweiten Faktor nicht abgreifen. Anders als SMS-Codes liegen sie nicht in Mobilfunknetzen oder bei E-Mail-Providern. Und sie schliessen einen ganzen Strang von Bypass-Klassen aus, weil sie kryptografisch an die Origin des Logins gebunden sind.

Die Migration ist nicht trivial. Sie verlangt einen IdP, der Passkeys unterstuetzt (Microsoft Entra, Okta, Keycloak ab Version 25), eine Hardware-Schluessel-Beschaffung (rechnen Sie mit 50–80 Euro pro Mitarbeitenden) und einen Schulungsaufwand fuer den ersten Rollout. Aber sie ist die einzige Schicht, die der GTIG-Vorfall direkt adressiert.

Schicht 2: Angriffsoberflaeche

Jede Web-Adminoberflaeche im Internet ist ein potenzieller GTIG-Vorfall. Pruefen Sie Ihren Perimeter mit dem ehrlichen Massstab: Gibt es einen geschaeftlichen Grund, dass die Oberflaeche aus dem Internet erreichbar ist? In neun von zehn Faellen lautet die Antwort nein. Setzen Sie einen Zero-Trust-Proxy davor (Cloudflare Access, Tailscale, Twingate, Pomerium, Identity-Aware-Proxy von Google) und beschraenken Sie den Zugriff auf authentifizierte Benutzer mit FIDO2.

Dasselbe gilt fuer VPN-Konzentratoren. Wir haben in unserer Analyse zur Akira-SonicWall-Welle vom 8. Mai 2026 ausgefuehrt, warum klassische SSL-VPNs heute ihre Halbwertszeit erreicht haben. Identitaetsbasierte Zugaenge sind die zeitgemaesse Antwort.

Schicht 3: Patch-Geschwindigkeit

Mit der Annahme, dass kritische Patches innerhalb von 24 Stunden eingespielt werden muessen, brauchen Sie ein Patch-Management, das diese Geschwindigkeit kann, ohne den Betrieb zu stoeren. Das bedeutet: Vorbereitete Wartungsfenster fuer Notfaelle (auch nachts, auch am Wochenende), ein klares Rollback-Verfahren, eine Vorab-Testumgebung fuer die kritischsten Systeme, ein dokumentierter Eskalationsweg von der CVE-Veroeffentlichung bis zur Wartungsfenster-Entscheidung. Das ist Organisationsarbeit, nicht Werkzeuganschaffung.

Schicht 4: Erkennung

Wenn Sie den Bypass nicht verhindern koennen, muss er auffallen. Praktisch heisst das: Authentifizierungsereignisse zentral und vollstaendig loggen, Webhook-Aufrufe gegen Geo-Anomalien pruefen, Service-Account-Tokens mit Verhaltensbasis-Profilen versehen, ungewoehnliche Aufrufpfade in Web-Adminoberflaechen alarmieren. Ihr SOC – ob intern oder als MSP – muss diese Faelle erkennen koennen. Wenn nicht, sind die Regeln zu schreiben, bevor der naechste GTIG-Vorfall ein Vorfall im eigenen Haus wird. Wir unterstuetzen unsere Kunden bei dieser Architekturarbeit ueber unseren Bereich Projektmanagement.

Schicht 5: Eigenes KI-Risiko

Petersen hat einen weiteren Punkt auf seine Liste gesetzt, den viele Mittelstaendler noch unterschaetzen: Was passiert mit seiner Codebasis, wenn Mitarbeitende, Lieferanten oder externe Beratungen Sprachmodelle nutzen, um ihren Code zu schreiben? Wenn Code aus einem LLM bei ihm landet, dann landet auch das KI-spezifische Halluzinationsrisiko in seinem Code. Das ist eine eigene Diskussion, die wir in unserem Artikel zur agentic coding im Mittelstand vertieft haben.

Spiegelbildlich gilt: Wenn Mitarbeitende eigenen Quellcode in oeffentliche LLMs hochladen, dann erleichtern sie es Angreifern, ihn auf Schwachstellen zu pruefen. Schatten-KI ist nicht nur ein Datenschutzproblem, sondern auch ein Sicherheitsproblem.

Breitere Einordnung: Was sich strategisch aendert

Die letzten zehn Jahre Sicherheits-Engineering waren von einer Annahme gepraegt: Bugs entstehen, weil Menschen Fehler machen, und Bugs werden gefunden, weil Menschen sie suchen. Diese Annahme hat Bug-Bounty-Programme, Vulnerability-Disclosure-Policies und das gesamte Forensik-Geschaeft gepraegt. Sie hat auch implizit den Verteidigern einen Vorteil gegeben: Menschen sind teuer, Forscherzeit ist begrenzt, also gibt es einen natuerlichen Filter, der die Geschwindigkeit der Bug-Findung beschraenkt.

Dieser Filter faellt 2026. Maschinen sind nicht muede, brauchen keine Bezahlung, koennen parallel hundert Codebasen lesen. Wenn die aktuelle Modellgeneration in der Lage ist, semantische Logikfehler in Open-Source-Adminpanels zu finden, dann gilt das fuer alle Codebasen, die ein Sprachmodell verarbeiten kann. Das schliesst proprietaere Software ein, sobald ein Angreifer Zugang zur Codebasis hat (durch Insider, Lieferanten-Leaks, Source-Code-Repository-Exfiltration).

Praktisch heisst das: Die Aera, in der mittelstaendische Spezialsoftware "durch ihre Nische geschuetzt" war, geht zu Ende. Auch SAP-Erweiterungen, CAD-Plugins, Branchen-CRMs, Buchhaltungssoftware mit 800 Kunden weltweit sind interessante Ziele, sobald die Kosten der Schwachstellensuche fallen.

Was Sie diese Woche tun sollten

Wenn Sie diesen Artikel bis hierher gelesen haben, lohnt sich ein 30-Minuten-Termin mit Ihrem IT-Verantwortlichen. Stellen Sie ihm vier Fragen:

Erstens: Welche Web-Adminoberflaechen unserer Software sind aus dem Internet erreichbar – inklusive aller selbst gehosteten Open-Source-Werkzeuge? Wir haben in unseren Projekten regelmaessig die Erfahrung gemacht, dass die Antwort auf diese Frage nicht aus dem Stehgreif kommt. Das ist bereits das erste Risiko.

Zweitens: Wenn morgen frueh ein CVSS-9.8-Patch fuer eine dieser Komponenten veroeffentlicht wird, wie schnell ist er installiert? Die Antwort sollte 24 Stunden sein. Ist sie es nicht, ist das die naechste Architekturaufgabe.

Drittens: Welche Authentifizierungsmethoden setzen wir heute fuer die kritischsten Anwendungen ein, und wann ist FIDO2 als Standard?

Viertens: Wenn das SOC am Sonntag um 03:14 Uhr eine Anomalie sieht, wer hat den Eskalationsweg? Steht der Telefonbaum aktuell?

Wenn drei dieser Fragen nicht zufriedenstellend beantwortet werden, ist die Antwort kein Tool-Kauf, sondern eine Architekturberatung. Wir bei pleXtec begleiten seit Jahren mittelstaendische Unternehmen bei genau dieser Sorte von Reife-Aufbau. Eine erste Standortbestimmung kostet nichts und dauert weniger als zwei Stunden – mehr dazu finden Sie unter unserer Leistungsuebersicht oder direkt ueber das Kontaktformular.

Ausblick: Was die naechsten zwoelf Monate bringen

Drei Entwicklungen halten wir fuer wahrscheinlich. Erstens: Mehrere weitere KI-gebaute Zero-Days werden bis Jahresende 2026 dokumentiert. Das ist nicht spekulativ. John Hultquist von GTIG selbst sagt, dass fuer jeden nachweisbaren Fall vermutlich viele unbeobachtete existieren. Die Zahl wird sichtbar steigen, weil die Erkennungsmethoden besser werden.

Zweitens: Die grossen Frontier-Modelle werden zusaetzliche Schutzmechanismen einbauen, die Code-Analyse-Anfragen in Richtung Schwachstellensuche erschweren. Das wird das Problem dampfen, nicht loesen, weil Open-Source-Modelle parallel dazu staerker werden und die Hemmschwelle fuer die Selbst-Hosting-Variante sinkt.

Drittens: Bug-Bounty-Programme werden defensiver. Unternehmen werden eigene Modelle gegen ihre eigenen Codebasen laufen lassen, um Bugs zu finden, bevor Angreifer es tun. Das ist eine Sicherheits-Disziplin, die heute fast niemand im Mittelstand betreibt. Sie wird in 24 Monaten Standard sein.

Markus Petersens 90-Tage-Plan endet am 10. August 2026. Bis dahin will er FIDO2 fuer alle Endanwender ausgerollt haben, jede Web-Adminoberflaeche hinter einem Zero-Trust-Proxy, das Patch-SLA auf 24 Stunden gehoben und das SOC-Tuning durch eine Tabletop-Uebung validiert. Er wird nicht alles schaffen, das weiss er. Aber er hat angefangen.

Das ist mehr, als die meisten am Tag vor dem 11. Mai 2026 von sich behaupten konnten. Es ist auch die ehrlichste Antwort auf die Frage, wie der deutsche Mittelstand mit der neuen Bedrohungslandschaft umgehen sollte: Nicht mit Panik, nicht mit einem schnellen Tool-Kauf, sondern mit der konsequenten Umsetzung der Architektur-Hausaufgaben, die schon vor dem GTIG-Bericht offen standen – und die durch ihn nur dringender geworden sind.