Montag, 8:47 Uhr: Ein ganz normaler Morgen bei der Falkenberg GmbH
Thomas Wiesel, IT-Leiter der Falkenberg GmbH – einem mittelständischen Maschinenbauer mit 340 Mitarbeitenden im Raum Stuttgart – beginnt seinen Montag wie gewohnt. Kaffee, E-Mails durchsehen, kurzer Blick auf das Monitoring-Dashboard. Alles grün. Die Woche kann beginnen.
Was Wiesel zu diesem Zeitpunkt nicht weiß: Am Freitagabend, 22:14 Uhr mitteleuropäischer Zeit, wurde ein Security Advisory für eine Open-Source-Komponente veröffentlicht, die sein Entwicklungsteam seit zwei Jahren produktiv einsetzt. CVSS-Score: 9.3. Unauthentifizierte Remote Code Execution über einen einzigen HTTP-POST-Request. Noch bevor der Samstag anbrach, hatten die ersten Angreifer funktionsfähige Exploits entwickelt und begonnen, das Internet systematisch nach verwundbaren Instanzen abzusuchen.
Am Montagmorgen um 8:47 Uhr hat das Exploitation Window bereits 58 Stunden offen gestanden. Die Falkenberg GmbH gehört zu den Treffern.
Das schrumpfende Zeitfenster: Eine Bestandsaufnahme
Der Fall der fiktiven Falkenberg GmbH ist konstruiert – das zugrunde liegende Szenario leider nicht. Am 17. März 2026 wurde die Schwachstelle CVE-2026-33017 in der Open-Source-KI-Plattform Langflow öffentlich bekannt gegeben. Der CVSS-Score: 9.3. Innerhalb von nur 20 Stunden nach Veröffentlichung des Advisories beobachteten Sicherheitsforscher die ersten aktiven Angriffsversuche in freier Wildbahn. Keine Wochen, keine Tage – Stunden.
Dieser Fall ist kein Ausreißer. Er ist symptomatisch für eine fundamentale Verschiebung in der Cybersicherheitslandschaft. Die Zeitspanne zwischen der öffentlichen Bekanntgabe einer Schwachstelle und ihrer ersten Ausnutzung – das sogenannte Exploitation Window – hat sich in den vergangenen Jahren dramatisch verkürzt. Was früher Wochen oder Monate dauerte, geschieht heute in Stunden.
Die Gründe dafür sind vielschichtig. Angreifer nutzen zunehmend automatisierte Scanning-Tools, die innerhalb von Minuten nach Veröffentlichung eines CVE das Internet nach verwundbaren Systemen durchsuchen. KI-gestützte Werkzeuge beschleunigen die Exploit-Entwicklung. Und die wachsende Vernetzung von Security-Communitys – auf beiden Seiten der Legalitätsgrenze – sorgt dafür, dass Proof-of-Concept-Code oft schneller zirkuliert als offizielle Patches eingespielt werden können.
Anatomie einer 20-Stunden-Attacke: Der Fall Langflow
Um zu verstehen, warum das klassische Patch-Management gegen diese Geschwindigkeit nicht ankommt, lohnt ein genauerer Blick auf den Langflow-Vorfall.
Langflow ist eine Open-Source-Plattform für die visuelle Erstellung von KI-Workflows und wird von Entwicklungsteams weltweit eingesetzt, um Large Language Models in Unternehmensprozesse zu integrieren. Die Schwachstelle CVE-2026-33017 kombinierte zwei Probleme: fehlende Authentifizierung an einem öffentlich erreichbaren API-Endpunkt und Code Injection über einen Parameter, der eigentlich interne Flow-Definitionen laden sollte. Ein Angreifer konnte über einen einzigen HTTP-POST-Request beliebigen Python-Code auf dem Server ausführen – ohne Anmeldung, ohne Benutzerinteraktion, ohne Sandbox.
Die technische Exploitation war erschreckend trivial: Der verwundbare Endpunkt /api/v1/build_public_tmp/{flow_id}/flow akzeptierte POST-Requests ohne Authentifizierung. Wurde ein optionaler Datenparameter mitgesendet, verarbeitete das System die vom Angreifer gelieferten Flow-Definitionen – inklusive eingebettetem Python-Code – anstelle der in der Datenbank gespeicherten Daten. Die Ausführung erfolgte über exec() ohne jegliche Sandboxing-Schutzmaßnahmen.
Innerhalb der ersten 20 Stunden nach Disclosure beobachteten Sicherheitsforscher bereits ausgefeilte Post-Exploitation-Aktivitäten: Angreifer extrahierten Umgebungsvariablen und Zugangsdaten, luden Malware von externen Command-and-Control-Servern nach und richteten persistente Zugänge ein. Das war kein opportunistisches Skript-Kiddie-Verhalten – hier operierten professionelle Angreifergruppen, die offenbar nur auf die Veröffentlichung gewartet hatten.
Zurück zur Falkenberg GmbH: Was schiefging
Thomas Wiesel und sein Team hatten vieles richtig gemacht. Es gab ein Informationssicherheitskonzept, regelmäßige Patch-Zyklen, ein dokumentiertes Vorgehen für kritische Schwachstellen. Aber der Prozess sah so aus: Security Advisories werden montags im wöchentlichen IT-Team-Meeting besprochen. Kritische Patches werden innerhalb von fünf Werktagen eingespielt. Für Notfälle gibt es eine Eskalationsregel – aber die wurde zuletzt vor zwei Jahren angepasst und definierte „Notfall" als eine aktiv ausgenutzte Schwachstelle in Microsoft- oder SAP-Produkten.
Langflow? Stand nicht auf der Liste der überwachten Software. Es war vom Entwicklungsteam als internes Tool eingeführt worden – „nur für Prototyping", wie es in der ursprünglichen Freigabe hieß. Dass die Instanz über einen Reverse Proxy auch aus dem Homeoffice erreichbar war und mittlerweile produktive KI-Workflows für die Qualitätssicherung verarbeitete, war im Asset-Register nicht vermerkt.
Als Wiesels Team am Montag die Schwachstellenmeldung entdeckte, war der Angriff längst erfolgt. Die Angreifer hatten über das Wochenende Datenbankzugangsdaten aus den Umgebungsvariablen extrahiert, sich lateral in das interne Netz bewegt und begonnen, Daten zu exfiltrieren. Die Falkenberg GmbH stand vor einem ausgewachsenen Sicherheitsvorfall – ausgelöst durch eine Schwachstelle in einem Tool, von dem die IT-Leitung nicht einmal wusste, dass es im produktiven Einsatz war.
Das strukturelle Problem: Warum klassisches Patch-Management versagt
Der Fall der Falkenberg GmbH illustriert ein Problem, das weit über ein einzelnes Unternehmen hinausgeht. Das klassische Patch-Management basiert auf Annahmen, die in der aktuellen Bedrohungslandschaft nicht mehr tragen:
Annahme 1: „Wir haben genug Zeit zum Patchen." Die traditionelle Faustregel lautete: Kritische Patches innerhalb von 30 Tagen, hochkritische innerhalb von 14 Tagen einspielen. Bei einem Exploitation Window von 20 Stunden sind 14 Tage eine Ewigkeit. Selbst die oft zitierten 24 bis 48 Stunden für Notfall-Patches reichen nicht mehr, wenn Angreifer schon nach wenigen Stunden aktiv werden.
Annahme 2: „Wir kennen unsere Angriffsfläche." In den meisten mittelständischen Unternehmen existiert eine erhebliche Lücke zwischen dem dokumentierten Software-Inventar und der tatsächlich eingesetzten Software. Schatten-IT, von Fachabteilungen oder Entwicklungsteams eigenständig eingeführte Tools, Cloud-Dienste mit selbstverwalteten Instanzen – all das erweitert die Angriffsfläche, ohne im offiziellen Asset-Management aufzutauchen. Laut aktuellen Studien kennen Unternehmen im Durchschnitt nur etwa 70 Prozent ihrer tatsächlich exponierten Systeme.
Annahme 3: „Open Source ist nicht unser Risiko." Die zunehmende Integration von Open-Source-Komponenten in Unternehmens-Workflows – verstärkt durch den KI-Boom – hat die Angriffsfläche vieler Organisationen massiv erweitert. Tools wie Langflow, n8n, Streamlit oder Gradio werden in rasanter Geschwindigkeit adoptiert, oft ohne die gleichen Sicherheitsprüfungen, die bei kommerzieller Software Standard sind. Dabei laufen sie häufig mit erweiterten Rechten und haben Zugang zu sensiblen Daten und Zugangsinformationen.
Annahme 4: „Unser Netzwerk schützt uns." Perimeter-basierte Sicherheit greift zu kurz, wenn verwundbare Dienste – absichtlich oder unabsichtlich – über Reverse Proxies, VPN-Split-Tunneling oder Cloud-Deployments von außen erreichbar sind. Die Grenze zwischen „intern" und „extern" verschwimmt in modernen Arbeitsumgebungen zunehmend.
Jenseits des Einzelfalls: Ein systemisches Muster
Der Langflow-Vorfall steht nicht allein. Allein im März 2026 zeigt sich das Muster der schnellen Exploitation in mehreren prominenten Fällen:
Die Schwachstelle CVE-2026-3564 in ConnectWise ScreenConnect ermöglichte es Angreifern, über manipulierte ASP.NET Machine Keys Remote-Sessions zu kapern – ohne Authentifizierung. Betroffen waren alle Versionen vor 26.1, also praktisch jede bestehende Installation. ScreenConnect wird von Tausenden IT-Dienstleistern für die Fernwartung eingesetzt – ein Angriffsvektor, der nicht nur das direkte Opfer, sondern dessen gesamten Kundenstamm gefährdet.
CVE-2026-21992 in Oracle Identity Manager, veröffentlicht am 21. März 2026 als Out-of-Band Patch, erreicht mit CVSS 9.8 die Höchstwertung. Unauthentifizierte Remote Code Execution über HTTP in einer Middleware-Komponente, die in zahlreichen Unternehmensumgebungen läuft. Oracle sah sich gezwungen, den regulären vierteljährlichen Patch-Zyklus zu durchbrechen – ein klares Signal für die Schwere der Bedrohung.
Diese Fälle eint ein Muster: Kritische Schwachstellen in weit verbreiteter Software, triviale Exploitation, unauthentifizierter Zugang. Und jedes Mal beginnt das Rennen zwischen Angreifern und Verteidigern von neuem – mit zunehmend schlechteren Chancen für die Verteidiger.
Was modernes Schwachstellenmanagement leisten muss
Die Erkenntnis, dass das klassische Patch-Management in seiner bisherigen Form nicht mehr ausreicht, führt zu der Frage: Was muss stattdessen kommen? Aus der Praxis von pleXtec und der aktuellen Sicherheitsforschung kristallisieren sich mehrere Handlungsfelder heraus:
1. Continuous Asset Discovery statt statischem Inventar
Ein Schwachstellenmanagement kann nur so gut sein wie die Kenntnis der eigenen Angriffsfläche. Unternehmen benötigen Werkzeuge und Prozesse, die kontinuierlich – nicht einmal im Quartal – die tatsächlich exponierten Systeme, Dienste und Softwarekomponenten identifizieren. Das umfasst nicht nur klassische Server und Clients, sondern explizit auch containerisierte Anwendungen, Cloud-Instanzen, SaaS-Integrationen und von Entwicklungsteams betriebene interne Tools. Software Composition Analysis (SCA) sollte integraler Bestandteil der Build-Pipeline sein, um die verwendeten Open-Source-Komponenten und ihre Versionen automatisch zu erfassen.
2. Automatisierte Threat Intelligence Integration
Das manuelle Sichten von Security Advisories im Wochenrhythmus ist bei der aktuellen Exploitation-Geschwindigkeit nicht mehr vertretbar. Unternehmen benötigen automatisierte Feeds, die neue CVEs in Echtzeit mit dem eigenen Software-Inventar abgleichen und bei Treffern sofort alarmieren. Die Integration von Threat-Intelligence-Plattformen mit dem Vulnerability Management und dem SIEM bildet die Grundlage für zeitnahe Reaktionen. Dabei geht es nicht darum, jeden CVE mit CVSS über 7.0 als Notfall zu behandeln – sondern darum, kontextbezogen zu priorisieren: Ist die verwundbare Software in unserer Umgebung vorhanden? Ist sie exponiert? Gibt es bereits aktive Exploitation?
3. Risikobasierte Priorisierung statt CVSS-Fixierung
Der CVSS-Score allein ist ein unzureichendes Kriterium für die Patch-Priorisierung. Eine Schwachstelle mit CVSS 9.8 in einem System, das air-gapped in einem Testlabor läuft, hat eine andere Dringlichkeit als eine CVSS-7.5-Lücke in einem internetexponierten Dienst mit Zugang zu Produktionsdaten. Moderne Vulnerability-Management-Frameworks berücksichtigen deshalb den Exploitability Score, die tatsächliche Exposition des Systems, den Wert der erreichbaren Assets und die Verfügbarkeit von Exploits in freier Wildbahn. Der Exploit Prediction Scoring System (EPSS) Score liefert dabei wertvolle Zusatzinformationen darüber, wie wahrscheinlich eine aktive Ausnutzung ist.
4. Notfall-Patch-Prozesse mit klaren Zeitschwellen
Jedes Unternehmen benötigt einen dokumentierten und regelmäßig getesteten Prozess für Notfall-Patches, der klare Zeitschwellen definiert. Ein mögliches Modell:
Stufe 1 (Sofort, <4 Stunden): Aktiv ausgenutzte Schwachstelle in exponiertem System → Sofortige Isolation oder Patching, Wochenendbereitschaft
Stufe 2 (Dringend, <24 Stunden): Kritische Schwachstelle mit öffentlichem Exploit-Code → Patch innerhalb eines Arbeitstages
Stufe 3 (Hoch, <72 Stunden): Kritische Schwachstelle ohne bekannten Exploit → Patch innerhalb von drei Tagen
Stufe 4 (Standard, <14 Tage): Hochkritische Schwachstelle ohne Exposition → Regulärer Patch-Zyklus
Entscheidend ist, dass dieser Prozess nicht nur auf dem Papier existiert, sondern regelmäßig in Übungen getestet wird – einschließlich der Erreichbarkeit der verantwortlichen Personen am Wochenende.
5. Kompensatorische Kontrollen für die Übergangszeit
Nicht jeder Patch lässt sich sofort einspielen – Abhängigkeiten, Kompatibilitätstests und Change-Management-Prozesse können das verzögern. Für diese Übergangszeit braucht es vordefinierte kompensatorische Maßnahmen: Netzwerksegmentierung, temporäre Firewall-Regeln, Web Application Firewalls (WAF) mit virtuellen Patches, deaktivierte Dienste oder eingeschränkte Zugriffsrechte. Diese Maßnahmen sollten als Playbooks vorbereitet sein, damit sie im Ernstfall sofort aktiviert werden können, ohne erst konzipiert werden zu müssen.
6. Governance für Schatten-IT und Entwickler-Tools
Die wachsende Adoption von Open-Source-Werkzeugen, KI-Plattformen und Low-Code-Tools durch Fachabteilungen und Entwicklungsteams erfordert klare Governance-Regeln. Das bedeutet nicht, Innovation zu bremsen – aber jedes produktiv eingesetzte Tool muss im Asset-Register erfasst, in das Schwachstellenmanagement integriert und regelmäßig auf Sicherheitsupdates geprüft werden. Eine Compliance-Lösung, die auch die Software-Supply-Chain abdeckt, kann hier den Überblick sicherstellen.
Die Rolle der NIS2-Verordnung
Der regulatorische Rahmen verstärkt den Handlungsdruck. Die seit März 2026 vollständig durchsetzbare NIS2-Richtlinie fordert von betroffenen Unternehmen explizit ein strukturiertes Schwachstellenmanagement als Teil ihrer Risikomanagementmaßnahmen. Das BSI hat nach Ablauf der Registrierungsfrist am 6. März 2026 angekündigt, aktiv zu prüfen – und die Bußgelder können empfindlich ausfallen: bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes.
Für die Praxis bedeutet das: Ein dokumentierter, nachvollziehbarer Prozess für den Umgang mit Schwachstellen ist nicht mehr nur Best Practice, sondern regulatorische Pflicht. Unternehmen, die bei einem BSI-Audit nachweisen müssen, dass sie eine kritische Schwachstelle zwei Wochen lang ungepatcht gelassen haben, werden Schwierigkeiten haben, ihre Compliance darzulegen – besonders wenn es in diesem Zeitraum bereits aktive Exploitation gab.
Epilog: Dienstagmorgen bei der Falkenberg GmbH
Thomas Wiesel wird den Dienstag nach dem Vorfall nicht so schnell vergessen. Das Incident-Response-Team – extern hinzugezogen, weil die interne Kapazität nicht ausreichte – benötigte vier Tage für die vollständige Eindämmung und forensische Analyse. Die Kosten des Vorfalls: knapp 180.000 Euro für Forensik, Beratung und Wiederherstellung. Dazu kam der Reputationsschaden bei drei Großkunden, denen der Vorfall offengelegt werden musste, und ein Meldepflichtverstoß, weil die NIS2-konforme Erstmeldung an das BSI die 24-Stunden-Frist um acht Stunden verfehlte.
Was Wiesel anschließend veränderte: Die Falkenberg GmbH führte ein kontinuierliches Asset Discovery ein, das auch Entwicklertools und interne Dienste erfasst. Der Patch-Management-Prozess wurde um eine Wochenendbereitschaft erweitert und die Eskalationsstufen an die aktuelle Bedrohungslage angepasst. Kritische Advisories werden jetzt automatisiert mit dem Software-Inventar abgeglichen, und für die am häufigsten eingesetzten Open-Source-Komponenten gibt es vorkonfigurierte WAF-Regeln als kompensatorische Kontrollen.
„Wir hatten Glück im Unglück", sagt Wiesel heute. „Die Angreifer waren auf Datenexfiltration aus, nicht auf Verschlüsselung. Ein Ransomware-Angriff hätte uns Wochen lahmgelegt."
Handlungsempfehlungen: Die Checkliste für Ihr Unternehmen
Auf Basis der beschriebenen Erkenntnisse empfehlen wir folgende konkrete Schritte:
Sofort umsetzbar: Prüfen Sie, ob Langflow (alle Versionen ≤ 1.8.1), ConnectWise ScreenConnect (Versionen vor 26.1) oder Oracle Identity Manager (12.2.1.4.0 / 14.1.2.1.0) in Ihrer Umgebung eingesetzt werden. Falls ja: Patchen Sie umgehend und prüfen Sie Ihre Systeme auf Kompromittierungsindikatoren.
Kurzfristig (1–4 Wochen): Erstellen Sie ein vollständiges Inventar aller eingesetzten Software – einschließlich Open-Source-Tools, Entwicklerwerkzeuge und intern gehostete Dienste. Überprüfen Sie Ihren Notfall-Patch-Prozess: Sind die Zeitschwellen noch realistisch? Gibt es eine Wochenendbereitschaft? Sind die Eskalationswege aktuell?
Mittelfristig (1–3 Monate): Implementieren Sie automatisierte CVE-Benachrichtigungen mit Abgleich gegen Ihr Software-Inventar. Evaluieren Sie die Einführung von risikobasierter Priorisierung (EPSS-Integration) in Ihrem Vulnerability-Management-Prozess. Erstellen Sie Playbooks mit kompensatorischen Kontrollen für die häufigsten Angriffsvektoren.
Strategisch (3–6 Monate): Etablieren Sie eine Governance-Struktur für die Einführung neuer Software, die Sicherheitsaspekte von Anfang an berücksichtigt. Integrieren Sie Software Composition Analysis (SCA) in Ihre Softwareentwicklungs-Pipelines. Führen Sie regelmäßige Übungen Ihres Notfall-Patch-Prozesses durch, analog zu Incident-Response-Übungen.
Ausblick: Die neue Normalität
Das 20-Stunden-Exploitation-Window ist kein Ausreißer – es ist die neue Normalität. Die Kombination aus automatisierter Exploit-Entwicklung, KI-gestütztem Scanning und der zunehmenden Vernetzung von Angreifergruppen wird die Exploitation-Geschwindigkeit weiter beschleunigen. Unternehmen, die ihr Schwachstellenmanagement nicht an diese Realität anpassen, werden zunehmend auf der Verliererseite des Wettlaufs stehen.
Die gute Nachricht: Die Werkzeuge und Methoden für ein modernes, risikobasiertes Schwachstellenmanagement existieren. Es fehlt in vielen Organisationen nicht an Technologie, sondern an der konsequenten Umsetzung – an aktualisierten Prozessen, klaren Verantwortlichkeiten und der Bereitschaft, Sicherheit als kontinuierlichen Prozess zu begreifen, nicht als jährliche Compliance-Übung.
Das pleXtec-Team unterstützt Sie bei der Entwicklung und Implementierung eines Schwachstellenmanagements, das mit der Geschwindigkeit moderner Bedrohungen Schritt hält – von der initialen Bestandsaufnahme über die KI-gestützte Automatisierung bis zur Integration in Ihre bestehenden Projektmanagement-Prozesse.