CISA hat drei Schwachstellen wegen nachgewiesener aktiver Ausnutzung in den Known Exploited Vulnerabilities Catalog aufgenommen. Betroffen sind IBM Langflow, N-able N-central und Apache Tomcat. Für DACH-Unternehmen ist die KEV-Aufnahme ein starkes Priorisierungssignal: Nicht nur theoretische Schwere, sondern beobachtete Ausnutzung spricht für schnelles Handeln. Die erste Aufgabe ist dennoch nicht blindes Patchen, sondern ein belastbares Inventar mit Exponierung und Geschäftsbezug.
Die drei Lücken betreffen unterschiedliche Angriffsflächen. Eine Code-Injection in einer KI-Workflow-Plattform, eine Authentifizierungsumgehung in einem zentralen Managementsystem und fehlende Verschlüsselung sensibler Daten in einem Anwendungsserver haben verschiedene Auswirkungen und Prüfpfade. Ein gemeinsames Ticket mit derselben Standardmaßnahme reicht deshalb nicht. Unternehmen brauchen pro Produkt einen Owner, eine konkrete Eindämmung, die passende Herstellerbehebung und eine rückwirkende Suche nach möglicher Ausnutzung.
Was CISA bestätigt
CISA nennt CVE-2026-9198 als Code-Injection-Schwachstelle in IBM Langflow. CVE-2026-18556 betrifft eine Umgehung der Authentifizierung in N-able N-central über einen alternativen Pfad oder Kanal. CVE-2026-34486 beschreibt fehlende Verschlüsselung sensibler Daten in Apache Tomcat. Alle drei wurden aufgrund von Evidenz aktiver Ausnutzung in den KEV-Katalog aufgenommen. Der CISA-Hinweis enthält keine universelle Aussage dazu, welche konkrete Installation betroffen ist.
CISA verweist auf US-Vorgaben für Bundesbehörden und empfiehlt darüber hinaus allen Organisationen, KEV-Lücken im risikobasierten Schwachstellenmanagement zu priorisieren. Für DACH-Unternehmen entsteht daraus keine automatische Bindung an die amerikanische Behördenrichtlinie. Nachvollziehbar ist aber die operative Ableitung, KEV-Signale höher zu gewichten als rein theoretische Scores und bei öffentlich erreichbaren oder hoch privilegierten Systemen besonders schnell zu handeln.
CISA encourages all organizations to adopt risk-based vulnerability management.
CISA
Drei Produkte, drei Triage-Schwerpunkte
Bei Langflow steht die mögliche Codeausführung im Kontext einer Plattform im Vordergrund, die häufig Modelle, Datenquellen und Zugangsdaten verbindet. Teams sollten Instanzen, Versionen, Erreichbarkeit, angebundene Secrets und zuletzt ausgeführte Flows erfassen. Bei N-central ist die zentrale Verwaltungsreichweite entscheidend: Ein kompromittiertes Managementsystem kann viele Kunden- oder Endsysteme berühren. Neben dem Produkt selbst sind deshalb Vertrauensbeziehungen, Administratorkonten und nachgelagerte Aktionen zu prüfen.
Bei Tomcat muss geklärt werden, welche Anwendungen und sensiblen Daten über betroffene Komponenten laufen. Fehlende Verschlüsselung kann andere Spuren und Folgen haben als direkte Codeausführung. Entscheidend sind Version, Konfiguration, Datenfluss und Exponierung der konkreten Instanz. Für alle drei Fälle gilt: Der CVE-Titel allein ist keine technische Diagnose. Maßgeblich sind Herstellerhinweise und die tatsächlich eingesetzte Version; diese Informationen müssen dokumentiert beschafft und geprüft werden.
- Langflow: verbundene Modelle, Datenquellen, Secrets und Flow-Ausführungen in die Aufarbeitung einbeziehen.
- N-central: zentrale Rechte, Mandantenreichweite, Admin-Zugänge und Remote-Aktionen priorisieren.
- Tomcat: betroffene Anwendungen, sensible Datenflüsse, Versionen und Verschlüsselungspfade erfassen.
- Internetexponierte Systeme: vor internen, abgeschirmten Testinstanzen behandeln.
- Unklare Assets: nicht als nicht betroffen schließen, sondern mit Owner und Prüffrist nachverfolgen.
Sechsstufiger Reaktionsplan
- Assets über CMDB, Scanner, Cloud-Konten und technische Owner identifizieren und Ergebnisse abgleichen.
- Betroffenheit anhand der offiziellen Herstellerinformationen und realer Versionen bestätigen.
- Exponierung reduzieren, unnötige Zugänge sperren und kritische Systeme bei Bedarf isolieren.
- Freigegebene Updates oder Herstellermaßnahmen kontrolliert einspielen und technisch verifizieren.
- Logs, Konten, Konfigurationen und Folgeaktionen rückwirkend auf Hinweise einer Ausnutzung prüfen.
- Credentials und Vertrauensbeziehungen risikobasiert rotieren sowie Befund und Restlücken dokumentieren.
Update und Kompromittierungsprüfung müssen parallel geplant werden. Ein gepatchtes System kann bereits zuvor missbraucht worden sein. Besonders bei N-central und Langflow ist zu prüfen, ob privilegierte Zugangsdaten, Tokens oder angebundene Systeme betroffen sein könnten. Logquellen sollten vor Änderungen gesichert werden. Fehlen ausreichende Logs, ist das eine Unsicherheit im Risikoentscheid und kein Beleg für einen sauberen Zustand. Dann können stärkere Eindämmung und Credential-Rotation gerechtfertigt sein.
Geschäftsbetrieb und Verantwortlichkeit
Nicht jedes System lässt sich sofort ohne Auswirkung aktualisieren. Der Ausnahmeprozess muss dann konkrete Ersatzkontrollen enthalten: reduzierte Erreichbarkeit, zusätzliche Zugangshürden, engere Netzwerkregeln, verstärkte Überwachung und einen verbindlichen Termin. Eine akzeptierte Ausnahme ohne Owner und Ablaufdatum ist keine Kontrolle. Geschäftsführung und Prozessverantwortliche brauchen eine kurze Darstellung von möglicher Wirkung, betroffenen Diensten, aktueller Eindämmung und verbleibendem Risiko.
Bei MSPs und gemeinsam betriebenen Plattformen kommt Kommunikation hinzu. Es muss klar sein, wer die Produktinstanz aktualisiert, wer Kundensysteme prüft und wer Indikatoren bewertet. Verträge und Notfallkontakte sollten nicht erst im Incident gesucht werden. Für Langflow können zusätzlich KI- und Datenverantwortliche nötig sein; für Tomcat die jeweiligen Application Owner. Zentrale Koordination verhindert, dass jedes Team nur seine lokale Komponente betrachtet.
Abschlusskriterien statt Ticketstatus
Ein Fall ist nicht abgeschlossen, nur weil ein Update-Ticket auf erledigt steht. Nachweisbar sein sollten vollständiges Inventar, geprüfte Versionen, angewendete Maßnahme, kontrollierter Neustart oder Funktionstest, gesicherte Logs, Ergebnis der Kompromittierungsprüfung und Behandlung möglicher Credentials. Nicht erreichbare Systeme und Ausnahmen bleiben separat sichtbar. Erst wenn Restunsicherheiten einem verantwortlichen Entscheider vorliegen, kann das Risiko bewusst akzeptiert oder weiter reduziert werden.
Fazit
Die CISA-Meldung verbindet drei unterschiedliche Schwachstellen durch ein gemeinsames Signal: aktive Ausnutzung. Unternehmen sollten Langflow, N-central und Tomcat deshalb priorisiert inventarisieren, Betroffenheit über Herstellerinformationen bestätigen, Exponierung reduzieren und Updates verifizieren. Entscheidend ist die rückwirkende Aufarbeitung, weil Patchen eine frühere Kompromittierung nicht beseitigt. Eine produktbezogene Triage mit klaren Abschlussnachweisen ist belastbarer als eine pauschale KEV-Checkliste.