• ·

    Cyber Resilience Act: Was der CRA für Ihr Unternehmen bedeutet

    VonJ. Benjamin Espagné

    Der EU Cyber Resilience Act (CRA) ist seit Ende 2024 in Kraft und entfaltet ab dem 11. Juni 2026 erste Wirkung. Mit ihm schafft die EU erstmals einen einheitlichen Rechtsrahmen für die Cybersicherheit von Produkten mit digitalen Elementen — von der Firmware im Router bis zur Cloud-basierten Unternehmenssoftware. Für Hersteller, Importeure und Händler gelten weitreichende neue Pflichten. Aber auch für Unternehmen, die solche Produkte einsetzen, ändert sich mehr als auf den ersten Blick erkennbar.

    Worum geht es beim CRA?

    Der CRA verfolgt einen horizontalen Ansatz: Er reguliert nicht einzelne Branchen, sondern alle Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Das umfasst Hardware mit eingebetteter Software ebenso wie eigenständige Softwareprodukte. Betroffen sind unter anderem Firewalls, Router, Switches, industrielle Steuerungen, Smart-Home-Geräte, aber auch Business-Software, ERP-Systeme und Cloud-Dienste.

    Im Kern verlangt der CRA:

    • Security by Design: Cybersicherheit muss von der Konzeption bis zum Ende des Produktlebenszyklus mitgedacht werden
    • Schwachstellenmanagement: Hersteller müssen bekannt gewordene Schwachstellen aktiv managen und Sicherheitsupdates bereitstellen — kostenlos und über einen definierten Zeitraum
    • Meldepflichten: Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an die ENISA gemeldet werden
    • Konformitätsbewertung: Produkte müssen vor dem Inverkehrbringen nachweislich die CRA-Anforderungen erfüllen — je nach Risikoklasse durch Selbstbewertung oder durch eine unabhängige Prüfstelle
    • Dokumentationspflichten: Technische Dokumentation, Software Bill of Materials (SBOM) und Konformitätserklärung werden Pflicht

    Zeitplan: Was gilt ab wann?

    Der CRA tritt stufenweise in Kraft:

    • Ab 11. Juni 2026: Pflichten für Konformitätsbewertungsstellen greifen
    • Ab 11. September 2026: Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle
    • Ab 11. Dezember 2027: Alle CRA-Anforderungen gelten vollständig — Produkte ohne CRA-Konformität dürfen nicht mehr in Verkehr gebracht werden

    Parallel dazu muss Deutschland ein nationales Durchführungsgesetz verabschieden. Der aktuelle Referentenentwurf des BMI sieht vor, dem BSI die zentrale Rolle als Marktüberwachungsbehörde, CSIRT und Beschwerdestelle zuzuweisen. TeleTrusT, der Bundesverband IT-Sicherheit, kritisiert in seiner aktuellen Stellungnahme vom 1. April 2026 allerdings, dass die personelle und finanzielle Ausstattung des BSI dafür nicht gesichert sei und die vorgesehenen Unterstützungsmaßnahmen für Unternehmen mit nur 1,28 Mio. Euro jährlich massiv unterfinanziert seien.

    Wen betrifft der CRA direkt?

    Hersteller

    Wer Produkte mit digitalen Elementen herstellt und in der EU in Verkehr bringt, ist Hauptadressat des CRA. Das betrifft nicht nur klassische Hardware-Hersteller, sondern ausdrücklich auch Softwareunternehmen. Selbst Open-Source-Projekte können unter bestimmten Voraussetzungen erfasst sein, wenn sie kommerziell genutzt werden.

    Importeure und Händler

    Wer Produkte aus Drittstaaten in die EU importiert oder weitervertreibt, muss sicherstellen, dass die CRA-Anforderungen erfüllt sind. Im Klartext: Wer IT-Produkte aus den USA, China oder anderen Nicht-EU-Staaten bezieht und im eigenen Geschäftsbetrieb einsetzt oder weiterverkauft, trägt Mitverantwortung.

    Anwender und Betreiber

    Unternehmen, die Produkte mit digitalen Elementen einsetzen, sind zwar nicht direkt Adressaten des CRA. Mittelbar betrifft sie der CRA aber erheblich — und genau hier wird es für die Kunden von NEOSEC relevant.

    Was der CRA für NEOSEC-Kunden konkret bedeutet

    1. Höhere Baseline-Sicherheit in der Lieferkette

    Der CRA wird dafür sorgen, dass Produkte, die in der EU verkauft werden, ein Mindestmaß an Cybersicherheit mitbringen. Für Betreiber kritischer Infrastrukturen und NIS2-pflichtige Unternehmen bedeutet das langfristig: Die Produkte, die Sie einkaufen, werden sicherer. Kurzfristig bedeutet es allerdings auch: Ihre bestehenden Beschaffungsprozesse müssen angepasst werden. Fragen Sie Ihre Lieferanten nach CRA-Konformität, SBOM und Schwachstellenmanagement-Prozessen.

    2. Wechselwirkung mit NIS2

    NIS2 verpflichtet Unternehmen zu Risikomanagementmaßnahmen — und dazu gehört ausdrücklich auch die Sicherheit in der Lieferkette (Art. 21 Abs. 2 lit. d NIS2-Richtlinie). Der CRA liefert hier das Pendant auf Produktseite. Wer als NIS2-pflichtige Einrichtung Produkte ohne CRA-Konformität einsetzt, könnte mittelfristig Schwierigkeiten bekommen, die eigenen Lieferkettensicherheitspflichten nachzuweisen. Umgekehrt wird die CRA-Konformität eines Produkts zu einem belastbaren Nachweis im Rahmen Ihres NIS2-Risikomanagements.

    3. Software Bill of Materials wird Standard

    Der CRA macht die SBOM — eine maschinenlesbare Aufstellung aller Softwarekomponenten eines Produkts — zur Pflicht. Für Ihr Schwachstellenmanagement ist das ein Gewinn: Wenn ein neues CVE veröffentlicht wird, können Sie anhand der SBOM Ihrer eingesetzten Produkte sofort prüfen, ob betroffene Komponenten in Ihrem Netz laufen. Voraussetzung dafür ist, dass Sie SBOMs Ihrer Lieferanten einfordern und systematisch auswerten — idealerweise automatisiert über Ihr SIEM.

    4. Meldepflichten ergänzen sich

    NIS2 verpflichtet Betreiber zur Meldung von Sicherheitsvorfällen. Der CRA verpflichtet Hersteller zur Meldung aktiv ausgenutzter Schwachstellen. Für Sie als Betreiber heißt das: Sie erfahren schneller von Schwachstellen in den Produkten, die Sie einsetzen. Gleichzeitig steigt die Anforderung, diese Informationen auch operativ zu verarbeiten — also zeitnah zu bewerten, zu priorisieren und zu patchen.

    5. Übergangszeit nutzen

    Bis Dezember 2027 gilt die volle Übergangsfrist. Diese Zeit sollten Unternehmen nutzen, um ihre Beschaffungsprozesse, Lieferantenanforderungen und das interne Schwachstellenmanagement auf den CRA vorzubereiten. Warten Sie nicht, bis Ihre Lieferanten von sich aus CRA-konforme Produkte liefern — setzen Sie die Anforderungen jetzt schon in Ihre Einkaufsbedingungen.

    Handlungsempfehlungen

    Für alle Unternehmen, die IT-Produkte einsetzen:

    • Inventar erstellen: Welche Produkte mit digitalen Elementen setzen Sie ein? Welche davon kommen von Herstellern außerhalb der EU?
    • Lieferantenanforderungen anpassen: Nehmen Sie CRA-Konformität, SBOM-Bereitstellung und definierte Supportzeiträume in Ihre Beschaffungsanforderungen auf
    • SBOM-Management aufbauen: Etablieren Sie Prozesse, um SBOMs Ihrer Lieferanten entgegenzunehmen, zu speichern und bei neuen CVEs automatisiert abzugleichen
    • Schwachstellenmanagement schärfen: Stellen Sie sicher, dass Ihr SOC oder SIEM die Herstellermeldungen zu Schwachstellen aufnehmen und priorisieren kann
    • NIS2-Dokumentation ergänzen: Die CRA-Konformität Ihrer eingesetzten Produkte wird ein wichtiger Baustein in Ihrer NIS2-Risikomanagement-Dokumentation

    Für Unternehmen, die selbst Produkte herstellen oder vertreiben:

    • CRA-Betroffenheit prüfen: Fallen Ihre Produkte unter den CRA? In welche Risikoklasse?
    • Security-by-Design verankern: Überprüfen Sie Ihre Entwicklungsprozesse — Cybersicherheit muss ab der Konzeptionsphase integriert sein
    • Schwachstellenmanagement-Prozess etablieren: 24-Stunden-Meldepflicht an die ENISA bei aktiv ausgenutzten Schwachstellen — das erfordert funktionierende interne Prozesse
    • SBOM generieren: Automatisieren Sie die Erstellung von Software Bills of Materials als Teil Ihrer CI/CD-Pipeline
    • Konformitätsbewertung vorbereiten: Klären Sie frühzeitig, ob eine Selbstbewertung ausreicht oder eine Prüfstelle hinzugezogen werden muss

    Was noch unklar ist

    Der CRA ist als EU-Verordnung unmittelbar anwendbar, benötigt aber nationale Durchführungsgesetze — und genau dort gibt es Nachholbedarf. Der aktuelle deutsche Referentenentwurf weist laut TeleTrusT erhebliche Lücken auf: Die Ausnahme von der Akkreditierungspflicht für Konformitätsbewertungsstellen ist zu weit gefasst, das geplante Reallabor für Cyberresilienz bleibt inhaltlich vage, und die finanzielle Ausstattung der Unterstützungsmaßnahmen für KMU ist unzureichend.

    Für Unternehmen bedeutet das: Planen Sie nicht mit dem Minimalstandard des Durchführungsgesetzes, sondern orientieren Sie sich direkt an den Anforderungen der EU-Verordnung selbst. Das nationale Gesetz wird nur den Vollzugsrahmen regeln — die materiellen Pflichten stehen bereits fest.

    Einordnung

    Der CRA ist neben NIS2 und der CER-Richtlinie der dritte große Baustein im EU-Cybersicherheitsrahmen. Während NIS2 die Betreiber adressiert und die CER-Richtlinie die physische Resilienz, schließt der CRA die Lücke auf Produktseite. Für Unternehmen, die bereits unter NIS2 fallen, ist der CRA keine zusätzliche Belastung, sondern eine sinnvolle Ergänzung: Er sorgt dafür, dass die Produkte, die Sie einsetzen, endlich den Sicherheitsstandards entsprechen müssen, die Sie selbst einhalten sollen.

    Ob der CRA in der Praxis funktioniert, wird maßgeblich davon abhängen, ob die Marktüberwachung durch das BSI tatsächlich wirksam wird — und ob Unternehmen die Übergangszeit nutzen, statt sie aussitzen.

    Sie möchten wissen, wie der CRA konkret auf Ihr Unternehmen wirkt und wie Sie Ihre NIS2-Compliance um die CRA-Dimension erweitern? NEOSEC unterstützt Sie bei der Gap-Analyse, der Bewertung Ihrer Lieferkette und der Integration in Ihr bestehendes Risikomanagement. Sprechen Sie uns an.

  • · ·

    Axios Supply-Chain-Angriff: Was Admins jetzt prüfen müssen

    VonJ. Benjamin Espagné

    Am 31. März 2026 wurde das npm-Paket Axios — mit rund 100 Millionen wöchentlichen Downloads eine der meistgenutzten JavaScript-Bibliotheken weltweit — durch einen Supply-Chain-Angriff kompromittiert. Die trojanisierten Versionen waren nur zwei bis drei Stunden online, bevor sie entfernt wurden. Trotzdem: Bei dieser Verbreitung reicht ein kurzes Zeitfenster, um tausende Entwicklungsumgebungen zu infizieren.

    Google Threat Intelligence hat den Angriff der nordkoreanischen Gruppe UNC1069 zugeordnet. Es handelt sich nicht um einen opportunistischen Angriff, sondern um eine sorgfältig vorbereitete Operation mit plattformübergreifender Malware, Anti-Forensik-Mechanismen und mehrstufiger Verschleierung.

    Was passiert ist

    Die Angreifer kompromittierten den npm-Account des Hauptmaintainers von Axios und veröffentlichten zwei trojanisierte Versionen:

    • axios@1.14.1
    • axios@0.30.4

    Beide Versionen enthielten eine neue Abhängigkeit namens plain-crypto-js@4.2.1 — ein sogenanntes Phantom-Dependency: im Manifest gelistet, aber nirgends im eigentlichen Code verwendet. Dieses Paket enthielt einen verschleierten postinstall-Hook, der beim Installieren automatisch ein Dropper-Skript ausführte.

    Das Skript lud plattformspezifische RAT-Payloads (Remote Access Trojaner) nach:

    • macOS: Binary in /Library/Caches/com.apple.act.mond, Gatekeeper-Bypass via codesign, C2-Callback alle 60 Sekunden
    • Windows: PowerShell-Payload als %PROGRAMDATA%\wt.exe, Persistenz via Registry-Key „MicrosoftUpdate”
    • Linux: Python-Skript als /tmp/ld.py, ausgeführt via nohup

    Nach der Infektion löschte die Malware ihre Spuren: Das kompromittierte package.json wurde durch eine saubere Kopie ersetzt, die Version 4.2.0 statt 4.2.1 meldet. Ein npm list zeigt dann fälschlicherweise eine unbedenkliche Version an.

    Wer betroffen ist

    Potenziell betroffen ist jedes Projekt, das Axios als direkte oder transitive Abhängigkeit nutzt. Laut Wiz betrifft das rund 80 % aller Cloud- und Code-Umgebungen. Fast 175.000 npm-Pakete listen Axios als Dependency.

    Konkret betroffen sind Umgebungen, in denen zwischen dem 31. März (ca. 00:00 UTC) und ca. 03:00 UTC ein npm install, npm update oder ein CI/CD-Build ohne fixiertes Lockfile lief und dabei eine der beiden Versionen gezogen wurde.

    Umgebungen mit einem intakten package-lock.json oder yarn.lock, in denen im Zeitraum kein ungelockerter Install stattfand, sind mit hoher Wahrscheinlichkeit nicht betroffen.

    Sofortmaßnahmen für Admins

    1. Lockfiles und node_modules prüfen

    In jedem Node.js-Projekt auf allen Entwicklungs-, Build- und Produktionsservern:

    # Nach der Phantom-Dependency suchen
grep -r "plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

# Installierte Axios-Version prüfen
npm list axios 2>/dev/null | head -20

# In node_modules direkt suchen
find . -path '*/plain-crypto-js' -type d 2>/dev/null

    Wenn plain-crypto-js auftaucht oder Axios in Version 1.14.1 bzw. 0.30.4 installiert ist: Umgebung als kompromittiert betrachten.

    2. Kompromittierte Systeme isolieren — nicht bereinigen

    Infizierte Entwicklungsrechner und Build-Server sofort vom Netz nehmen. Nicht versuchen, die Malware manuell zu entfernen. Der RAT hat möglicherweise bereits Credentials exfiltriert. Stattdessen:

    • System isolieren und forensisch sichern
    • Von einem bekannt sauberen Snapshot oder Image neu aufsetzen
    • Erst nach dem Rebuild wieder ans Netz nehmen

    3. Credentials rotieren — alle

    Auf betroffenen Systemen gespeicherte Zugangsdaten als kompromittiert betrachten:

    • npm-Tokens
    • SSH-Schlüssel
    • Cloud-Provider-Keys (AWS, Azure, GCP)
    • CI/CD-Secrets (GitHub Actions, GitLab CI, Jenkins)
    • API-Keys und Service-Accounts
    • Datenbank-Zugangsdaten

    Wichtig: Nicht in-place rotieren. Alte Credentials widerrufen, neue auf sauberen Systemen generieren.

    4. CI/CD-Pipelines absichern

    # postinstall-Hooks in CI/CD-Builds deaktivieren
npm ci --ignore-scripts

# Danach nur gezielt Scripts ausführen, die bekannt sicher sind

    Zusätzlich: minimumReleaseAge in der npm-Konfiguration aktivieren. Diese Funktion blockiert die Installation von Paketen, die jünger als ein definierter Zeitraum sind — hätte in diesem Fall den Angriff verhindert, da plain-crypto-js weniger als 24 Stunden existierte.

    5. IOCs prüfen

    Netzwerk-Logs und Endpoint-Monitoring auf folgende Indikatoren prüfen:

    • Outbound-Verbindungen zu unbekannten Domains, die am 30./31. März registriert wurden
    • Prozesse namens com.apple.act.mond (macOS), wt.exe (Windows), ld.py (Linux)
    • Registry-Key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate
    • Dateien in /Library/Caches/com.apple.act.mond

    Präventivmaßnahmen

    Lockfiles konsequent einsetzen

    package-lock.json bzw. yarn.lock sind keine optionale Bequemlichkeit, sondern die wichtigste Verteidigungslinie gegen Supply-Chain-Angriffe dieser Art. In CI/CD immer npm ci statt npm install verwenden — ersteres installiert exakt die im Lockfile festgeschriebenen Versionen.

    Trusted Publishing nutzen

    Beim Axios-Angriff war zwar OIDC Trusted Publishing für die 1.x-Linie konfiguriert, aber ein langlebiger Legacy-Token hatte Vorrang. Prüfen Sie für Ihre eigenen Pakete: Verwenden Sie ausschließlich kurzlebige OIDC-Tokens? Sind Legacy-Tokens widerrufen?

    Dependency-Monitoring etablieren

    Tools wie npm audit, Snyk, Socket oder Dependabot erkennen kompromittierte Pakete oft innerhalb von Minuten. Wer kein automatisches Monitoring hat, erfährt erst durch Zufall oder Medienberichte davon.

    Entwicklungsumgebungen härten

    Entwicklerrechner sind hochwertige Ziele, weil sie typischerweise SSH-Keys, Cloud-Credentials und Repository-Zugang bündeln. Segmentierung, Least-Privilege-Prinzipien und separate Build-Umgebungen reduzieren den Blast Radius erheblich.

    Erweiterte Angriffsfläche: KI-Tools

    Ein oft übersehener Aspekt: KI-gestützte Entwicklungstools wie Claude Code oder OpenAI Codex nutzen ebenfalls npm-Pakete und installieren diese teils automatisiert. Damit erweitert sich die Angriffsfläche über klassische Entwicklerumgebungen hinaus auf alle Arbeitsplätze, an denen solche Tools zum Einsatz kommen — auch bei Nicht-Entwicklern.

    Einordnung

    Dieser Angriff zeigt, wie fragil das Vertrauensmodell im npm-Ökosystem nach wie vor ist. Ein einziger kompromittierter Account — in diesem Fall der des Hauptmaintainers — reicht aus, um Schadcode in hunderttausende nachgelagerte Projekte zu schleusen. Die Attribution zu einer nordkoreanischen APT-Gruppe unterstreicht: Supply-Chain-Angriffe sind kein theoretisches Risiko, sondern ein aktiv genutzter Angriffsvektor staatlicher Akteure.

    Für Unternehmen, die Node.js-basierte Anwendungen entwickeln oder betreiben, ist die konsequente Absicherung der Software-Lieferkette keine Kür mehr — sie ist Pflicht. Wer ein SIEM betreibt, sollte die genannten IOCs in seine Detektionsregeln aufnehmen. Wer keins betreibt, hat ein grundsätzlicheres Problem.

    Sie wollen sicherstellen, dass Ihre Entwicklungs- und Produktionsumgebungen sauber sind? NEOSEC unterstützt Sie bei der forensischen Analyse, dem Incident Response und der nachhaltigen Absicherung Ihrer Software-Lieferkette. Sprechen Sie uns an.

  • ·

    CVE-2026-33017: Kritische Langflow-Schwachstelle wird innerhalb von Stunden ausgenutzt

    VonJ. Benjamin Espagné

    KI-Tooling als Einfallstor: Langflow im Fadenkreuz

    Die US-amerikanische Cybersecurity-Behörde CISA hat die Schwachstelle CVE-2026-33017 in ihren Known Exploited Vulnerabilities (KEV) Catalog aufgenommen und eine Patch-Frist bis zum 8. April 2026 gesetzt. Betroffen ist Langflow, eine weit verbreitete Open-Source-Plattform zur visuellen Erstellung von KI-Workflows und LLM-Agenten — mit über 60.000 GitHub-Stars und wachsender Verbreitung in Unternehmen.

    Die Schwachstelle hat einen CVSS-Score von 9.3 (kritisch) und ermöglicht es Angreifern, ohne Authentifizierung beliebigen Python-Code auf dem Server auszuführen. Das Bemerkenswerte: Die Ausnutzung begann innerhalb von 20 Stunden nach Bekanntwerden — ohne dass ein öffentlicher Exploit-Code existierte.

    Was ist Langflow — und warum wird es angegriffen?

    Langflow ist ein Open-Source-Framework, das es ermöglicht, LLM-Anwendungen (Large Language Models) visuell per Drag-and-Drop zu erstellen. Typische Einsatzgebiete sind RAG-Pipelines (Retrieval-Augmented Generation), KI-Agenten und Workflow-Automatisierungen.

    Die Plattform wird von Entwicklungsteams eingesetzt, die schnell KI-Prototypen und Produktionsworkflows aufbauen wollen. Viele Instanzen laufen auf Cloud-Servern — teilweise ohne ausreichende Absicherung oder hinter öffentlich erreichbaren Endpoints. Genau das macht sie zu einem attraktiven Ziel für automatisierte Angriffe.

    Technische Details: CVE-2026-33017

    Die Schwachstelle liegt im Endpoint build_public_tmp, der für öffentliche Flows konzipiert ist und absichtlich ohne Authentifizierung arbeitet. Das Problem: Der Endpoint akzeptiert vom Angreifer übermittelte Flow-Daten, die eingebetteten Python-Code enthalten können. Dieser Code wird ohne Sandboxing direkt auf dem Server ausgeführt.

    Laut der NVD-Beschreibung ist dies eine eigenständige Schwachstelle, die sich von CVE-2025-3248 unterscheidet. Letztere betraf den Endpoint /api/v1/validate/code und wurde durch das Hinzufügen einer Authentifizierung behoben. CVE-2026-33017 nutzt einen anderen Angriffsvektor über einen bewusst öffentlich zugänglichen Endpoint.

    Betroffen sind alle Langflow-Versionen bis 1.8.2. Das Update auf Version 1.9.0 behebt die Schwachstelle.

    20 Stunden vom Advisory zum Angriff

    Laut einem Bericht von Sysdig begannen Angreifer innerhalb von 20 Stunden nach Veröffentlichung des Advisories, verwundbare Langflow-Instanzen zu attackieren. Sysdig hatte Honeypot-Nodes mit verwundbaren Instanzen über mehrere Cloud-Provider verteilt und beobachtete vier Angriffsversuche innerhalb weniger Stunden nach Deployment.

    Ein Angreifer ging dabei über das initiale Scanning hinaus und exfiltrierte Umgebungsvariablen — einschließlich Zugangsdaten und API-Keys.

    Besonders alarmierend: Es existierte zum Zeitpunkt der ersten Angriffe kein öffentlicher Exploit-Code auf GitHub. Das Advisory selbst enthielt genügend Details — den verwundbaren Endpoint-Pfad und den Mechanismus zur Code-Injection über Flow-Node-Definitionen — um einen funktionierenden Exploit zu konstruieren.

    Einheitliches Angriffsmuster: os.popen() + HTTP-Exfiltration

    Sysdig identifizierte ein konsistentes Post-Exploitation-Playbook über alle beobachteten Angriffe hinweg:

    • Shell-Befehl über Pythons os.popen() ausführen
    • Output über HTTP an externe C2-Infrastruktur exfiltrieren
    • Umgebungsvariablen (Credentials, API-Keys) abgreifen

    Sysdig veröffentlichte zudem eine Liste von Indicators of Compromise (IOCs), darunter Angreifer-IPs, C2-Infrastruktur, Dropper-URLs und Interactsh-Callback-Domains.

    Warum Runtime Detection entscheidend ist

    Sysdig betont, dass bei derart schneller Ausnutzung klassische Patch-Zyklen nicht mehr ausreichen. Runtime Detection bleibt die primäre Verteidigungslinie. Die eingesetzten Erkennungsregeln benötigen keine spezifische Signatur für CVE-2026-33017, weil sie das Exploitation-Verhalten erkennen, nicht die Schwachstelle selbst. Dieselben Regeln greifen unabhängig davon, ob der initiale Zugang über CVE-2026-33017, CVE-2025-3248 oder eine andere RCE erfolgt.

    Das heißt: Verhaltensbasierte Erkennung erkennt den Angriff unabhängig von der spezifischen Schwachstelle — ob bekannt oder unbekannt.

    Was Unternehmen jetzt tun müssen

    • Sofort patchen: Update auf Langflow v1.9.0 oder höher
    • Exponierte Instanzen prüfen: Jede öffentlich erreichbare Langflow-Instanz als potenziell kompromittiert behandeln
    • Zugang einschränken: Langflow niemals ohne Authentifizierung und Netzwerksegmentierung betreiben
    • Umgebungsvariablen rotieren: Alle Credentials, API-Keys und Datenbankzugänge auf kompromittierten Systemen sofort wechseln
    • Runtime Monitoring: Verhaltensbasierte Erkennung implementieren, die Shell-Ausführung und HTTP-Exfiltration erkennt
    • IOCs prüfen: Sysdig-IOCs gegen eigene Logs abgleichen
  • ·

    APIs sind die neue Angriffsfläche — und die meisten Unternehmen sind blind

    VonJ. Benjamin Espagné

    Die Front hat sich verschoben

    „Wir haben früher über Defense-in-Depth und Endpoint Protection gesprochen. Dann kam Identity. Jetzt ist die API das neue Perimeter.“ So beschreibt Sean Murphy, CISO bei BECU, einem der größten US-Kreditinstitute, die aktuelle Lage. Und er steht mit dieser Einschätzung nicht allein.

    In einer aktuellen Erhebung von CSO Online berichten mehrere CISOs übereinstimmend: APIs haben Endpoints als primäre Angriffsfläche abgelöst. Sie sind die Eingangstür zu Backend-Systemen, Partnerschnittstellen und Kundendaten — und in vielen Unternehmen weder inventarisiert noch ausreichend geschützt.

    Die Zahlen: Jede dritte Organisation betroffen

    Ein Salt Security Report von 2025 zeigt:

    • Jede dritte Organisation wurde in den letzten 12 Monaten über eine API kompromittiert
    • 95 % der API-Angriffe kommen von authentifizierten Quellen — über gestohlene API-Keys oder Credentials

    Laut einer Studie von Enterprise Management Associates haben rund 70 % der Unternehmen nur 30 % ihrer APIs dokumentiert. Der Rest? Shadow-APIs, die außerhalb jeder Sicherheits-Governance existieren.

    Konservative Schätzungen gehen davon aus, dass ein Großunternehmen zwischen 250 und 500 APIs betreibt. In der Realität sind es oft Tausende.

    Warum EDR und WAF versagen

    Das Kernproblem: Traditionelle Sicherheitswerkzeuge wie EDR, XDR und WAF sind für API-Angriffe schlicht nicht gebaut. Sie erkennen Malware auf Endpoints und einfache Web-Exploits — aber API-Missbrauch sieht für diese Systeme wie normaler, valider Traffic aus.

    Elliott Franklin, CISO bei Fortitude Re, bringt es auf den Punkt: EDR und WAFs wurden für die Probleme von gestern gebaut. Ohne ein tiefes Verständnis von Business Logic und Identity Context übersehen traditionelle Tools Credential Stuffing, Token-Diebstahl oder Data Scraping.

    API-Angriffe nutzen keine Payload-Patterns, die eine WAF erkennen würde. Sie missbrauchen Business Logic: gebrochene Authentifizierung, übermäßig permissive Autorisierung, exzessive Datenexposition. Einzeln betrachtet sind die Requests valide — erst in der Sequenz entsteht der Angriff.

    James Faxon, Principal Advisor bei der Risk & Insight Group, erklärt: Ein Angreifer braucht keinen Laptop zu kompromittieren und keine Malware zu deployen. Mit einem gestohlenen Token und einer fehlerhaften Autorisierungslogik kann er sich lateral bewegen und Daten extrahieren, ohne traditionelle Endpoint-Controls auszulösen.

    KI verschärft das Problem — auf beiden Seiten

    Chaim Mazal, Chief AI and Security Officer bei Gigamon, warnt: KI hat die Demokratisierung offensiver Tools ermöglicht. Jeder kann jetzt API-Schwachstellen ausnutzen, unabhängig vom Skill-Level — ohne eine einzige Zeile Code zu schreiben.

    Gleichzeitig vergrößert KI die Angriffsfläche von innen: Agentic AI, die autonom über APIs mit Systemen interagiert — einschließlich Model Context Protocol (MCP), Agent-to-Agent-Workflows und automatisierter Integrationen — schafft neue, schwer kontrollierbare Zugriffspfade.

    Eine Studie von Software Finder (2025) zeigt: 56 % der IT-Entscheider erwarten, dass ihr Software-Stack bis 2030 KI-gesteuert sein wird. Mehr KI bedeutet mehr API-Aufrufe, mehr nicht-menschliche Identitäten, mehr Angriffsfläche.

    Die Lieferkette als API-Risiko

    Laut Gartner nutzen 71 % der Unternehmen APIs von Drittanbietern — SaaS-Plattformen, Cloud-Dienste, Partner-Integrationen. Jede dieser Verbindungen ist ein potenzieller Angriffsvektor.

    Patrick Opet, CISO von JPMorganChase, veröffentlichte 2025 einen offenen Brief, in dem er warnte, dass das SaaS-Modell „stillschweigend Cyber-Angreifer ermöglicht“ und eine „substanzielle Schwachstelle schafft, die das globale Wirtschaftssystem schwächt“.

    In der Praxis heißt das: API-Keys und Tokens landen in Repositories, werden nicht rotiert, haben übermäßige Berechtigungen und sind teilweise offen im Web auffindbar. Escape entdeckte 2024 über 18.000 API-Secrets und Tokens im offenen Internet.

    Was CISOs empfehlen

    1. API-Inventar aufbauen

    „Was man nicht sieht, kann man nicht schützen“, sagt Andreas Gaetje, CISO bei Körber. Der erste Schritt ist ein vollständiges Inventar aller APIs — intern, extern, und von Drittanbietern. Jede API braucht einen Owner, eine Dokumentation und eine Threat-Model-Bewertung.

    2. API Governance einführen

    BECU implementierte eine einheitliche API-Policy für alle Entwickler — noch bevor die Technologie ausgerollt wurde. Jeder API-Builder unterliegt derselben internen Richtlinie. Das reduziert Fehlkonfigurationen, die laut OWASP Top 10 das größte API-Risiko darstellen.

    3. Identity-basierte Absicherung

    APIs als „nicht-menschliche Identitäten“ behandeln: Least-Privilege-Prinzip, zeitgebundene RBAC, regelmäßige Token-Rotation. Fortitude Re integriert API-Sicherheit direkt in die IAM-Strategie und trackt aktiv nicht-menschliche Identitäten.

    4. Security in die CI/CD-Pipeline

    API-Spezifikationen müssen automatisierte Sicherheitsvalidierung durchlaufen, bevor sie deployed werden. Infinite Computer Solutions hat Security-Checks direkt in die CI/CD-Pipeline eingebettet.

    5. Verhaltensbasiertes Runtime-Monitoring

    Wenn ein API-Consumer außerhalb seines erwarteten Musters agiert, ist das ein Security Event, keine technische Anomalie. Runtime-Erkennung ist die einzige Verteidigung, die bei Zero-Day-Exploitation funktioniert.

    6. Third-Party-APIs wie Risiken behandeln

    Credentials von Drittanbietern zentralisieren und verschlüsseln. Niemals rohe API-Keys an Entwicklungsteams verteilen. Regelmäßig rotieren und auf Behavioral Drift überwachen.

  • ·

    Wenn die Firewall selbst zur Sicherheitslücke wird — Was CVE-2026-20131 für Ihr Unternehmen bedeutet

    VonJ. Benjamin Espagné

    Es gibt Cyberangriffe, die einen innehalten lassen. CVE-2026-20131 ist so einer. Denn diesmal sitzt die Schwachstelle nicht in einer veralteten Anwendung, nicht in einem vergessenen System im Keller des Rechenzentrums — sondern direkt im Herz der Netzwerksicherheit: im Management-Interface von Cisco Secure Firewall.

    Die amerikanische Bundesbehörde für Cybersicherheit CISA hat in dieser Woche einen dringenden Warnhinweis herausgegeben. Die Lücke wird aktiv ausgenutzt. Nicht theoretisch. Nicht in Proof-of-Concept-Demos. Sondern in echten Ransomware-Angriffen gegen echte Unternehmen — jetzt, gerade, während Sie diese Zeilen lesen.

    Was passiert technisch — und warum es so gefährlich ist

    Das Cisco Secure Firewall Management Center ist das Werkzeug, mit dem IT-Teams ihre Firewall-Infrastruktur zentral steuern und überwachen. Genau dieses Interface hat eine Schwachstelle in der Art, wie es eingehende Datenpakete verarbeitet.

    Die Lücke erlaubt es einem Angreifer, über das öffentlich erreichbare Management-Interface eigenen Code einzuschleusen und auszuführen — mit vollen Systemrechten. Das Fatale: Es wird dafür kein gültiges Passwort, keine Zugangsdaten, keine vorherige Authentifizierung benötigt. Wer das Management-Interface aus dem Internet erreichen kann, kann angreifen.

    Mit vollen Administratorrechten auf dem Firewall-Management kann ein Angreifer Sicherheitsregeln deaktivieren oder gezielt umschreiben, Protokollierung und Alarmierung abstellen — der Einbruch bleibt unsichtbar —, den eigentlichen Ransomware-Angriff auf das dahinterliegende Netzwerk vorbereiten und sich dauerhaft im System festsetzen, bevor irgendjemand Alarm schlägt.

    Wer Kontrolle über das Firewall-Management hat, hat im Wesentlichen Kontrolle über die gesamte Netzwerksicherheit des Unternehmens.

    Betroffen: Cisco Secure Firewall Management Center und Security Cloud Control

    Konkret betroffen sind Unternehmen, die Cisco Secure Firewall Management Center (FMC) in verschiedenen Versionen sowie Cisco Security Cloud Control einsetzen. Cisco ist eines der weltweit meistgenutzten Netzwerk- und Sicherheitsunternehmen — entsprechend groß ist die Angriffsfläche.

    Die eigentliche Botschaft: Prävention versagt — Detektion ist alles

    Viele Sicherheitsstrategien bauen auf dem Prinzip auf: Wenn wir die Firewall richtig konfigurieren, sind wir sicher. CVE-2026-20131 zeigt einmal mehr, dass dieses Prinzip allein nicht ausreicht.

    Eine Zero-Day-Lücke ist per Definition eine Schwachstelle, für die es zum Zeitpunkt der Angriffe noch keinen Patch gibt oder die so neu ist, dass viele Systeme noch ungepacht sind. Auch nach Bekanntwerden dauert das vollständige Einspielen von Patches in verteilten Unternehmensinfrastrukturen oft Tage bis Wochen.

    Die entscheidende Frage lautet deshalb nicht: „Haben wir eine Firewall?” — sondern: „Merken wir, wenn jemand unsere Firewall bereits kompromittiert hat?”

    Hier kommen API-Sicherheitslösungen wie Neosec eine zentrale Rolle zu. Moderne Angriffe — inklusive solcher, die über Management-Interfaces laufen — hinterlassen Spuren im API-Traffic. Ungewöhnliche Anfragen. Zugriffsmuster, die von normalen Administrationsmustern abweichen. Befehle, die zu ungewöhnlichen Zeiten ausgeführt werden. Wer diese Anomalien in Echtzeit erkennt, kann handeln, bevor der eigentliche Schaden entsteht.

    Was jetzt zu tun ist

    Sind wir betroffen? Setzen wir Cisco Secure Firewall Management Center oder Cisco Security Cloud Control ein? Wenn ja, ist sofortiges Handeln angezeigt. Cisco hat Sicherheitshinweise und — sofern verfügbar — Patches herausgegeben.

    Ist das Management-Interface aus dem Internet erreichbar? Jedes Firewall-Management-Interface, das direkt aus dem öffentlichen Internet erreichbar ist, vergrößert die Angriffsfläche massiv. Die Best Practice: Management-Zugang ausschließlich über VPN oder isolierte Management-Netzwerke.

    Haben wir Monitoring auf ungewöhnliches Verhalten? Nicht jede Attacke lässt sich verhindern. Aber jede Attacke hinterlässt Spuren — wenn man hinsieht. Stellen Sie sicher, dass Ihre Sicherheitsinfrastruktur Anomalien im API- und Management-Traffic aktiv überwacht und alarmiert.

    Was ist unser Incident-Response-Plan? Wenn ein Angriff über diesen Vektor stattgefunden hat — wer wird informiert? Wer entscheidet über Gegenmaßnahmen? Diese Fragen sollten nicht erst im Ernstfall beantwortet werden.

    Fazit

    CVE-2026-20131 ist kein Einzelfall. Es ist ein weiteres Kapitel in einer langen Geschichte von Schwachstellen in genau den Systemen, denen wir am meisten vertrauen. Perimeter-Sicherheit allein ist seit Jahren nicht mehr ausreichend.

    Unternehmen, die heute resilient gegenüber solchen Angriffen sind, haben eines gemeinsam: Sie gehen davon aus, dass Angreifer möglicherweise bereits im Netzwerk sind. Sie investieren in Detektion, Sichtbarkeit und die Fähigkeit, schnell zu reagieren — nicht nur darin, den Einbruch zu verhindern.

    Neosec hilft dabei, genau diese Sichtbarkeit herzustellen — besonders dort, wo moderne Angriffe ansetzen: in den APIs und Management-Interfaces, über die heute Infrastruktur gesteuert wird.

    Sprechen Sie uns an. Sicherheit beginnt damit, zu wissen, was gerade in Ihrem Netzwerk passiert.

    Quellen: CISA Advisory zu CVE-2026-20131, Cisco Security Advisory (März 2026)

  • · ·

    KI beschleunigt Exploits – die Lücke zwischen Bekanntwerden und Angriff schrumpft drastisch

    VonJ. Benjamin Espagné

    Künstliche Intelligenz verändert die Sicherheitslandschaft in einem Tempo, dem viele Unternehmen kaum hinterherkommen. Aktuelle Analysen des SANS Institute zeigen, dass KI nicht nur die Reaktionsgeschwindigkeit von Security Operations Centers beeinflusst, sondern vor allem das Timing von Angriffen selbst. Der Zeitraum zwischen der öffentlichen Bekanntgabe einer Schwachstelle und ihrer ersten aktiven Ausnutzung verkürzt sich zunehmend – in vielen Fällen von mehreren Wochen auf wenige Stunden oder Minuten.

    Diese Entwicklung wird zusätzlich durch neue Infrastrukturtaktiken verstärkt. Die US-amerikanische National Security Agency (NSA) warnt gemeinsam mit internationalen Partnern vor der zunehmenden Nutzung sogenannter Fast-Flux-Netzwerke. Dabei wechseln Angreifer IP-Adressen und DNS-Zuordnungen extrem schnell, um Command-and-Control-Server, Exploit-Infrastruktur und Malware-Verteilung zu verschleiern.

    In Kombination mit KI-gestützter Schwachstellenanalyse entsteht eine neue Dynamik: Sobald technische Details zu einer Schwachstelle verfügbar sind, können automatisierte Systeme Exploits generieren, Infrastruktur dynamisch aufbauen und Angriffe nahezu in Echtzeit durchführen. Klassische Verteidigungsmodelle, die auf verzögerte Patch-Zyklen und manuelle Analyse setzen, geraten dadurch massiv unter Druck.

    Die NSA stuft Fast-Flux inzwischen als nationale Sicherheitsbedrohung ein. Besonders kritisch ist die Nutzung solcher Techniken durch staatlich unterstützte Akteure und organisierte Cybercrime-Gruppen, da sie Erkennung, Attribution und Abschaltung erheblich erschweren.

  • · ·

    Neue “Erfahrungen”: Adobe Experience Manager schafft es in die Hall of Shame

    VonJ. Benjamin Espagné

    Die US-Behörde CISA (Cybersecurity and Infrastructure Security Agency) hat am 15. Oktober 2025 eine kritische Sicherheitslücke in Adobe Experience Manager (AEM) in ihren Known Exploited Vulnerabilities (KEV)-Katalog aufgenommen. Die Schwachstelle mit der Kennung CVE-2025-54253 erlaubt Remote-Code-Execution (RCE) über eine fehlerhafte Konfiguration in der Administrationsoberfläche von AEM Forms on JEE – CVSS-Score 10.0, also maximal kritisch.

    Betroffen sind AEM-Versionen 6.5.23.0 und älter. Adobe hatte bereits im August 2025 ein außerplanmäßiges Update bereitgestellt, nachdem ein Proof-of-Concept öffentlich geworden war. CISA setzt nun eine verbindliche Patch-Frist bis zum 5. November 2025.

    Neosec hat ermittelt: Laut BuiltWith setzen über 2.700 produktive Websites in Deutschland auf AEM – darunter große Konzerne aus der Automobil-, Industrie-, Energie- und Finanzbranche. Zu den bekannten AEM-Nutzern zählen BMW, Mercedes-Benz, Volkswagen, SAP, Allianz, Fresenius, E.ON, DHL, Toyota, Philips und viele andere. BuiltWith verzeichnet zudem mehr als 3.000 weitere Domains, bei denen AEM bereits in der Implementierungsphase ist – darunter Porsche SE.

    Die Lücke reiht sich ein in eine Serie kritischer AEM-Schwachstellen (u. a. CVE-2025-49533, CVE-2025-54254) und betrifft insbesondere Umgebungen, in denen AEM als zentrale Content-Management-Plattform mit Backend-Systemen wie SAP, Salesforce oder Azure AD integriert ist. Ein erfolgreicher Angriff kann daher vollständige Systemkompromittierung und Datenabfluss sensibler Informationen zur Folge haben.

  • · ·

    Wenn Berechtigung zur Schwachstelle wird – Das Zeitalter des Authorization Sprawl

    VonDr. Anatolii Nazarko

    Die Ergebnisse des aktuellen SANS Whitepapers von Joshua Wright „Authorization Sprawl – The Vulnerability Reshaping Modern Attacks“ (Oktober 2025) zeigen eindrucksvoll, wie sich eine unscheinbare Sicherheitslücke zum größten Risiko moderner IT-Landschaften entwickelt hat.

    Unter Authorization Sprawl versteht man die unkontrollierte Ausbreitung von Zugriffsrechten über Systeme, Cloud-Dienste, SaaS-Anwendungen und Identitätsplattformen hinweg. Durch die zunehmende Integration von SSO, API-Tokens und föderierten Identitäten entstehen unzählige „Seitentüren“ ins Unternehmensnetz.

    Während Authentifizierung (Login, MFA, EDR) in den letzten Jahren stark verbessert wurde, hinkt die Kontrolle der Autorisierung weit hinterher. Angreifer nutzen diese Schwäche gezielt aus: Ein kompromittierter Account, ein offener Token, ein vergessenes Servicekonto – und schon ist der Weg frei für Datenexfiltration, lateral movement und Privilegienausweitung.

    Bekannte Gruppen wie Scattered Spider, LAPSUS$ oder ShinyHunters setzen diese Methode inzwischen systematisch ein. Sie kombinieren Social Engineering, gestohlene OAuth-Tokens und API-Schlüssel mit SaaS-Schwachstellen – und umgehen damit klassische Schutzsysteme völlig unbemerkt.

    Die Untersuchung von SANS zeigt:

    • Moderne EDR-Systeme erkennen diese Angriffe nicht, weil sie innerhalb legitimer Prozesse stattfinden (z. B. Browser, AWS- oder M365-Sessions).
    • VPNs und lokale Proxys verschleiern Geodaten und umgehen Impossible Travel Detection.
    • Viele SaaS-Anbieter bieten nur rudimentäres oder kostenpflichtiges Logging, was Incident Response massiv erschwert.

    Kurz gesagt: Wir haben gelernt, wer sich anmeldet – aber nicht, was er danach tut.

  • Zwei neue Windows-Zero-Days erschüttern das Vertrauen in Microsofts Update-Kultur

    VonJ. Benjamin Espagné

    Am 15. Oktober 2025 veröffentlichte Microsoft Patches für 183 Sicherheitslücken – darunter zwei aktiv ausgenutzte Zero-Days:

    • CVE-2025-24990: Schwachstelle im „Agere Modem Driver“, betrifft jede Windows-Version seit 2000.
    • CVE-2025-59230: Lücke im „Remote Access Connection Manager (RasMan)“.

    Beide erlauben Privilegienerweiterungen bis hin zu Systemrechten. Besonders kritisch: Der betroffene Treiber ist selbst auf Systemen installiert, die gar keine Modem-Hardware besitzen. Microsoft kündigte an, ihn vollständig zu entfernen – ein seltenes Eingeständnis, wie tief verwurzelte Legacy-Komponenten noch immer Risiken bergen.

  • · ·

    Shellshock-Angriffe sind wieder auf dem Vormarsch – was Sie jetzt wissen müssen

    VonJ. Benjamin Espagné

    Die Shellshock-Schwachstelle, auch bekannt als Bash-Bug (CVE-2014-6271 und weitere), wurde bereits 2014 entdeckt und gilt damals wie heute als extrem gefährlich; sie ermöglicht Angreifern, beliebigen Code über manipulierte Umgebungsvariablen einzuschleusen, wenn Bash-Skripte etwa in CGI-Anwendungen genutzt werden.

    Bereits 2014 kam es zu einem massiven Aufkommen an Scans, Exploits und Botnetz-Aktivitäten; auch namhafte Ziele wie große Internetplattformen und Regierungsinstitutionen waren betroffen. Trotz der Veröffentlichung von Patches hat sich die Bedrohung bis heute nicht aufgelöst: Laut aktuellen Analysen zielen Angreifer wieder verstärkt auf Organisationen ab, darunter Banken und Finanzdienstleister.

    Nach unseren jüngsten Erhebungen müssen wir warnen: Shellshock-Schwachstellen in Web-Anwendungen werden erneut vermehrt aktiv angegriffen – alte Systemkomponenten bleiben ein Risikofaktor in der Lieferkette.

Keine weiteren News.

Keine weiteren News.

Sicherheitslücken schließen. Risiken senken. Jetzt handeln!

Unsere Experten zeigen Ihnen live, wie wir Angriffe erkennen, stoppen und Ihr Unternehmen schützen.

Blog

Aktuelle Sicherheitsereignisse