Joseph Lee

Cisco-Unternehmensgeräte: Weitere kritische Sicherheitslücken und aktive Ausnutzung im Juni 2026

Cisco-Produkte wurden in den letzten Monaten von schwerwiegenden, aktiv ausgenutzten Sicherheitslücken heimgesucht [1][2][3][4][5][6][7][8][9]. Zu den kürzlich ausgenutzten Schwachstellen im Catalyst SD-WAN Manager und Controller gehören CVE-2026-20133 (CVSS 7.5, EPSS >= 95. Perzentil), CVE-2026-20128 (CVSS 7,8, EPSS >= 90. Perzentil), CVE-2026-20122 (CVSS 5.4, EPSS >= 93. Perzentil), CVE-2026-20127 (CVSS 10, EPSS 99. Perzentil) sowie CVE-2026-20182 (CVSS 10, EPSS >= 99. Perzentil). Insgesamt sind in diesem Jahr elf Cisco-Sicherheitslücken in den Katalog „Known Exploited Vulnerabilities“ (KEV) der CISA aufgenommen worden.

SD-WAN-Plattformen sind für Cyberangreifer attraktiv, da sie Routing, die Durchsetzung von Richtlinien, Netzwerktransparenz und administrative Kontrolle in Unternehmens-IT-Umgebungen zentralisieren. Die wiederholte Ausnutzung von SD-WAN-Schwachstellen deutet darauf hin, dass Angreifer vorrangig Ziele in der Netzwerkinfrastruktur ins Visier nehmen, die die Manipulation des Datenverkehrs [T1565.002], die laterale Bewegung [TA0008], Persistenz [TA0003] sowie weitreichendere operative Auswirkungen einschließlich Ransomware-Angriffen ermöglichen.

Der OPENVAS ENTERPRISE FEED von Greenbone bietet Erkennung für alle in diesem Blogbeitrag behandelten CVEs und enthält eine eigene Familie zur Erkennung von Cisco-Sicherheitslücken. Hier sind die wichtigsten neuen Bedrohungen für Cisco-Produkte aus dem Juni 2026:

Weitere kritische Cisco-Sicherheitslücken und aktive Ausnutzung im Juni 2026

CVE-2026-20245 und CVE-2026-20262: Neue Schwachstellen in Catalyst SD-WAN werden aktiv ausgenutzt

CVE-2026-20245: Authentifizierte Befehlsausführung mit Root-Rechten

CVE-2026-20245 (CVSS 7.8, EPSS >= 57. Perzentil), veröffentlicht am 4. Juni 2026, ermöglicht es einem authentifizierten lokalen Angreifer mit netadmin-Rechten, beliebige Befehle als Root auf dem Cisco Catalyst SD-WAN Controller, Manager und Validator auszuführen. Die Ursache ist eine unzureichende Validierung von Benutzereingaben in hochgeladenen Dateien [CWE-20]. Laut Mandiant nutzten Angreifer gestohlene Anmeldedaten in Verbindung mit CVE-2026-20245, um sich über einen bösartigen CSV-Upload Root-Zugriff zu verschaffen.

CVE-2026-20245 betrifft den Cisco Catalyst SD-WAN Controller, den Cisco Catalyst SD-WAN Manager und den Cisco Catalyst SD-WAN Validator in allen Bereitstellungsarten, einschließlich On-Premises, Cisco SD-WAN Cloud-Pro, Cisco-verwalteter SD-WAN-Cloud und Cisco SD-WAN for Government. Cisco hat Korrekturen in den Catalyst SD-WAN-Versionen 20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1 und 26.1.1.2 veröffentlicht. Es gibt keine Workarounds, und Cisco empfiehlt, ein Upgrade auf eine behobene Version durchzuführen, nachdem die Protokolle gesichert und die Admin-Tech-Dateien zur Überprüfung des Kompromittierungsvorfalls gesammelt wurden.

CVE-2026-20262: Authentifizierte Dateierstellung mit Angriffskette für eine Kompromittierung auf Root-Ebene

CVE-2026-20262 (CVSS 6.5, EPSS >= 63. Perzentil), veröffentlicht am 15. Juni 2026, ermöglicht es einem authentifizierten Angreifer aus der Ferne mit geringen Berechtigungen und gültigem Schreibzugriff, Dateien auf Cisco Catalyst SD-WAN Manager-Systemen zu erstellen oder zu überschreiben. Die Schwachstelle wird durch eine unzureichende Einschränkung der Pfadnamen beim Hochladen von Dateien verursacht [CWE-22]. Cisco bestätigte im Juni 2026 begrenzte Ausnutzungsaktivitäten, und die CISA hat CVE-2026-20262 in seinen KEV-Katalog aufgenommen. Es gibt keine Hinweise auf einen öffentlich zugänglichen PoC-Exploit oder eine detaillierte technische Analyse durch Dritte.

Laut Cisco können Angreifer die erforderlichen Berechtigungen durch gültige Anmeldedaten oder die vorherige Ausnutzung von CVE-2026-20182 (CVSS 10) oder CVE-2026-20127 (CVSS 10) erlangen, und der offizielle Hinweis des Herstellers beschreibt vereinzelte Fälle, in denen durch die Ausnutzung des Schwachpunkts Konfigurationsänderungen auf Edge-Geräte übertragen wurden. Catalyst SD-WAN Manager-Systeme mit Internetanbindung sind einem höheren Risiko ausgesetzt, da durch den Missbrauch verdächtige WAR- oder JSP-Dateien hochgeladen, schädlicher Code eingesetzt und möglicherweise Folgeaktivitäten vorbereitet werden können, die zu einer Kompromittierung auf Root-Ebene führen.

Der Cisco Catalyst SD-WAN Manager war unabhängig von der Gerätekonfiguration in allen Bereitstellungen betroffen, darunter On-Premises-, Cisco SD-WAN Cloud-Pro-, Cisco SD-WAN Cloud- (Cisco Managed) und Cisco SD-WAN for Government- (FedRAMP) Umgebungen. Cisco hat das Problem in den Versionen 20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1 und 26.1.1.2 behoben. Es gibt keine Workarounds für CVE-2026-20262, daher ist zur Behebung des Problems ein Upgrade auf eine behobene Version erforderlich. Der OPENVAS ENTERPRISE FEED enthält eine Remote-Banner-Prüfung zur Identifizierung von Geräten, die von CVE-2026-20262 betroffen sind.

CVE-2026-20230: Unified Communications Manager wird aktiv über nicht authentifizierte HTTP-Anfragen ausgenutzt

CVE-2026-20230 (CVSS 8.6, EPSS 42. Perzentil), veröffentlicht am 3. Juni 2026, ermöglicht es einem nicht authentifizierten Angreifer aus der Ferne, Cisco Unified Communications Manager und Unified CM Session Management Edition über eine serverseitige Request-Forgery-Sicherheitslücke im WebDialer [CWE-918] auszunutzen. Die Ursache ist eine unzureichende Eingabevalidierung von HTTP-Anfragen. Für die Ausnutzung muss WebDialer aktiviert sein, welcher standardmäßig deaktiviert ist. Erfolgreiche Angriffe können jedoch Dateien auf das zugrunde liegende Betriebssystem schreiben und eine spätere Rechteausweitung auf Root-Ebene ermöglichen.

Die CISA hat CVE-2026-20230 in ihre KEV-Liste aufgenommen, womit es sich um die zweite bekannte, aktiv ausgenutzte CVE in Cisco Unified Communications Manager im Jahr 2026 handelt. Berichten zufolge wird die Sicherheitslücke genutzt, um Web-Shells [T1505.003] zur Remote-Code-Ausführung (RCE) zu platzieren. Öffentlicher PoC-Exploit-Code und eine vollständige technische Beschreibung wurden von SSD Secure Disclosure veröffentlicht.

Cisco hat Korrekturen für Unified CM und Unified CM SME 14SU6 sowie 15SU5 oder COP1 veröffentlicht, weist darauf hin, dass es keine Workarounds gibt, und empfiehlt, WebDialer als vorübergehende Abhilfemaßnahme zu deaktivieren, bis die Installation der Patches abgeschlossen ist. Der OPENVAS ENTERPRISE FEED enthält eine Erkennung auf Paketebene für CVE-2026-20230.

Zwei kritische Sicherheitslücken in Cisco ISE – eine ermöglicht RCE auf Root-Ebene

CVE-2026-20181 (CVSS 9.1, EPSS 43. Perzentil) und CVE-2026-20190 (CVSS 7.5, EPSS 29. Perzentil), veröffentlicht am 17. Juni 2026, ermöglichen RCE, die Ausweitung von Berechtigungen, Denial-of-Service (DoS) und die Offenlegung von Informationen in der Cisco Identity Services Engine und dem Cisco ISE Passive Identity Connector. Es liegen keine Berichte über aktive Ausnutzung vor, und PoC-Exploit-Code oder detaillierte technische Analysen sind noch nicht verfügbar.

CVE-2026-20181 ermöglicht es einem authentifizierten Administrator, HTTP-Anfragen auszunutzen, um Zugriff auf das Betriebssystem auf Benutzerebene zu erlangen und die Berechtigungen auf Root-Ebene zu erweitern. CVE-2026-20190 ermöglicht es einem nicht authentifizierten Angreifer, auf sensible Informationen zuzugreifen, darunter gehashte Anmeldedaten, die Folgeangriffe ermöglichen könnten, sofern diese Anmeldedaten geknackt werden können. Beide Schwachstellen betreffen Cisco ISE und ISE-PIC unabhängig von der Gerätekonfiguration. In Umgebungen mit einem einzelnen Knoten kann CVE-2026-20181 dazu führen, dass der ISE-Knoten nicht mehr verfügbar ist, wodurch die Authentifizierung durch andere Endpunkte verhindert wird, bis der Knoten wiederhergestellt ist.

Cisco gibt an, dass es für keine der beiden Sicherheitslücken Workarounds gibt; betroffene Kunden sollten daher ein Upgrade durchführen oder gegebenenfalls den verfügbaren Hotpatch anwenden. Siehe den Sicherheitshinweis von Cisco für konkrete betroffene Versionen und Anweisungen zum Upgrade. Der OPENVAS ENTERPRISE FEED umfasst die Erkennung auf Paketebene sowohl für CVE-2026-20181 als auch für CVE-2026-20190 [1][2].

Zusammenfassung

Cisco sah sich im Juni 2026 inmitten einer anhaltenden Flut von Sicherheitsbedrohungen einer weiteren Welle von Sicherheitsrisiken für seine Unternehmensprodukte ausgesetzt. Zu den neu auftretenden Bedrohungen zählen neue, aktiv ausgenutzte Schwachstellen in Catalyst SD-WAN und Unified Communications Manager sowie kritische Cisco ISE-Schwachstellen. Die Probleme ermöglichen die Ausführung von Befehlen auf Root-Ebene, das Erstellen von Dateien, SSRF-Angriffe, die Offenlegung von Anmeldedaten und DoS-Angriffe sowie potenzielle Folgeangriffe, falls Anmeldedaten geknackt werden. Der OPENVAS ENTERPRISE FEED von Greenbone bietet Erkennung für alle in diesem Blogbeitrag behandelten CVEs und enthält eine spezielle Familie zur Erkennung von Cisco-Sicherheitslücken. Verteidiger können Greenbones Flaggschiff OPENVAS BASIC kostenlos testen, einschließlich einer zweiwöchigen Testversion des OPENVAS ENTERPRISE FEED.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Greenbone AG

Die 5 Reifegrade im Schwachstellenmanagement

Ein effektives Schwachstellenmanagement beginnt und endet nicht mit dem Scannen. Um effektiv zu sein, erfordert das Schwachstellenmanagement ein fundiertes Verständnis sowohl der Scanner-Technologie als auch Ihrer IT-Infrastruktur. Operativ hängt das Schwachstellenmanagement von zuverlässigen und wiederholbaren Prozessen, klar definierten Zuständigkeiten, der Integration in den täglichen IT-Betrieb und einer strategischen Steuerung ab.

Jede Organisation befindet sich in einer anderen Reifestufe des Schwachstellenmanagements. Einige beginnen gerade erst mit der Einführung von Schwachstellenscans. Andere haben zwar operative Prozesse etabliert, es fehlt ihnen jedoch an einer strukturierten Priorisierung, einer Nachverfolgung von Abhilfemaßnahmen oder der Ausrichtung auf das Unternehmen. Die am weitesten fortgeschrittenen Organisationen betrachten das Schwachstellenmanagement als eine wesentliche Sicherheitsmaßnahme zur Minderung der Gefährdung durch neu auftretende Bedrohungen und zur Reduzierung des gesamten Geschäftsrisikos.

Ein Reifegradmodell für das Schwachstellenmanagement bietet einen strukturierten Ansatz zur Bewertung des aktuellen Zustands des Programms in Ihrem Unternehmen. Es hilft den Verantwortlichen aus den Bereichen Sicherheit, IT und Geschäft, zu verstehen, wo ihre Sicherheitslage derzeit steht, identifiziert „Hindernisse“, die den Fortschritt einschränken, und definiert die nächsten Schritte hin zu einem effektiveren und nachhaltigeren Schwachstellenmanagementprozess.

In diesem Artikel werden wir ein strukturiertes Modell zur Definition der Reife im Schwachstellenmanagement (VM) betrachten. Das Modell definiert fünf Reifegrade und erläutert, wie Sie ermitteln können, wo sich Ihr Unternehmen innerhalb des Modells befindet. Es beschreibt außerdem die Einschränkungen, die jeder Reifegrad für eine widerstandsfähige operative Cybersicherheit mit sich bringt.

Die 5 Stufen der Reife im Schwachstellenmanagement verstehen

Die Reife im Schwachstellenmanagement lässt sich in fünf Stufen unterteilen. Jede Stufe spiegelt einen unterschiedlichen Stand in Bezug auf Disziplin, operative Fähigkeiten, organisatorische Einbindung und Reife der Governance wider. Unternehmen entwickeln sich in der Regel von einfachen technischen Scans hin zu einem risikoorientierten Sicherheitsprogramm, das in den IT-Betrieb integriert ist und kontinuierlich auf der Grundlage messbarer KPI-Ergebnisse verbessert wird.

Stufe 1 – Ad-hoc

In der Ad-hoc-Stufe ist das Schwachstellenmanagement für eine Organisation in der Regel eine völlig neue Aktivität oder wird nur sporadisch durchgeführt. Scans werden nicht formell geplant, und es gibt keine dokumentierten Sicherheitsprozesse. Das Unternehmen verfügt möglicherweise über ein Scan-Tool, doch der Erfassungsgrad der Scans wird nicht gemessen, und die Ergebnisse werden nicht systematisch zur Einleitung von Abhilfemaßnahmen genutzt.

Die informelle Einstellung in dieser Phase lautet oft: „Wir werden es schon irgendwie scannen.“ Auch wenn diese Haltung und der reine Aufwand zunächst für etwas Transparenz sorgen mögen, stellen sie kein zuverlässiges Schwachstellenmanagementprogramm dar.

Die Grenzen eines ad-hoc / anfänglichen Sicherheitsprogramms

Die größte Einschränkung in dieser Phase ist das Fehlen einer Struktur. Ohne eine vollständige Bestandsaufnahme der Assets weiß ein Unternehmen nicht, ob kritische Systeme gescannt werden. Ohne einen definierten Umfang oder Zeitplan bleiben Scan-Aktivitäten eine Nebensache. Ohne klare Zuständigkeiten werden entdeckte Schwachstellen möglicherweise nicht an die richtigen Teams zur Behebung weitergeleitet.

Zu den häufigen Einschränkungen gehören:

  • Keine vollständige Bestandsaufnahme der IT-Ressourcen
  • Kein definierter Scan-Umfang oder Zeitplan
  • Keine Zuständigkeiten oder Verantwortlichkeiten
  • Keine Berichterstattung oder KPIs
  • Kein strukturierter Behebungsprozess

Stufe 2 – Wiederholbar / Operativ

In der wiederholbaren / operativen Phase ist das Schwachstellenscannen konsistenter. Es werden regelmäßige Scans durchgeführt, eine grundlegende Betriebsstabilität ist gegeben, und das Unternehmen verfügt über einen ersten Überblick über Schwachstellen in einem Teil seiner Umgebung. Diese Stufe stellt einen wichtigen Übergang von informellen Aktivitäten zu einer wiederholbaren Durchführung dar. Ein Unternehmen führt nun zuverlässig und wiederkehrend Scans durch, und einige Verantwortlichkeiten für das Schwachstellenmanagementprogramm wurden zugewiesen, beispielsweise an einen Administrator oder technischen Verantwortlichen.

Eine Organisation führt zwar möglicherweise regelmäßig Systemscans durch, hat jedoch noch keinen vollständig verwalteten Prozess für die Prüfung, Priorisierung, Nachverfolgung und Behebung von Schwachstellen etabliert.

Die Grenzen eines wiederholbaren / operativen Sicherheitsprogramms

Diese wiederholbare / operative Phase ist nach wie vor vorwiegend technischer Natur. Die größte Einschränkung in dieser Phase besteht darin, dass Schwachstellendaten noch nicht effektiv über einen strukturierten Lebenszyklus hinweg verwaltet werden. Organisationen wissen, wo Schwachstellen bestehen, verfügen jedoch nicht über einen formellen Prozess zur Entscheidung, welche Probleme am wichtigsten sind, wer sie beheben soll und bis wann. Die Steuerung beschränkt sich auf eine grundlegende Berichterstattung ohne KPI-gesteuertes Management oder formelle Leistungsziele.

Zu den üblichen Einschränkungen gehören:

  • Keine strukturierte Priorisierung
  • Keine definierten SLAs für die Behebung
  • Begrenzte Nachverfolgung der Behebung
  • Schwache teamübergreifende Zusammenarbeit

Stufe 3 – Definiert / Verwaltet

In der definierten / verwalteten Phase wird das Schwachstellenmanagement strukturiert und messbar. Ein Unternehmen hat Prozesse zur Identifizierung, Priorisierung, Behebung und Nachverfolgung von Schwachstellen etabliert. Die Verantwortlichkeiten sind klar auf die relevanten Beteiligten verteilt, einschließlich IT- und Sicherheitsteams. Diese Stufe markiert den Punkt, an dem das Schwachstellenmanagement zu einem gesteuerten operativen Prozess wird und nicht mehr nur eine Scan-Aktivität ist.

Ein Unternehmen in dieser Phase nutzt KPIs zur Messung der Leistung, wendet risikobasierte Priorisierung an und folgt klar definierten Workflows zur Behebung. Die Scan-Abdeckung wird überprüft, und es werden authentifizierte Scans zur mehrschichtigen Verteidigung durchgeführt.

Ein Programm der Stufe 3 kann wichtige Fragen des Managements beantworten: Welche Schwachstellen sind am wichtigsten? Wer ist für die Behebung zuständig? Wie lange dauert die Behebung? Erreichen die Teams die definierten Ziele? Wo treten wiederkehrende Probleme auf?

Die Grenzen eines definierten / verwalteten Sicherheitsprogramms

Ein Programm auf dieser Stufe ist strukturiert, jedoch weder automatisiert noch tiefgreifend integriert. Die Prozesse sind dokumentiert und messbar, doch die Ausführung hängt nach wie vor weitgehend von manueller Koordination ab. Eine Integration der Scan-Infrastruktur in den IT-Betrieb, das Ticketing, das Patch-Management oder das Änderungsmanagement fehlt gänzlich oder ist unvollständig.

Zu den üblichen Einschränkungen zählen:

  • Begrenzte Automatisierung
  • Schwache Integration in IT-Prozesse
  • Begrenzte Ausrichtung auf das Geschäft

Stufe 4 – Integriert / Kontrolliert

In der Stufe „Integriert / Kontrolliert“ ist das Schwachstellenmanagement fest in den IT-Betrieb integriert. Das Programm wird nicht mehr als separate Sicherheitsmaßnahme verwaltet, sondern ist in die operativen Systeme und Arbeitsabläufe eingebunden, die Infrastruktur, Anwendungen, Patching, Änderungsmanagement, Incident Response und Servicemanagement steuern.

Die Prozesse in dieser Stufe sind automatisiert und skalierbar. Schwachstellenfunde können in Tickets umgewandelt, den richtigen Verantwortlichen zugewiesen, bis zur Behebung nachverfolgt und anhand definierter Ziele gemessen werden. Integrationen mit ITSM, SIEM, Patch-Management und verwandten Betriebssystemen ermöglichen durchgängige Transparenz und Kontrolle. Insgesamt kann ein Unternehmen die Behebung von Schwachstellen konsistenter, verantwortungsbewusster und betrieblich effizienter verwalten.

Die Grenzen eines integrierten / kontrollierten Sicherheitsprogramms

Die größte Einschränkung in dieser Phase ist das Fehlen einer strategischen Optimierung. Ein Unternehmen verfügt über starke Prozesse und Integrationen, nutzt jedoch die Daten aus dem Schwachstellenmanagement nicht als Rückmeldung für die langfristige strategische Planung, Investitionsplanung oder kontinuierliche Optimierung.

Zu den häufigen Einschränkungen gehören:

  • Begrenzte strategische Steuerung
  • Optimierungspotenzial wird nicht voll ausgeschöpft

Stufe 5 – Optimiert / Strategisch

In der Optimierten / Strategischen Phase ist das Schwachstellenmanagement risikogesteuert, wird kontinuierlich verbessert und ist strategisch auf die Geschäftsziele abgestimmt. Eine Organisation betrachtet Schwachstellen nicht nur als technische Mängel, sondern bewertet sie im Kontext von Geschäftsrisiken, der Kritikalität von Systemen, der Bedrohungslage, den betrieblichen Auswirkungen und der Sicherheitsstrategie.

Kontinuierliche Verbesserung ist auf dieser Ebene fest in die Programme integriert. Metriken, Daten zur Behebung, wiederkehrende Schwachstellenmuster, die Behandlung von Ausnahmen sowie Risikobewertungen werden genutzt, um den Schwachstellenmanagement-Prozess im Laufe der Zeit zu verfeinern. Das Schwachstellenmanagement wird Teil einer umfassenderen Sicherheits-Governance und Risikomanagement-Fähigkeit.

Die Grenzen eines optimierten / strategischen Sicherheitsprogramms

Auf dieser Reifegradstufe gibt es in der Regel keine größeren strukturellen Lücken. Das Programm ist stabil, integriert, gesteuert und strategisch ausgerichtet. Verbleibende Einschränkungen werden eher als Optimierungsmöglichkeiten denn als grundlegende Schwächen betrachtet.

Häufige Optimierungsbereiche können sein:

  • Verfeinerung von Risikomodellen
  • Verbesserung der Automatisierungsgenauigkeit
  • Stärkung des geschäftlichen Kontexts
  • Verringerung von Reibungsverlusten bei der Behebung
  • Verbesserung der prädiktiven und trendbasierten Analyse

Zusammenfassung

Bei der Reife des Schwachstellenmanagements geht es um weit mehr als nur darum, ob eine Organisation über ein Scan-Tool verfügt und wie oft Scans durchgeführt werden. Während Organisationen von der Ad-hoc-Reife zu einem optimierten / strategischen Schwachstellenmanagement-Programm entwickeln, wandelt sich der Prozess von einem technischen zu einer strategischen Sicherheitskompetenz.

Im Kern wird die Reife des Schwachstellenmanagements dadurch definiert, wie konsequent eine Organisation Schwachstellen identifizieren, diese anhand des Risikos priorisieren, Verantwortlichkeiten zuweisen, die Behebung nachverfolgen, die Leistung messen und den Prozess im Laufe der Zeit verbessern kann. Ein unreifes Programm bietet gelegentliche Transparenz, kann jedoch nicht zuverlässig garantieren, dass das Risiko auf ein akzeptables Niveau reduziert wird. Ein hoch ausgereiftes Programm verbindet Technologie, Prozesse, Organisation und Governance zu einem kontrollierten Lebenszyklus.

Sobald eine Organisation ihren aktuellen Reifegrad versteht, kann sie praktische nächste Schritte planen. Die Abdeckung der Assets wird sich verbessern, Standards und Prozesse werden von den Beteiligten gut verstanden, und klar definierte Verantwortlichkeiten sowie SLAs sorgen für zuverlässige und effektive Ergebnisse. Das Gesamtergebnis ist eine strategische Reduzierung des Geschäftsrisikos.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Greenbone AG

Cyber Resilience Act und Open-Source-Software: Was Softwareanbieter und -verwalter wissen müssen

Update — 27. Juli 2026

Die Europäische Kommission hat ihre Leitlinien zur Anwendung des CRA auf Open-Source-Software verabschiedet (Mitteilung C(2026) 5252 und Anhang) – bei der Erstveröffentlichung dieses Beitrags lag hierzu noch ein Entwurf vor. Wir haben den Beitrag entsprechend aktualisiert: Für die „gewerbliche Tätigkeit“ ist jetzt entscheidend, ob der Zugang zur Software selbst, einschließlich ihrer Wartung, an eine Zahlung geknüpft ist – nicht, ob daneben kostenpflichtige Dienstleistungen verkauft werden. Die Leitlinien legen zudem fest, was überhaupt als FOSS gilt, und konkretisieren Frist und Umfang der Meldepflichten für Open-Source-Software-Verwalter gemäß Artikel 24 Absatz 3.

Der Geltungsbereich des CRA für Open-Source-Software (OSS) war einer der umstrittensten Teile der Verordnung. Die OSS-Community äußerte während des Gesetzgebungsverfahrens berechtigte Bedenken, beispielsweise wie die Herstellerpflichten auf nichtkommerzielle, von Freiwilligen getragene Projekte anzuwenden seien. Die endgültige Verordnung bietet eine Antwort, wobei die Überzeugungskraft dieser Antwort davon abhängt, wen man fragt. Die Europäische Kommission (EK) klärt die Details seit März 2026 durch ihre Leitlinien und hat deren Inhalt am 27. Juli 2026 verabschiedet.

Für Unternehmen wie Greenbone, die sowohl ein Open-Source-Projekt (OPENVAS) betreuen als auch darauf aufbauende kommerzielle Produkte verkaufen, ist die Antwort klar: Für den kommerziellen Bereich gelten die vollständigen Herstellerpflichten, während für die Aktivitäten der Open-Source-Community die Pflichten des Projektbetreibers gelten. Es ist wichtig zu wissen, wo diese Grenzen verlaufen.

Open Source & CRA

Der dreistufige Ansatz des CRA für Open-Source-Software

Stufe 1: Nichtkommerzielle Open-Source-Projekte und ihre Mitwirkenden (außerhalb des Geltungsbereichs)

Freie und Open-Source-Software (FOSS), die in einem rein nichtkommerziellen Kontext entwickelt und verbreitet wird (d. h. Freiwillige, die Software erstellen und frei weitergeben, ohne kommerzielle Absicht oder Unterstützungsmodell), begründet keine CRA-Verpflichtungen für ihren Urheber oder Vertreiber. Nur FOSS, die im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird, fällt in den Geltungsbereich, und die Leitlinien der Europäischen Kommission bestätigen, dass die bloße Bereitstellung von nicht monetarisierter FOSS keine kommerzielle Tätigkeit darstellt.

Allerdings ist der Begriff „nichtkommerziell“ möglicherweise immer noch enger definiert, als viele Projekte annehmen. Das Annehmen von Spenden macht ein Projekt nicht automatisch zu einer kommerziellen Aktivität. In Erwägungsgrund 15 der Verordnung (EU) 2024/2847 heißt es jedoch, dass „das Annehmen von Spenden, die die mit der Konzeption, Entwicklung und Bereitstellung verbundenen Kosten übersteigen“, eine kommerzielle Tätigkeit darstellt. Die Leitlinien der Europäischen Kommission zum CRA und Erwägungsgrund 18 der Verordnung (EU) 2024/2847 legen zudem fest, dass der CRA nicht für Einzelpersonen oder Unternehmen gilt, die lediglich Quellcode zu FOSS-Projekten beitragen, für die sie nicht verantwortlich sind.

Stufe 2: Open-Source-Software-Stewards (geringere Verpflichtungen)

Der CRA führt die rechtliche Definition eines „Open-Source-Software-Stewards“ ein: eine juristische Person, die die Entwicklung von Open-Source-Produkten, die für kommerzielle Tätigkeiten bestimmt sind, nachhaltig und systematisch unterstützt oder die Lebensfähigkeit dieser Produkte sicherstellt. Dies umfasst Software-Stiftungen,

Industriekonsortien und Unternehmen, die OSS-Projekte pflegen und unterstützen, die von anderen kommerziell genutzt werden. Eine natürliche Person gilt gemäß Artikel 3 Absatz 14 der Verordnung (EU) 2024/2847 nicht als OSS-Verwalter.

Verwalter unterliegen nicht denselben Verpflichtungen wie Hersteller. Ihre Verpflichtungen sind geringer als die vollständigen Anforderungen an Hersteller: keine CE-Kennzeichnung, keine formelle Konformitätsbewertung, keine Aufbewahrungspflicht für technische Unterlagen. Gemäß Artikel 24 der Verordnung (EU) 2024/2847 müssen Open-Source-Software-Verwalter jedoch weiterhin:

  • eine Cybersicherheitsrichtlinie aufrechterhalten, die die sichere Entwicklung der von ihnen unterstützten OSS-Produkte fördert
  • mit den Marktüberwachungsbehörden zusammenarbeiten und Sicherheitsdokumentation auf Anfrage zur Verfügung stellen
  • ab dem 11. September 2026 aktiv ausgenutzte Schwachstellen nach demselben Zeitplan wie Hersteller melden – Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, Abschlussbericht innerhalb von 14 Tagen –, soweit der Steward an der Entwicklung des Produkts beteiligt ist (Artikel 24 Absatz 3)
  • schwerwiegende Sicherheitsvorfälle melden, allerdings nur solche, die die Netzwerk- und Informationssysteme betreffen, die der Steward selbst für die Entwicklung des Produkts bereitstellt (Artikel 24 Absatz 3)
  • Schwachstellen wirksam beheben und sicherstellen, dass sie den Nutzern ohne unangemessene Verzögerung zugänglich sind
  • eine Richtlinie festlegen, die die freiwillige Meldung von Schwachstellen durch die Entwickler des Softwareprodukts fördert

Stewards sind zudem gemäß Artikel 64 Absatz 10 von Bußgeldern für Verstöße gegen den CRA befreit. Die Durchsetzung erfolgt durch Zusammenarbeit und Abhilfemaßnahmen statt durch finanzielle Sanktionen.

Stufe 3: Kommerzielle OSS-Anbieter (vollständige Herstellerpflichten)

Wenn eine natürliche Person oder eine juristische Person (z. B. ein Unternehmen oder eine andere Art von Organisation) OSS entwickelt und vertreibt und diese im Rahmen einer gewerblichen Tätigkeit auf dem EU-Markt in Verkehr bringt, gilt sie gemäß des CRA als Hersteller. Der Schwellenwert des CRA für „gewerbliche Tätigkeit“ ist weit gefasst, doch die Leitlinien benennen das entscheidende Kriterium: ob der Zugang zur Software selbst, einschließlich ihrer Wartung, an eine Zahlung geknüpft ist – nicht, ob begleitend Dienstleistungen verkauft werden. SLA-gestütztes Hosting oder eine kostenpflichtige Edition, die den Zugang zur Software selbst beschränkt, stellt eine gewerbliche Tätigkeit dar; optionaler kostenpflichtiger Support rund um eine ansonsten frei verfügbare Software in der Regel nicht. Für Hersteller gelten alle Anforderungen aus Anhang I: „Secure-by-Default“-Design, Umgang mit Sicherheitslücken, 24-Stunden-Meldung von Vorfällen, SBOM, technische Dokumentation und CE-Kennzeichnung.

Hersteller bleiben für den Umgang mit Sicherheitslücken in ihren eigenen Produkten verantwortlich, einschließlich solcher, die durch integrierte OSS-Komponenten von Drittanbietern verursacht werden. (EU) 2024/2847, Artikel 13 legt fest, dass Hersteller bei der Integration von Komponenten von Drittanbietern gebotene Sorgfalt walten lassen müssen. Bei Feststellung einer Sicherheitslücke in einer integrierten Komponente, einschließlich einer FOSS-/OSS-Komponente, müssen sie die Sicherheitslücke der Person oder Stelle melden, die diese Komponente herstellt oder wartet, und die Sicherheitslücke unverzüglich gemäß (EU) 2024/2847 Anhang I, Teil II beheben.

Der Cyber Resilience Act fordert regelmäßige Schwachstellenanalysen und externe Audits – kontinuierlich und nachhaltig.

OPENVAS SECURITY INTELLIGENCE unterstützt Sie bei der CRA-Compliance – on premises oder in der Cloud. Kontaktieren Sie uns und erfahren Sie mehr.

➜ CRA-Compliance gemeinsam erreichen

Die Leitlinien der Europäischen Kommission zum CRA: Was wir derzeit wissen

Die öffentliche Konsultation zum Leitlinienentwurf der Europäischen Kommission lief vom 3. März bis zum 13. April 2026. Am 27. Juli 2026 verabschiedete die Europäische Kommission den Inhalt ihrer Leitlinien zur Anwendung des CRA (Mitteilung C(2026) 5252 und deren Anhang). Die Leitlinien sind rechtlich nicht bindend und gelten formal, sobald alle EU-Sprachfassungen angenommen sind; einige Grenzfälle bleiben auslegungsbedürftig, aber es handelt sich nicht mehr um einen Entwurf. In ihren Leitlinien liefert die Europäische Kommission Klarstellungen zur Definition des Begriffs „gewerbliche Tätigkeit“ und dazu, was als FOSS gilt, und geht auf weitere wichtige Fragen zum Anwendungsbereich ein.

Zu den wichtigsten Klarstellungen gehören:

  • Ein Produkt kann kostenlos und Open-Source sein und dennoch als „auf dem Markt bereitgestellt“ gelten, wenn es auch als Teil einer kommerziellen Dienstleistung oder eines monetarisierten Supportmodells angeboten wird
  • Das bloße Vorhandensein öffentlich zugänglichen Codes, beispielsweise in einem GitHub-Repository, stellt noch kein Inverkehrbringen dar; erst eine kommerzielle Beziehung begründet eine Verantwortung
  • Bei Dual-Lizenz-Modellen (kostenlose OSS-Edition + kommerzielle Enterprise-Edition) fällt die kommerzielle Edition eindeutig in den Geltungsbereich des CRA; der Status der kostenlosen Edition hängt zudem von ihrer Verbindung zu einer kommerziellen Tätigkeit ab
  • Die Verantwortung folgt der Governance: Wer ein Projekt veröffentlicht und effektiv kontrolliert, trägt die Verpflichtungen, nicht derjenige, der Änderungen am Quellcode der Software technisch bereitstellt
  • Die Herstellerverantwortung erstreckt sich auch über den ursprünglichen Entwickler hinaus auf Unternehmen, die OSS-Komponenten in Produkte integrieren oder unter eigenem Markennamen vertreiben, die auf dem EU-Markt in Verkehr gebracht werden
  • Um überhaupt als FOSS zu gelten, muss Software zwei kumulative Bedingungen erfüllen: eine Lizenz, die die vollständigen Rechte zum Zugriff, zur Nutzung, Veränderung und Weitergabe gewährt, und einen Quellcode, der tatsächlich offen zugänglich ist – nicht nur zahlenden Kunden oder einem begrenzten Personenkreis vorbehalten

Meldungen im September: Die Uhr tickt

Die erste verbindliche CRA-Frist gilt für alle Produkte mit digitalen Elementen, einschließlich OSS. Ab dem 11. September 2026 müssen Hersteller und Verwalter aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden, die die Sicherheit der digitalen Produkte beeinträchtigen könnten, für die sie verantwortlich sind.

Die Meldefristen sind knapp bemessen: Eine Frühwarnung muss innerhalb von 24 Stunden nach Bekanntwerden erfolgen, eine vollständige Meldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb von 14 Tagen bei ausgenutzten Schwachstellen bzw. innerhalb eines Monats bei schwerwiegenden Vorfällen. Die Meldungen werden über die Single Reporting Platform (SRP) der ENISA eingereicht; Anleitungen zur Registrierung und Einbindung werden von der ENISA seit dem 31. Juli 2026 schrittweise veröffentlicht, die Plattform selbst soll bis zum 11. September 2026 den Betrieb aufnehmen.

Was das für Greenbone bedeutet

Greenbone ist auf zwei Ebenen tätig: als Hersteller digitaler Produkte und als Open-Source-Software-Steward. Wie oben erläutert, erlegt der CRA für beide Rollen unterschiedliche Verpflichtungen auf. Als Hersteller ist Greenbone für die kommerzialisierten OPENVAS-IT-Sicherheitsprodukte für Unternehmen verantwortlich, und als Steward übernehmen wir die Verantwortung für unsere FOSS-Community-Projekte.

Greenbone kommt seinen Verpflichtungen als Hersteller durch eine breite Palette von IT-Sicherheitsrichtlinien, Kontrollmaßnahmen und Notfallplänen nach. Dazu gehören ein kontinuierliches Schwachstellenmanagement, eine DSGVO-konforme Architektur, dokumentierte Sicherheitsverfahren sowie weitere bewährte Praktiken im Bereich der IT-Sicherheit. Als aktiv nach ISO/IEC 27001:2022 und ISO 9001:2015 zertifiziertes Unternehmen hat sich Greenbone den strengsten Qualitätsstandards für Informationssicherheit verschrieben. Als OSS-Steward ist Greenbone darauf vorbereitet, die CRA-Anforderungen für unsere OPENVAS-Community-Softwareprojekte zu erfüllen.

Schließlich nutzen die Kunden von Greenbone – als Anbieter digitaler Produkte speziell für die Cybersicherheit – unsere OPENVAS-Produktreihe für IT-Sicherheit, um ihre eigenen CRA-Verpflichtungen zu erfüllen. Das bedeutet, dass wir nicht nur für die Erfüllung unserer eigenen CRA-Verpflichtungen verantwortlich sind, sondern auch dafür, die technischen Anforderungen zu verstehen, die andere Organisationen erfüllen müssen, um konform zu bleiben. Diese Doppelrolle als Hersteller digitaler Produkte und als Anbieter von Cybersicherheitsprodukten, die anderen Organisationen dabei helfen, die CRA-Konformität zu erreichen, verschafft Greenbone einen klaren Vorteil: Wir können uns in der Regulierung zurechtfinden und gleichzeitig globale Hersteller digitaler Produkte umfassend dabei unterstützen, dasselbe zu tun.

Sind Sie bereit für den Cyber Resilience Act?

CRA-konforme Schwachstellenanalysen und Audits – OPENVAS SECURITY INTELLIGENCE begleitet Sie on premises oder in der Cloud auf dem Weg zur Compliance.

➜ Jetzt Beratung anfragen

Empfehlungen für Softwareanbieter, die mit Open Source arbeiten

  1. Erfassen Sie Ihre OSS-Nutzung. Jede Open-Source-Komponente in Ihren Produkten muss identifiziert, dokumentiert und nachverfolgt werden. Dies bildet die Grundlage Ihrer SBOM und wird von der CRA unabhängig vom eigenen Compliance-Status der Komponente verlangt.
  2. Überprüfen Sie Ihre Geschäftsbeziehungen. Wenn Sie OSS in irgendeiner Weise monetarisieren, beispielsweise durch kostenpflichtigen Support, SaaS-Bereitstellung oder professionelle Dienstleistungen, sollten Sie rechtlichen Rat einholen, ob die vollständigen Herstellerpflichten gelten. Der Monetarisierungstest in den Leitlinien ist der richtige Ausgangspunkt.
  3. Bereiten Sie sich jetzt auf die Berichterstattung im September vor. Richten Sie einen internen Prozess ein, der eine Frühwarnung innerhalb von 24 Stunden auslösen kann – die Registrierungs- und Einbindungsanleitungen der ENISA für das SRP sind seit dem 31. Juli 2026 verfügbar.
  4. Tauschen Sie sich mit der Community aus. Die ORC-Arbeitsgruppe unterhält eine CRA-FAQ und eine Ressourcenplattform für OSS-Verwalter und -Hersteller (cra.orcwg.org und den CRA-Hub auf GitHub). Auch die OpenSSF verfolgt die Entwicklungen im Bereich der CRA-Richtlinien.
  5. Prüfen Sie die Leitlinien der Europäischen Kommission. Die Kommission hat ihre Leitlinien zur Anwendung des CRA am 27. Juli 2026 verabschiedet (Mitteilung C(2026) 5252 und Anhang) – wer seinen CRA-Status anhand des März-Entwurfs beurteilt hat, sollte diese Einschätzung anhand der finalen Fassung überprüfen, insbesondere die Tests zum FOSS-Status und zur gewerblichen Tätigkeit.

Lesen Sie den vollständigen Leitfaden: Der umfassende Leitfaden zum EU-Cyber-Resilience-Gesetz – alle Anforderungen, Fristen und Sanktionen auf einen Blick.

1. Quellen Europäische Kommission – Cyber Resilience Act (Verordnung (EU) 2024/2847), Amtsblatt https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
2. Europäische Kommission – Seite zu CRA und Open-Source-Software-Politik
https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
3. Europäische Kommission – Ankündigung des Leitlinienentwurfs (3. März 2026)
https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act
4. Europäische Kommission – CRA-Meldepflichten
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
5. ENISA – Einheitliche Meldeplattform (SRP)
https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
6. ORC-Arbeitsgruppe der Eclipse Foundation — orcwg.org
https://orcwg.org/
7. ORC-Arbeitsgruppe – CRA Hub (FAQ und Ressourcen zur Implementierung)
https://github.com/orcwg/cra-hub
8. ORC-Arbeitsgruppe – Whitepaper: Open-Source-Software-Stewards und der CRA
https://orcwg.org/cra/resources/d3-5-white-paper-on-open-source-software-stewards-and-cra/
9. OpenSSF – Seite zu den politischen Leitlinien des EU-Gesetzes zur Cyber-Resilienz
https://openssf.org/public-policy/eu-cyber-resilience-act/
10. OpenSSF – CRA-Tracker der Global Cyber Policy Working Group
https://policy.openssf.org/CRA/
11. Europäische Kommission – Mitteilung C(2026) 5252 und Anhang: Leitlinien zur Anwendung des Cyber Resilience Act (27. Juli 2026)
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Joseph Lee

Mai 2026 Threat Report: Verstärkte Systemüberprüfung und Patching

Die Ausnutzung von Schwachstellen hat sich mittlerweile als häufigste Methode etabliert, mit der Angreifer sich zunächst Zugang zur Umgebung eines Unternehmens verschaffen. Das zeigt, wie wichtig es nach wie vor ist, die Grundlagen richtig zu machen.

— Verizon Data Breach Investigations Report 2026

CVE-2025-20393-cisco-spam-filter

Die Industrialisierung der Schwachstellenausnutzung ist nicht neu; der prozessgesteuerte Ansatz zur Instrumentalisierung von Schwachstellen existiert seit Langem, lange vor LLMs. Doch ausgefeilte Cybersicherheitsfähigkeiten stehen heute fast jedem zur Verfügung, der einen Laptop hat. Anthropic hat inzwischen den ersten offiziellen Wirkungsbericht zu Mythos veröffentlicht [1][2]. Die Ergebnisse deuten darauf hin, dass die Auswirkungen für Softwareanbieter und Verteidiger spürbar sein werden, auch wenn Perfektion noch unerreicht bleibt.

Im April und Mai 2026 bestätigten große Softwareanbieter [3][4][5], Anbieter von Sicherheitsinformationen [6][7][8] und Cybersicherheits-Nachrichtenportale [9] die Auswirkungen von Mythos auf die Offenlegung von Schwachstellen. Sicherheitsforscher von Mozilla schrieben, es sei „kaum zu überschätzen, wie sehr sich diese Dynamik für uns innerhalb weniger Monate verändert hat“. Cisco wies auf den Mangel an nachgelagerter Unterstützung für die Offenlegung der bevorstehenden Flut neuer Probleme hin. In Kombination mit dem einleitenden DBIR-Zitat ist die Schlussfolgerung klar: Sicherheitsverantwortliche müssen stärker auf kontinuierliches Schwachstellenmanagement und Patch-Performance setzen, um kritische Risiken zu reduzieren.

Cisco veröffentlicht zwei CVSS-10-Schwachstellen – Catalyst SD-WAN wird aktiv ausgenutzt

Im Mai 2026 wurden zwei neue Schwachstellen mit maximalem Schweregrad für Cisco-Produkte bekannt. CVE-2026-20182 in Cisco Catalyst SD-WAN wird aktiv ausgenutzt; die CISA hat die Schwachstelle in ihre KEV-Liste aufgenommen und die Leitlinien zu Angriffen auf Catalyst SD-WAN aktualisiert. Sechs weitere CVEs in Catalyst SD-WAN wurden 2026 ebenfalls in die CISA-KEV-Liste aufgenommen. Die zweite neue Schwachstelle mit maximalem Schweregrad aus dem Mai 2026 ist CVE-2026-20223 in Cisco Secure Workload.

Für CVE-2026-20182 wurden zahlreiche nationale CERT-Warnungen herausgegeben [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18]; für CVE-2026-20223 ebenfalls [1][2][3][4][5][6][7][8][9][10][11]. Details:

  • CVE-2026-20182 (CVSS 10, EPSS >= 99. Perzentil): Eine Schwachstelle in der Peering-Authentifizierung des Cisco Catalyst SD-WAN Controllers und Managers ermöglicht einem nicht authentifizierten Angreifer aus der Ferne, die Authentifizierung zu umgehen (CWE-287) und sich als interner Administrator anzumelden. Mit dem gekaperten Konto kann ein Angreifer auf NETCONF zugreifen und SD-WAN-Fabric Netzwerkkonfigurationen Ausnutzung ist über HTTP-Anfragen möglich. Weitere Informationen in der offiziellen Sicherheitsmitteilung von Cisco.
  • CVE-2026-20223 (CVSS 10): Fehlende Authentifizierung (CWE-306) in den REST-APIs von Cisco Secure Workload ermöglicht einem nicht authentifizierten Angreifer aus der Ferne, mit Site-Admin-Rechten auf Site-Ressourcen zuzugreifen. Angreifer können manipulierte HTTP-API-Anfragen nutzen, um sensible Informationen auszulesen und Konfigurationsänderungen über Mandantengrenzen hinweg vorzunehmen. Weitere Informationen im offiziellen Advisory von Cisco.

Cisco gibt an, dass es für keine der beiden Schwachstellen Workarounds gibt. Zur vollständigen Behebung müssen Patches installiert werden. Der OPENVAS ENTERPRISE FEED umfasst die Erkennung von CVE-2026-20182 und CVE-2026-20223 sowie die Erkennung weiterer CVEs für Cisco-Produkte, die im Mai 2026 veröffentlicht wurden.

Trend Micro Apex One: Schwachstelle von Februar 2026 wird aktiv ausgenutzt

CVE-2026-34926, das Trend Micro Apex One 2019 betrifft, wird als aktiv ausgenutzt gemeldet und wurde in die KEV-Liste der CISA aufgenommen. Trend Micro veröffentlichte im Februar 2026 einen kritischen Patch KA-0022458 für diese CVE sowie für zwei weitere kritische Schwachstellen. Der Patch verbesserte auch den Schutz vor CVE-2025-54948 (CVSS 9,8) [1] und CVE-2025-54987 (CVSS 9,8) [2], die beide Mitte 2025 in die CISA-KEV-Liste aufgenommen wurden. Am 3. März 2026 veröffentlichte der Anbieter Updates für CVE-2025-71210 (CVSS 9,8) und CVE-2025-71211 (CVSS 9,8) [3][4], die nicht authentifizierten Angreifern aus der Ferne beliebige Codeausführung auf betroffenen Installationen ermöglichen.

Die aktiv ausgenutzte CVE-2026-34926 (CVSS 6,7) ist eine Verzeichnisüberquerungsschwachstelle (CWE-23) im Apex One 2019 On-Premise-Server und in Server- und Agent-Builds unter 17079, in Apex One as a Service (SaaS) sowie in Trend Vision One Endpoint für Windows. Die Schwachstelle erlaubt einem Angreifer, eine Schlüsseltabelle auf dem Server zu ändern, bösartigen Code einzuschleusen und auf Agenten zu verteilen. Voraussetzung ist Windows-Administratorzugriff auf den Apex One-Server; eine Authentifizierung bei Apex One selbst ist nicht erforderlich.

Der OPENVAS ENTERPRISE FEED von Greenbone enthält regelmäßige Windows-Erkennungen für Trend Micro-Sicherheitshinweise sowie zusätzliche Erkennungen für KA-0022458-CVEs, die am Tag nach ihrer Veröffentlichung im Februar 2026 verfügbar waren.

Living on the Edge: Neue Bedrohungen für IT-Peripheriegeräte

Laut dem Verizon DBIR 2026 ist die Ausnutzung von Schwachstellen die häufigste Methode, mit der Angreifer sich ersten Zugriff auf die Umgebung eines Unternehmens verschaffen. Das verdeutlicht, wie wichtig es ist, anfällige Software zu erkennen und Patches zu installieren. Die folgenden hochriskanten Bedrohungen für IT-Peripheriesysteme wurden im Mai 2026 bekannt.

Palo Alto Networks PAN-OS aktiv ausgenutzt

CVE-2026-0300 (CVSS 9,8, EPSS >= 95. Perzentil) ist eine Pufferüberlauf-Schwachstelle (CWE-787) im User-ID-Authentifizierungsportal (auch bekannt als Captive Portal) der PAN-OS-Software von Palo Alto Networks. Die Schwachstelle wird aktiv ausgenutzt und wurde in die KEV-Liste der CISA aufgenommen. Betroffen sind PAN-OS-Versionen 10.2 bis 12.1.x, darunter Firewalls der PA-Serie und VM-Serie.

Die Schwachstelle erlaubt einem nicht authentifizierten Angreifer, beliebigen Code mit Root-Rechten auf betroffenen Geräten auszuführen. Das Risiko lässt sich erheblich reduzieren, wenn der Zugriff auf vertrauenswürdige interne IP-Adressen beschränkt wird. Zahlreiche nationale CERT-Behörden haben Warnungen herausgegeben [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18]. CISA und Siemens haben zudem Warnungen für Siemens RUGGEDCOM APE1808-Geräte herausgegeben, die durch CVE-2026-0300 gefährdet sind [19][20].

Eine weitere Schwachstelle, CVE-2026-0257 (CVSS 7,8) in PAN-OS GlobalProtect, wurde nach beobachteten Ausnutzungsversuchen ebenfalls in die KEV-Liste der CISA aufgenommen. Palo Alto hat die CVE mit der höchsten Dringlichkeitsstufe bewertet. CVE-2026-0257 betrifft GlobalProtect-Portal und -Gateway und kann einem nicht authentifizierten Angreifer ermöglichen, Sicherheitsbeschränkungen zu umgehen und eine unbefugte VPN-Verbindung herzustellen.

Der OPENVAS ENTERPRISE FEED umfasst Erkennung auf Paketebene für CVE-2026-0300 [21][22] sowie eine umfangreiche Reihe von Schwachstellentests für PAN-OS.

Ivanti EPMM: Drei kritische Schwachstellen, eine davon aktiv ausgenutzt

Ivanti veröffentlichte im Mai 2026 einen Sicherheitshinweis zu neuen CVEs in Endpoint Manager Mobile (EPMM). Drei kritische Schwachstellen erlauben nicht authentifizierten Angreifern aus der Ferne, beliebige Funktionen auf der EPMM-Appliance auszulösen, sich als registrierte Sentry-Hosts auszugeben, gültige CA-signierte Client-Zertifikate zu erlangen oder ein Gerät aus einer eingeschränkten Gruppe nicht registrierter Geräte anzumelden. Die CISA hat eine separate Schwachstelle mit hohem Schweregrad, CVE-2026-6973, in ihre KEV-Liste aufgenommen. Die wichtigsten CVEs:

  • CVE-2026-6973 (CVSS 7,2, EPSS >= 91. Perzentil): Unsachgemäße Eingabevalidierung (CWE-20) erlaubt einem authentifizierten Remote-Benutzer mit Administratorrechten Remote-Code-Ausführung (RCE). CISA hat diese CVE in die KEV-Liste aufgenommen.
  • CVE-2026-5788 (CVSS 9,8): Unsachgemäße Zugriffskontrolle (CWE-284) erlaubt einem nicht authentifizierten Angreifer aus der Ferne, beliebige Methoden aufzurufen.
  • CVE-2026-5787 (CVSS 9,1): Unsachgemäße Zertifikatsvalidierung (CWE-295) erlaubt einem nicht authentifizierten Angreifer aus der Ferne, sich als registrierte Sentry-Hosts auszugeben und gültige CA-signierte Client-Zertifikate zu erhalten.
  • CVE-2026-7821 (CVSS 9,1): Unsachgemäße Zertifikatsvalidierung (CWE-295) erlaubt einem nicht authentifizierten Angreifer aus der Ferne, ein Gerät aus einer eingeschränkten Gruppe nicht registrierter Geräte anzumelden. Eine Ausnutzung kann zur Offenlegung von Informationen über eine EPMM-Appliance führen und die Integrität des neu angemeldeten Geräts beeinträchtigen.

Betroffen sind EPMM-Versionen vor 12.6.1.1, 12.7.0.1 und 12.8.0.1. Für keine der CVEs sind technische Details oder PoC-Exploits öffentlich verfügbar. Ivanti EPMM wurde in den letzten Jahren mehrfach angegriffen und erscheint achtmal auf der CISA-KEV-Liste, zweimal im Zusammenhang mit Ransomware-Angriffen. Greenbone bietet umfassende Schwachstellenerkennung für Ivanti-Produkte.

Mehrere Fortinet-Produkte von kritischen Schwachstellen betroffen

Fortinet veröffentlichte im Mai 2026 mehrere Sicherheitshinweise zu FortiSandbox, FortiOS, FortiAP, FortiAnalyzer, FortiManager und FortiAuthenticator. Darunter sind zwei kritische Schwachstellen: CVE-2026-26083 in FortiSandbox und CVE-2026-44277 in FortiAuthenticator. Beide sind aus der Ferne ausnutzbar und können nicht autorisierten Code oder Befehle ausführen. Es gibt keine Hinweise auf aktive Ausnutzung oder öffentlich verfügbare PoC-Exploits.

  • CVE-2026-26083 (CVSS 9,8): Fehlende Autorisierung (CWE-862) in der FortiSandbox-GUI erlaubt einem nicht authentifizierten Angreifer aus der Ferne RCE über manipulierte HTTP-Anfragen. Betroffen sind FortiSandbox 5.0 und 4.4, FortiSandbox Cloud 24, 23 und 5.0 sowie FortiSandbox PaaS in mehreren Versionen. Nationale CERT-Warnungen [1][2][3][4][5][6][7][8][9].
  • CVE-2026-44277 (CVSS 9,8): Unsachgemäße Zugriffskontrolle (CWE-284) in FortiAuthenticator erlaubt einem nicht authentifizierten Angreifer, über manipulierte Anfragen nicht autorisierten Code oder Befehle auszuführen. FortiAuthenticator Cloud ist nicht betroffen. Betroffen sind FortiAuthenticator 8.0.2, 8.0.0, 6.6.0 bis 6.6.8 sowie 6.5.0 bis 6.5.6. Nationale CERT-Warnungen [10][11][12][13][14][15][16][17].

Betroffene Organisationen sollten die Patches so schnell wie möglich installieren. Der OPENVAS ENTERPRISE FEED umfasst die Erkennung beider Schwachstellen [18][19] sowie eine dedizierte Erkennungsfamilie für Fortinet-Schwachstellen.

Neue SQL-Injection in Drupal Core mit PostgreSQL wird aktiv ausgenutzt

CVE-2026-9082 (CVSS 9,8) ist eine aktiv ausgenutzte [1][2][3] nicht authentifizierte SQL-Injection-Schwachstelle (CWE-89) in Drupal. Eine Ausnutzung kann über bösartige HTTP-Anfragen zu Rechteausweitung und RCE auf einem betroffenen Server führen. Drupal gibt in der offiziellen Sicherheitsmitteilung an, dass CVE-2026-9082 ausschließlich Instanzen mit PostgreSQL-Backend betrifft. Der Anbieter schätzt, dass rund 5 % der Installationen PostgreSQL nutzen.

Für CVE-2026-9082 ist eine vollständige technische Beschreibung mit PoC-Exploit-Code und mindestens einem weiteren PoC öffentlich verfügbar, was das Risiko erhöht. Mehrere nationale CERT-Behörden haben Warnungen herausgegeben [4][5][6][7][8][9][10][11][12][13]. Betroffen sind Drupal-Core-Versionen 8.x bis 11.3.x; Korrekturen sind in den Versionen 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 und 10.4.10 sowie über manuelle Patches für Drupal 9.5 und 8.9 verfügbar. Der OPENVAS ENTERPRISE FEED umfasst Erkennung für Windows- und Linux-Installationen.

vm2-Projekt: Kritische Sicherheitslücken

Im Mai 2026 wurden dreizehn kritische Schwachstellen bekannt, die das vm2-Projekt betreffen. vm2 ist eine Node.js-Sandboxing-Bibliothek zum Ausführen von nicht vertrauenswürdigem JavaScript in einer isolierten Umgebung. Die betroffenen CVEs enthalten mehrere mit maximalem Schweregrad (CVSS 10). Alle Schwachstellen greifen das zentrale Sicherheitsversprechen von vm2 an: die Isolierung von nicht vertrauenswürdigem JavaScript von der zugrunde liegenden Node.js-Hostumgebung. Eine erfolgreiche Ausnutzung kann zu einem Sandbox-Ausbruch und beliebiger Code- oder Betriebssystembefehlsausführung im Kontext des Hostprozesses führen.

Die betroffenen vm2-Versionen variieren je nach CVE. Frühere Probleme wurden in den Versionen 3.10.5, 3.11.0, 3.11.1 oder 3.11.2 behoben; spätere CVEs betreffen bis einschließlich 3.11.3 und wurden in 3.11.4 gepatcht. Nutzer sollten auf 3.11.5 oder höher aktualisieren. Der OPENVAS ENTERPRISE FEED umfasst Erkennung auf Paketebene für alle neuen vm2-CVEs.

Mehrere kritische Schwachstellen in Apache-Softwareprodukten

Im Mai 2026 veröffentlichte die Apache Software Foundation 18 kritische CVEs und 28 weitere Schwachstellen mit hohem Schweregrad. Der OPENVAS ENTERPRISE FEED von Greenbone umfasst die Erkennung aller in diesem Abschnitt genannten Apache-Schwachstellen und vieler weiterer.

Kritische und weitere Schwachstellen mit hohem Schweregrad im Apache HTTP Server

CVE-2026-28780 (CVSS 9,8) und CVE-2026-23918 (CVSS 8,8, EPSS >= 0,77. Perzentil) betreffen den Apache HTTP Server 2.4.66 und frühere Versionen. Beide CVEs sind Speichersicherheitsprobleme.

CVE-2026-28780 ist ein heap-basierter Pufferüberlauf (CWE-122) in mod_proxy_ajp. Für eine Ausnutzung muss der Apache-HTTP-Server über mod_proxy_ajp eine Verbindung zu einem bösartigen AJP-Server herstellen.

CVE-2026-23918 ist eine Double-Free-Schwachstelle (CWE-415) in der HTTP/2-Implementierung. Ruft ein Programm die Funktion free() zweimal mit demselben Argument auf, können Datenstrukturen beschädigt werden, was unerwartete Speicherzugriffe ermöglichen kann. Die Schwachstelle kann während eines frühen Stream-Resets ausgelöst werden und einen Denial-of-Service verursachen; je nach Laufzeitbedingungen ist auch RCE möglich. Apache empfiehlt ein Upgrade auf Apache HTTP Server 2.4.67.

Zwei neue kritische Schwachstellen in Apache MINA

CVE-2026-42778 (CVSS 9,8) und CVE-2026-42779 (CVSS 9,8) sind kritische Deserialisierungsschwachstellen in Apache MINA. Sie können betroffene Anwendungen für nicht authentifizierte RCE anfällig machen, wenn diese Apache MINA zur Deserialisierung von Client-seitig bereitgestellten Java-Klassen nutzen. Beide CVEs betreffen die Zweige Apache MINA 2.1.x und 2.2.x und gehen auf unvollständige oder nicht angewendete Korrekturen früherer Deserialisierungsprobleme zurück.

Drei kritische Schwachstellen in Apache OFBiz

CVE-2026-45434 (CVSS 9,8), CVE-2026-41919 (CVSS 9,1) und CVE-2026-31986 (CVSS 9,1) betreffen Apache OFBiz-Versionen vor 24.09.06 und können betroffene ERP-Bereitstellungen je nach Konfiguration und Angriffspfad für Authentifizierungsumgehung, unbefugten Zugriff oder Codeausführung anfällig machen. CVE-2026-45434 ist das größte Risiko: Die Schwachstelle liegt in einer fehlerhaften Authentifizierungslogik bei der Passwortänderung und kann zu nicht authentifizierter RCE führen.

Drei kritische Schwachstellen in Apache Tomcat

CVE-2026-43512 (CVSS 9,8), CVE-2026-41293 (CVSS 9,8) und CVE-2026-43515 (CVSS 9,1) betreffen Apache Tomcat und können je nach Konfiguration zu Authentifizierungsumgehung oder Autorisierungsfehlern führen.

CVE-2026-43512 betrifft Bereitstellungen mit DIGEST-Authentifizierung und erlaubt es unter bestimmten Bedingungen, sich mit einem ungültigen Passwort zu authentifizieren. CVE-2026-41293 entsteht durch fehlerhafte Validierung von HTTP/2-Anfrage-Headern, die unsicheres Downstream-Verhalten auslösen können. CVE-2026-43515 ist eine fehlerhafte Autorisierung bei überlappenden HTTP-Methodenbeschränkungen, die unbefugten Zugriff auf geschützte Ressourcen ermöglichen kann. Nutzer sollten auf Tomcat 11.0.22, 10.1.55 oder 9.0.118 aktualisieren.

Zwei kritische Schwachstellen in Apache Camel

CVE-2026-47323 (CVSS 9,8) ist eine kritische Schwachstelle im Apache Camel-Integrationsframework, die Nachrichten-Header-Injektion und Anfrageweiterleitungen betrifft. Die Schwachstelle erlaubt einem nicht authentifizierten Angreifer, Camel-interne Header (z. B. CamelExecCommandExecutable und CamelFileName) über HTTP-Anfragen an CXF-RS- oder CXF-SOAP-Endpunkte einzuschleusen.

Langflow wird aktiv ausgenutzt: fünf weitere kritische Schwachstellen seit Anfang 2026

Langflow ist eine Python-basierte Open-Source-Plattform für Low-Code-Entwicklung und Bereitstellung von KI-Anwendungen, Agenten und Workflows. IBM berichtet, dass Zehntausende von Entwicklern sie für generative KI einsetzen. Im Mai 2026 wurde CVE-2025-34291 (CVSS 8,8) als aktiv ausgenutzt gemeldet und in die KEV-Liste der CISA aufgenommen. Seit Anfang 2026 wurden fünf weitere kritische CVEs in Langflow bekannt:

  • CVE-2025-34291 (CVSS 8,8, EPSS >= 97. Perzentil): Eine verkettete Schwachstelle durch zu freizügiges Cross-Origin-Verhalten (CWE-346) in Kombination mit fehlerhafter Sitzungs-/Token-Verarbeitung kann Kontoübernahme und RCE ermöglichen, wenn ein authentifizierter Benutzer eine vom Angreifer kontrollierte Webseite besucht.
  • CVE-2026-33017 (CVSS 9,8): Nicht authentifizierte RCE über den öffentlichen temporären Flow-Build-Endpunkt. Vom Angreifer bereitgestellte Flow-Daten werden ohne angemessenes Sandboxing als ausführbarer Python-Code verarbeitet.
  • CVE-2026-21445 (CVSS 9,1): Fehlende Authentifizierung (CWE-306) bei bestimmten kritischen API-Endpunkten erlaubt nicht authentifizierten Angreifern den Zugriff auf sensible Benutzerdaten, Konversations- und Transaktionsaufzeichnungen sowie destruktive Operationen wie das Löschen von Nachrichten.
  • CVE-2026-33309 (CVSS 9,9): Umgehung eines früheren Patches zur Dateinamenskontrolle in der LocalStorageService-Schicht ermöglicht beliebiges Dateischreibverhalten (CWE-22) über die v2-API, was potenziell zu RCE führen kann.
  • CVE-2026-27966 (CVSS 9,8): Der CSV-Agent-Knoten legte sensible Python-REPL-Funktionalität offen, durch die Angreifer über Prompt-Injection beliebige Python- oder Betriebssystembefehle ausführen konnten.
  • CVE-2026-42048 (CVSS 9,6): Eine Path-Traversal-Schwachstelle (CWE-22) in der Knowledge Bases API erlaubt einem authentifizierten Angreifer, beliebige Verzeichnisse auf dem Server zu löschen. Unsichere Wissensdatenbanknamen werden ohne Begrenzungsprüfung zu Dateisystempfaden verkettet.

Zusammenfassung

Mythos und andere KI-Coding-Modelle haben erkennbare Auswirkungen auf die Anzahl neu bekannt gewordener Schwachstellen in wichtiger Unternehmenssoftware. Dieselbe Technologie senkt auch die Hürde für Angreifer, Exploits zu entwickeln.

Sicherheitsverantwortliche sollten kontinuierliches Schwachstellenmanagement und Audit-Maßnahmen einsetzen, um das Risiko zu reduzieren. OPENVAS SCAN und der OPENVAS ENTERPRISE FEED bieten branchenführende Schwachstellenabdeckung. Greenbone erstellt monatlich Tausende neuer Schwachstellentests für Unternehmenssoftware, IT-Netzwerkprodukte, Betriebssysteme, Browser, Linux-Pakete, Produktivitätswerkzeuge, agentenbasierte KI-Tools und mehr. Sicherheitsverantwortliche, die Schwachstellen erkennen und Schutzmaßnahmen einleiten möchten, können Greenbones Einstiegsprodukt OPENVAS BASIC kostenlos testen, inklusive einer zweiwöchigen Testversion des ENTERPRISE FEED.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Greenbone AG

Die CRA-Frist im September 2026: Was Hersteller jetzt tun müssen

Zeitkritisch

Dieser Artikel befasst sich mit dem Meldepflicht-Stichtag am 11. September 2026 — dem ersten verbindlichen Durchsetzungsmeilenstein des Cyber Resilience Act. Stand 27. August 2026 verbleiben Ihnen noch 15 Tage zur Vorbereitung.

Die meisten Unternehmen, die den CRA als ein Problem für 2027 betrachten, hinken bereits hinterher. Laut dem „2026 CRA Awareness and Readiness Report“ von OpenSSF und Linux Foundation Research sind 66 % der befragten Softwarehersteller nach wie vor nicht mit der Verordnung vertraut – und diese Zahl ist im Vergleich zum Vorjahr gestiegen. Der erste Stichtag für die Durchsetzung ist nicht Dezember 2027. Es ist der 11. September 2026, an dem die Meldepflichten für Sicherheitslücken gemäß Artikel 14 rechtsverbindlich werden. Ab diesem Datum sind Sie verpflichtet, eine Frühwarnung über die ENISA Single Reporting Platform einzureichen, wenn eine Sicherheitslücke in Ihrem Produkt aktiv ausgenutzt wird, und zwar innerhalb von 24 Stunden, nachdem Sie davon Kenntnis erlangt haben. Verpassen Sie diese Frist, verstoßen Sie bereits gegen die Vorschriften – mit einem Bußgeld von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Was genau müssen Sie ab September 2026 tun?

Die Meldepflicht wird durch zwei Bedingungen ausgelöst, von denen jede Maßnahmen erfordert:

  • Eine aktiv ausgenutzte Schwachstelle in einem Ihrer betroffenen Produkte, unabhängig vom Schweregrad
  • Ein schwerwiegender Vorfall, der die Sicherheit Ihrer Produkte beeinträchtigt – zum Beispiel eine erhebliche Sicherheitsverletzung oder eine systemische Kompromittierung

Sobald eine der beiden Bedingungen erfüllt ist, beginnt eine dreistufige Meldeprozedur:

Stufe 1 — Frühwarnung: Innerhalb von 24 Stunden

Reichen Sie über die ENISA Single Reporting Platform (SRP) eine Frühwarnung ein, in der Sie bestätigen, dass Ihnen eine aktiv ausgenutzte Schwachstelle bekannt ist. In dieser Phase müssen Sie noch keine vollständigen technischen Details angeben. Der Zweck besteht darin, zu signalisieren, dass Sie sich der Situation bewusst sind und diese im Griff haben. Die SRP leitet den Bericht automatisch gleichzeitig an Ihren nationalen CSIRT-Koordinator und an die ENISA weiter. Die SRP selbst ist zum jetzigen Zeitpunkt noch nicht in Betrieb – die ENISA gibt an, dass die Plattform bis zum 11. September 2026 betriebsbereit sein soll; eine feste öffentliche URL wird erst kurz vor dem Start bekanntgegeben. Anleitungen zur Registrierung und Einbindung (EU-Login-Zugang, Rollen für benannte Vertreter) werden von der ENISA bereits seit dem 31. Juli 2026 schrittweise veröffentlicht – mit diesem Teil der Vorbereitung müssen Sie also nicht auf die Plattform selbst warten.

Stufe 2 — Vollständige Meldung: Innerhalb von 72 Stunden

Reichen Sie eine vollständige Meldung ein, die technische Details zur Schwachstelle, eine erste Schweregradbewertung (unter Verwendung von CVSS oder einem gleichwertigen System), betroffene Produkte und Versionen sowie alle verfügbaren Abhilfemaßnahmen oder Workarounds enthält. Dieser Bericht muss korrekt und vollständig sein – übereilte oder ungenaue Berichte können zu Strafen der Stufe 3 wegen der Bereitstellung falscher Informationen führen.

Stufe 3 — Abschlussbericht: Innerhalb von 14 Tagen nach Veröffentlichung eines Fixes

Bei einer aktiv ausgenutzten Schwachstelle reichen Sie den Abschlussbericht spätestens 14 Tage, nachdem ein Sicherheitsupdate oder eine andere Abhilfemaßnahme verfügbar ist, bei der ENISA ein. Bei einem schwerwiegenden Vorfall ist der Abschlussbericht innerhalb eines Monats nach Einreichung der Stufe-2-Meldung (72-Stunden-Meldung) fällig – eine eigene Frist, die unabhängig davon läuft, wann oder ob ein Fix veröffentlicht wird. Beide Berichte schließen den Meldeprozess ab und müssen eine vollständige Beschreibung des Vorfalls bzw. der Schwachstelle, eine Bewertung von Schweregrad und Auswirkungen sowie eine vollständige Darstellung der ergriffenen Abhilfemaßnahmen enthalten.

Ein Detail, das die meisten Teams übersehen: Es gilt auch für bestehende Produkte

Die Meldepflichten ab September 2026 gelten nicht nur für Produkte, die nach diesem Datum auf den Markt gebracht werden. Gemäß Artikel 69 Absatz 3 der CRA gelten sie für alle Produkte mit digitalen Elementen, die bereits auf dem EU-Markt sind, einschließlich Produkten, die Jahre vor Inkrafttreten der CRA ausgeliefert wurden. Wenn eine Schwachstelle in einem Produkt, das Sie 2021 veröffentlicht haben, im September 2026 aktiv ausgenutzt wird, sind Sie verpflichtet, dies zu melden. Das überrascht viele Teams: Der Geltungsbereich dieser Verpflichtung umfasst Ihren gesamten aktiven Produktkatalog, nicht nur Ihre nächste Version.

Das begründet keine rückwirkende Meldepflicht für jede Schwachstelle, die Ihnen bereits vor dem Stichtag bekannt war. Die Meldepflicht wird durch die Kenntnis einer aktiv ausgenutzten Schwachstelle ausgelöst (Artikel 14 Absatz 1) – nicht durch die bloße Existenz der Schwachstelle. Kannten Sie eine nicht ausgenutzte Schwachstelle bereits vor dem 11. September 2026, müssen Sie an diesem Stichtag nichts melden; die 24-Stunden-Frist beginnt erst, sobald Ihnen eine aktive Ausnutzung bekannt wird – unabhängig davon, ob das vor oder nach dem Stichtag geschieht.

Ein zweites Detail, das es zu beachten gilt: Die 24-Stunden-Frist beginnt bei der begründeten Annahme einer aktiven Ausnutzung, nicht erst bei bestätigten forensischen Beweisen. Wenn Ihre Überwachung glaubwürdige Anzeichen für eine Ausnutzung meldet, können Sie nicht auf Gewissheit warten, bevor Sie die Frühwarnung einreichen. Das Warten auf eine Bestätigung ist der Grund, warum Unternehmen das Zeitfenster verpassen werden.

Warum das schwieriger ist, als es klingt

Die meisten Organisationen verfügen nicht über einen erprobten 24-Stunden-Prozess zur Meldung von Schwachstellen. Um einen solchen aufzubauen, ist Folgendes erforderlich:

  • Kontinuierliche Schwachstellenüberwachung: Was Sie nicht sehen können, können Sie auch nicht melden. Echtzeit-Transparenz über Ihr gesamtes Produktportfolio ist die Grundlage des gesamten Prozesses.
  • Klare interne Eskalationswege: Wer wird zuerst benachrichtigt? Wer ist befugt, einen Bericht an die ENISA zu übermitteln? Wer erstellt die technische Dokumentation? All dies muss festgelegt sein, bevor die Uhr zu ticken beginnt.
  • Genaue Produktbestandsaufnahme: Sie müssen genau wissen, welche Produkte betroffen sind und welche aktuellen Versionen im Einsatz sind, einschließlich End-of-Life-Produkten, die sich noch innerhalb der 5-jährigen obligatorischen Support-Frist befinden.
  • Behördenkontakte: Sie benötigen die richtigen ENISA-Meldewege und die Kontaktdaten Ihres nationalen CSIRT griffbereit.
  • Rechtliche Prüfung: Meldungen an Aufsichtsbehörden haben rechtliche Bedeutung. Ihr Rechtsteam muss in den Eskalationsprozess eingebunden sein.

Nichts davon lässt sich an einem Wochenende aufbauen. Organisationen, die noch keine Schwachstellenmanagementprogramme mit dokumentierten Nachweisen betreiben, werden bis September unter erheblichem operativem Druck stehen, um bereit zu sein.

Ihre Checkliste für die Bereitschaft im September 2026

  • Identifizieren Sie alle betroffenen Produkte und bestätigen Sie deren Supportzeiträume, einschließlich älterer Produkte, die bereits auf dem EU-Markt sind
  • Implementieren oder überprüfen Sie kontinuierliche Schwachstellenscans für alle betroffenen Produkte und deren Komponenten
  • Dokumentieren Sie Ihren internen Eskalationsprozess für vermutete, aktiv ausgenutzte Schwachstellen
  • Legen Sie fest, wer für die Einreichung von ENISA-Meldungen verantwortlich ist (Rechtsabteilung, Sicherheitsabteilung oder ein benannter Datenschutzbeauftragter)
  • Registrieren Sie sich bei Ihrem nationalen CSIRT und bereiten Sie sich auf die Registrierung auf der ENISA Single Reporting Platform (SRP) vor
  • Führen Sie eine Tabletop-Übung durch, die ein 24-Stunden-Meldeszenario simuliert
  • Informieren Sie die Geschäftsleitung über Meldepflichten und Haftungsrisiken
  • Stellen Sie sicher, dass Ihre Schwachstellenmanagement-Tools auditfähige Berichte im erforderlichen Format erstellen können

Weitere Fristen im Blick

September 2026 ist der dringlichste Termin, aber nicht der einzige. Zum jetzigen Zeitpunkt ist noch keine harmonisierte CRA-Norm für irgendeine Produktkategorie im Amtsblatt veröffentlicht worden – der Normungsauftrag der Kommission (M/606) umfasst insgesamt 41 Normen. Der bislang konkreteste Meilenstein ist ein Satz von 17 Norm-Entwürfen der ETSI für höherriskante Produktkategorien, der am 13. August 2026 in die öffentliche Anhörung ging; die Kommentierungsfristen enden je nach Kategorie zwischen Mitte September und Mitte November 2026. Die vollständige Produktkonformität für alle Kategorien gilt erst ab dem 11. Dezember 2027, doch Organisationen, die auf die harmonisierten Normen warten, bevor sie mit der Arbeit beginnen, haben nur sehr wenig Zeit für die Umsetzung.

Das bedeutet: Mit einer Meldefrist, die jetzt nur noch gut zwei Wochen entfernt ist, und einer technischen Normungsebene, die sich weiterhin erst noch formt, ist der Spätsommer 2026 für alle noch nicht vorbereiteten Organisationen eine Phase intensiver, paralleler Compliance-Aktivitäten. Jetzt damit zu beginnen, ist nicht zu früh. Es ist der letzte Moment, um zu vermeiden, dass man ohne einen getesteten Prozess dasteht, wenn die Uhr zu ticken beginnt.

→ Den vollständigen Leitfaden lesen

Der vollständige Leitfaden zum EU Cyber Resilience Act — alle Anforderungen, Produktkategorien und der vollständige Zeitplan an einem Ort. Zum Leitfaden →

Quellen

  1. Verordnung (EU) 2024/2847 — Cyber Resilience Act (EUR-Lex, offizieller Gesetzestext)
    https://eur-lex.europa.eu/eli/reg/2024/2847/2024-11-20

  2. 2026 CRA Awareness and Readiness Report — OpenSSF / Linux Foundation Research
    https://openssf.org/blog/2026/05/18/taking-stock-of-the-state-of-european-cyber-resilience-act-cra-compliance-an-urgent-wake-up-call-for-the-open-source-ecosystem/

  3. Cyber Resilience Act – Zusammenfassung des Gesetzestextes (Europäische Kommission)
    https://digital-strategy.ec.europa.eu/en/policies/cra-summary
Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Greenbone AG

Wenn der Schiedsrichter aufhört zu pfeifen

NIST stellt die unabhängige CVSS-Bewertung weitgehend ein.

Seit Jahren ist das Ritual dasselbe. Eine neue Schwachstelle taucht auf, das Security-Team schaut in die NVD, sieht den CVSS-Score, und entscheidet: patchen oder warten. Ein einziger Wert, produziert von einer US-Bundesbehörde, wird zum Taktgeber für Millionen von Systemen weltweit.
Dieser Taktgeber fällt nun weitgehend weg.
Das NIST hat angekündigt, die routinemäßige CVSS-Berechnung für die National Vulnerability Database einzustellen. Der Rückstau an unbearbeiteten Einträgen ist seit Februar 2024 von 13.000 auf über 27.000 angewachsen bei gleichzeitig steigender Zahl gemeldeter Schwachstellen und stagnierendem Budget. Was bleibt, wenn NIST nicht mehr rechnet: der CVSS-Score des Herstellers selbst.

CVE-2025-20393-cisco-spam-filter

Das strukturelle Problem hinter der Schlagzeile

In der Security-Community ist es kein Geheimnis, dass Hersteller dazu neigen, die Schwere eigener Schwachstellen niedrig zu bewerten. Das NIST hat diesen Interessenkonflikt bisher mit einer unabhängigen Zweitbewertung ausgeglichen. Diese Unabhängigkeit baut sich immer weiter ab.
Für Teams, die bislang mit NVD-CVSS als primärer Prioritätsquelle gearbeitet haben, ist das eine echte Verschiebung. Für Greenbone-Nutzer ändert sich operativ nichts.

Breite internationale Datenbasis statt Single Source of Truth

Greenbones Ansatz basiert auf einer bewussten Quell-Diversität. Schwachstelleninformationen werden aus einem breiten, internationalen Portfolio bezogen wie offiziellen Datenbanken, Hersteller-Advisories in standardisierten Formaten wie CSAF, nationale Behörden wie das BSI, europäische Initiativen wie die EuVD, und darüber hinaus aus der globalen Security-Community. Jede wird eingeordnet, gewichtet und abgeglichen.
Der Vorteil dieser Breite zeigt sich besonders in Momenten wie dem aktuellen: Wenn eine Quelle ausfällt, wegfällt oder an Qualität verliert, verändert sich das Gesamtbild nicht. Die Redundanz ist kein Luxus, sondern Voraussetzung für verlässliche Priorisierung.

Die EuVD: Europäische Souveränität als konstruktive Antwort

Die NIST-Krise macht ein strukturelles Abhängigkeitsproblem sichtbar: Europa hat sich bei der Schwachstellenbewertung zu stark auf eine einzelne US-Behörde verlassen. Die ENISA-betriebene European Vulnerability Database ist die richtige systemische Antwort. Souverän, europäisch, unabhängig von US-Haushaltsentscheidungen.

Erfahren Sie, wie Ihr Unternehmen die Anforderungen des Cyber Resilience Act erfüllt und Ihre Cyberresilienz nachhaltig stärkt.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Elmar Geese

Angreifer steigen zunehmend von gestohlenen Zugangsdaten auf ausgenutzte Schwachstellen um

Fast zwei Jahrzehnte lang standen gestohlene Zugangsdaten im Mittelpunkt vieler Analysen zu Sicherheitsverletzungen. Dieses Bild ändert sich nun. Laut dem Verizon Data Breach Investigations Report 2026 (DBIR) haben Schwachstellen-Exploits erstmals die Zugangsdaten-Kompromittierung als häufigsten Angriffsvektor abgelöst – mit 31 % der Sicherheitsverletzungen gegenüber nur 13 % für gestohlene Zugangsdaten. KI beschleunigt die Angriffsentwicklung und verkürzt das Zeitfenster zwischen Offenlegung einer Schwachstelle und ihrer Ausnutzung von Monaten auf Stunden. ([Heise][1])

Diese Verschiebung ist strategisch wichtig. Sie bedeutet, dass sich Unternehmen nicht mehr allein auf Identitätsschutz, Phishing-Schulungen, MFA, Endgeräteschutz oder Perimeter-Abwehr verlassen können. Diese Kontrollmaßnahmen bleiben zwar unverzichtbar, beantworten aber nicht die zentrale Frage, die Angreifer zunehmend ausnutzen: Wo ist das Unternehmen derzeit technisch verwundbar?

KI verändert das Tempo von Angriffen

Generative KI und Automatisierung senken die Kosten für die Aufklärung, beschleunigen die Entwicklung von Exploits und erleichtern es Angreifern, ihre Operationen zu skalieren. Die praktische Konsequenz ist klar: Verteidiger müssen die Zeit zwischen der Offenlegung, Erkennung, Priorisierung und Behebung von Schwachstellen verkürzen. In einer Umgebung, in der Angreifer exponierte Schwachstellen schneller identifizieren und ausnutzen können, ist Schwachstellenmanagement nicht mehr nur eine periodische Compliance-Maßnahme. Es wird zu einer operativen Sicherheitsdisziplin.

Schwachstellenmanagement schließt die Lücke

Unternehmen müssen Schwachstellen identifizieren, bevor Angreifer sie ausnutzen. Wir sehen dabei Schwachstellenmanagement als den zentralen Prozess, bei dem Schwachstellen in der IT-Infrastruktur aufgedeckt, nach Schweregrad klassifiziert und Behebungsmaßnahmen empfohlen werden. So können Schwachstellen beseitigt werden, bevor sie zu ausnutzbaren Risiken werden.

Das Schwachstellenmanagement betrachtet die Infrastruktur aus der Perspektive des Angreifers und fragt, welche Systeme, Dienste, Geräte und Konfigurationen derzeit exponiert sind. Greenbone positioniert diese „Outside-in“-Sichtweise ausdrücklich als Ergänzung zu Firewalls und anderen Verteidigungssystemen.

Warum OpenVAS gerade jetzt der richtige Schwachstellenscanner ist

OPENVAS ist unsere Antwort auf dieses Problem. Wir bieten authentifizierte und nicht authentifizierte Tests, Unterstützung für Internet- und Industrieprotokolle, die Optimierung von groß angelegten Scans sowie eine leistungsstarke interne Sprache für Schwachstellentests. Unsere Tests stammen aus einem Feed mit täglichen Updates, und das schon seit 2006.

Unsere Enterprise-Vulnerability-Management-Lösungen nutzen mehr als 225.000 Schwachstellentests, wobei täglich neue Tests hinzukommen. Das ist wichtig, denn Schwachstellenmanagement ist nur dann sinnvoll, wenn es die aktuelle Bedrohungslage widerspiegelt. Ein Scanner, der nicht kontinuierlich aktualisiert wird, wird von Angreifern schnell überholt.

Die wirtschaftlichen Argumente sind überzeugender geworden

KI verändert die ökonomischen Argumente für das Schwachstellenmanagement. Der Bedarf ist nicht abstrakt. Er wird durch messbare Veränderungen im Verhalten der Angreifer vorangetrieben. Laut dem DBIR 2026 stieg die mittlere Zeit bis zur vollständigen Behebung auf 43 Tage (gegenüber 32 Tagen im Vorjahr), während Unternehmen nur 26 % der Schwachstellen im CISA-Katalog bekannter ausgenutzter Schwachstellen (KEV) beheben konnten, gegenüber 38 % im Jahr 2024.

Wenn ausgenutzte Schwachstellen zum Hauptzugang in Unternehmen werden, ist das Erkennen und Verringern der angreifbaren Angriffsfläche eine der wirksamsten Methoden, um die Wahrscheinlichkeit von Sicherheitsverletzungen zu senken.

Fazit: Sicherheitsteams benötigen kontinuierliche Transparenz

Die Lehre aus den neuesten Angriffsdaten ist einfach: Unternehmen müssen davon ausgehen, dass ihre offengelegten Schwachstellen schneller als zuvor gesucht, korreliert und ausgenutzt werden. Der Schutz von Anmeldedaten bleibt unerlässlich, reicht aber nicht mehr aus. Die neue Priorität liegt auf kontinuierlicher Transparenz der Angriffsfläche, risikobasierter Priorisierung und schneller Behebung.

Genau hier kommen Greenbone und OPENVAS ins Spiel. In einer Bedrohungslandschaft, in der Angreifer zunehmend über bekannte und aufdeckbare Schwachstellen eindringen, wird das Schwachstellenmanagement zur ersten Verteidigungslinie: die Schwachstelle erkennen, das Risiko verstehen, handeln, bevor der Angreifer es tut.

[1]: https://www.heise.de/news/KI-Aera-Laut-Verizon-mehr-Angriffe-ueber-Luecken-als-mit-gestohlenen-Zugangsdaten-11299991.html?utm_source=chatgpt.com „KI-Ära: Laut Verizon mehr Angriffe über Lücken als mit gestohlenen Zugangsdaten“

[2]: https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/?utm_source=chatgpt.com „Verizon DBIR 2026: Ausnutzung von Schwachstellen überholt Diebstahl von Zugangsdaten als häufigste Angriffsmethode“

[3]: https://www.verizon.com/business/resources/reports/dbir/ „2026 Data Breach Investigations Report (DBIR) | Verizon“

[4]: https://www.greenbone.net/en/ „Schwachstellenmanagement | Open Source und DSGVO-konform“

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Greenbone AG

Greenbones OPENVAS SCAN deckt nun auch Sicherheitshinweise für Ubuntu 26.04 LTS ab!

Sicherheitsverantwortliche, die Ubuntu einsetzen, werden sich freuen zu erfahren, dass Greenbones OPENVAS SCAN nun die Erkennung von Sicherheitsmeldungen für Ubuntu 26.04 LTS über den OPENVAS ENTERPRISE FEED und den COMMUNITY FEED umfasst. Ubuntu 26.04 LTS, auch bekannt als „Resolute Raccoon“, ist eine Long-Term-Support-Version (LTS) von Ubuntu, die am 23. April 2026 veröffentlicht wurde. LTS-Versionen erhalten fünf Jahre lang standardmäßige Sicherheitsupdates und kritische Fehlerbehebungen, sodass Ubuntu 26.04 LTS bis April 2031 mit Updates versorgt wird. Die Unterstützung für Ubuntu 26.04 LTS erweitert die bestehenden Erkennungsfunktionen von OPENVAS SCAN für Ubuntu-Sicherheitshinweise bis zurück zu Ubuntu 5.10.

OPENVAS SCAN von Greenbone bietet branchenführende Erkennung für viele gängige Linux-Distributionen über authentifizierte Local Security Checks (LSC). Authentifizierte LSCs sorgen für zuverlässige Erkennung, da sie Endpunktsysteme von innen analysieren, ein Bestandsverzeichnis erstellen, Software-Schwachstellen auf Paketebene aufdecken und andere Sicherheitsfehlkonfigurationen identifizieren.

Sicherheitsverantwortliche, die nach Erkennungs- und Schutzlösungen suchen, können Greenbones OPENVAS BASIC kostenlos testen, einschließlich einer zweiwöchigen Testversion des OPENVAS ENTERPRISE FEED.

CVE-2025-20393-cisco-spam-filter

Sicherheitsupdates für Betriebssysteme (OS) sind entscheidend für die Aufrechterhaltung einer starken Sicherheitslage im Unternehmen. Eine einzige Schwachstelle kann Angreifenden den initialen Zugang verschaffen, den sie für einen kostspieligen Cyberangriff benötigen. OS-Schwachstellen wirken sich auf alle Aspekte der IT-Infrastruktur aus, einschließlich lokaler und Cloud-Ressourcen, Mitarbeiter-Workstations, Entwicklungsumgebungen, Container-Hosts, Virtualisierungsplattformen und Edge-Infrastruktur. Neue Vorschriften und Compliance-Anforderungen verlangen zudem eine stärkere Rechenschaftspflicht und belasten IT-Sicherheitsteams zunehmend. Sicherheitsverantwortliche benötigen einen besseren Überblick über aufkommende Sicherheitsrisiken, um Abhilfemaßnahmen effektiv priorisieren zu können.

Sehen Sie, was in Ihrer Linux-Umgebung angreifbar ist

Warten Sie nicht, bis Angreifer Ihre Schwachstellen finden. Starten Sie noch heute Ihren Scan mit OPENVAS FREE – inklusive zweiwöchiger Testphase des OPENVAS ENTERPRISE FEED.

Unterstützung für Ubuntu 26.04 LTS-Sicherheitshinweise ist da!

Canonical veröffentlicht Ubuntu-Sicherheitshinweise (USNs), wenn Sicherheitsprobleme in offiziellen Ubuntu-Paketen behoben werden. Ein typischer USN benennt das betroffene Paket, die betroffenen Ubuntu-Versionen, zugehörige CVE-IDs, die Auswirkungen der Sicherheitslücke und die zur Behebung erforderlichen Paket-Updates.

Unternehmen, die Ubuntu 26.04 LTS einsetzen, können nun Greenbones OPENVAS SCAN nutzen, um Ubuntu 26.04-Sicherheitshinweise sowohl im OPENVAS ENTERPRISE FEED als auch im COMMUNITY FEED zu erkennen.

Zusammenfassung

Linux-Systeme bilden das Rückgrat vieler Unternehmensumgebungen und unterstützen kritische Infrastrukturen, Cloud-Plattformen, Mitarbeiter-Workstations, Entwicklungssysteme, Container-Hosts und Produktions-Workloads. Die Aufrechterhaltung der Linux-Sicherheit erfordert einen konsistenten Überblick über Schwachstellen und ein zeitnahes Patch-Management. Ein effektives Schwachstellenmanagement auf Betriebssystemebene verringert das Risiko von Exploits, unterstützt die Einhaltung gesetzlicher Vorschriften und hilft Unternehmen dabei, eine robuste Sicherheitslage aufrechtzuerhalten.

Unternehmen, die Ubuntu 26.04 LTS einsetzen, können nun Greenbones OPENVAS SCAN nutzen, um Ubuntu-Sicherheitshinweise über den OPENVAS ENTERPRISE FEED und den COMMUNITY FEED zu erkennen. Die Erkennung von Ubuntu 26.04 ergänzt andere beliebte Linux-Betriebssysteme, die sowohl im OPENVAS ENTERPRISE FEED als auch im COMMUNITY FEED unterstützt werden, darunter Fedora, Debian, Suse, OpenSuse, Huawei EulerOS, OpenEuler und Mageia. Greenbones OPENVAS ENTERPRISE FEED unterstützt weitere Linux-Distributionen, darunter Amazon Linux, Oracle Linux, AlmaLinux OS, FortiOS und viele mehr.

Sicherheitsbeauftragte können Greenbones OPENVAS BASIC kostenlos testen, einschließlich einer zweiwöchigen Testversion des OPENVAS ENTERPRISE FEED.

Bereit, die Lücken in Ihrer Linux-Security zu schließen?

Von RHEL über Rocky Linux bis hin zu Ubuntu und AlmaLinux – OPENVAS SCAN verschafft Ihrem Team die nötige Transparenz, um Schwachstellen zu erkennen, bevor sie zu Sicherheitsvorfällen werden. Kein Rätselraten. Keine blinden Flecken.

OPENVAS FREE testenMit Security-Experten sprechen
Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Greenbone AG

Greenbones OPENVAS SCAN deckt nun auch die Sicherheitshinweise zu Fedora 44 ab!

Für Sicherheitsverantwortliche, die Fedora einsetzen, gibt es eine gute Nachricht: Greenbones OPENVAS SCAN nun über den OPENVAS ENTERPRISE FEED und den COMMUNITY FEED auch Sicherheitshinweise für Fedora 44 erkennt. Fedora Linux 44 wurde am 28. April 2026 veröffentlicht, und Releases werden in der Regel 13 Monate lang gepflegt. Für Fedora 44 wurde der 19. Mai 2027 als voraussichtliches End-of-Life-Datum (EOL) festgelegt. Die Unterstützung für Fedora 44 erweitert die bestehenden Erkennungsfunktionen von OPENVAS SCAN für Fedora-Sicherheitshinweise bis zurück zu Fedora 7.

OPENVAS SCAN von Greenbone bietet branchenführende Erkennung für gängige Linux-Distributionen über authentifizierte Local Security Checks (LSC). Authentifizierte LSCs sorgen für zuverlässige Erkennung, da sie Endpunktsysteme von innen analysieren, ein Bestandsverzeichnis erstellen, Software-Schwachstellen auf Paketebene aufdecken und andere Sicherheitsfehlkonfigurationen identifizieren.

Sicherheitsverantwortliche, die nach Erkennungs- und Schutzlösungen suchen, können Greenbones OPENVAS BASIC kostenlos testen, einschließlich einer zweiwöchigen Testversion des OPENVAS ENTERPRISE FEED.

CVE-2025-20393-cisco-spam-filter

Sicherheitsupdates für Betriebssysteme (OS) sind entscheidend für die Aufrechterhaltung einer starken Sicherheitslage im Unternehmen. Eine einzige Schwachstelle kann Angreifenden den initialen Zugang verschaffen, den sie für einen kostspieligen Cyberangriff benötigen. OS-Schwachstellen wirken sich auf alle Aspekte der IT-Infrastruktur aus, einschließlich lokaler und Cloud-Ressourcen, Mitarbeiter-Workstations, Entwicklungsumgebungen, Container-Hosts, Virtualisierungsplattformen und Edge-Infrastruktur. Neue Vorschriften und Compliance-Anforderungen verlangen zudem eine stärkere Verantwortlichkeit und belasten IT-Sicherheitsteams zunehmend. Sicherheitsverantwortliche benötigen einen besseren Überblick über aufkommende Sicherheitsrisiken, um Gegenmaßnahmen effektiv priorisieren zu können.

Sehen Sie, was in Ihrer Linux-Umgebung angreifbar ist

Warten Sie nicht, bis Angreifer Ihre Schwachstellen finden. Starten Sie noch heute Ihren Scan mit OPENVAS FREE – inklusive zweiwöchiger Testphase des OPENVAS ENTERPRISE FEED.

Unterstützung für Fedora 44-Sicherheitshinweise ist da!

Fedora-Sicherheitshinweise werden über das Fedora Updates System, auch bekannt als Bodhi, veröffentlicht. Jeder Hinweis enthält eine eindeutige Kennung, betroffene Paketversionen, den Update-Status, eine Liste der zugehörigen CVEs, eine allgemeine Schweregradbewertung und den Teststatus für den Patch.

Unternehmen, die Fedora 44 einsetzen, können sich freuen: Greenbones OPENVAS SCAN unterstützt nun die Erkennung von Schwachstellen für Fedora 44-Sicherheitshinweise sowohl im OPENVAS ENTERPRISE FEED als auch im COMMUNITY FEED unterstützt.

Zusammenfassung

Linux-Systeme bilden das Rückgrat vieler Unternehmensumgebungen und unterstützen kritische Infrastrukturen, Cloud-Plattformen, Mitarbeiter-Workstations, Entwicklungssysteme, Container-Hosts und Produktions-Workloads. Die Aufrechterhaltung der Linux-Sicherheit erfordert einen konsistenten Überblick über Schwachstellen und ein zeitnahes Patch-Management. Ein effektives Schwachstellenmanagement auf Betriebssystemebene verringert das Risiko von Exploits, unterstützt die Einhaltung gesetzlicher Vorschriften und hilft Unternehmen dabei, eine robuste Sicherheitslage aufrechtzuerhalten.

Unternehmen, die Fedora Linux einsetzen, können nun Greenbones OPENVAS SCAN nutzen, um Sicherheitshinweise für Fedora 44 über den OPENVAS ENTERPRISE FEED und den COMMUNITY FEED zu erkennen. Damit gewinnen Sicherheitsverantwortliche bessere Einblicke in Schwachstellen auf Fedora-Systemen und können fehlende Sicherheitsupdates mittels authentifizierter Erkennung auf Paketebene zuverlässig aufdecken.

Mit Fedora 44 ergänzt OPENVAS SCAN die Unterstützung weiterer beliebter Linux-Betriebssysteme, die sowohl im OPENVAS ENTERPRISE FEED als auch im COMMUNITY FEED verfügbar sind, darunter Ubuntu, Debian, Suse, OpenSuse, Huawei EulerOS, OpenEuler und Mageia. Greenbones OPENVAS ENTERPRISE FEED unterstützt weitere Linux-Distributionen, darunter Amazon Linux, Oracle Linux, AlmaLinux OS, FortiOS und viele mehr.

Sicherheitsverantwortliche können Greenbones OPENVAS BASIC kostenlos testen, einschließlich einer zweiwöchigen Testversion des OPENVAS ENTERPRISE FEED.

Bereit, die Lücken in Ihrer Linux-Security zu schließen?

Von RHEL über Rocky Linux bis hin zu Ubuntu und AlmaLinux – OPENVAS SCAN verschafft Ihrem Team die nötige Transparenz, um Schwachstellen zu erkennen, bevor sie zu Sicherheitsvorfällen werden. Kein Rätselraten. Keine blinden Flecken.

OPENVAS FREE testenMit Security-Experten sprechen
Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Joseph Lee

Linux-Schwachstellen Copy Fail, Copy Fail 2 und Dirty Frag: Root-Zugriff auf gängigen Distributionen

Drei hochkritische Linux-Schwachstellen zur lokalen Rechteausweitung (LPE) gefährden Systeme weltweit. Angreifer benötigen zwar initialen Zugriff auf Benutzerebene – können dann aber Befehle als Root ausführen und das System vollständig übernehmen. Alle drei CVEs sind auf gängigen Linux-Distributionen zuverlässig ausnutzbar.

Der Name „Copy Fail“ wurde CVE-2026-31431 (CVSS 7.8) zum Zeitpunkt der Offenlegung gegeben, und nachfolgende Untersuchungen führten zur Entdeckung von CVE-2026-43284 (CVSS 8.8), auch „Copy Fail 2“ genannt, sowie CVE-2026-43500 (CVSS 7.8). Die Angriffskette, die CVE-2026-43284 und CVE-2026-43500 umfasst, wurde als „Dirty Frag“ bezeichnet. CVE-2026-31431 wurde in die KEV-Liste der CISA aufgenommen, nachdem von Microsoft eine aktive Ausnutzung gemeldet wurde. Microsoft stuft „Dirty Frag“ zudem als hochriskant für Aktivitäten nach der Ausnutzung ein. Weltweit wurden zahlreiche nationale CERT-Warnungen zu den CVEs

CVE-2025-20393-cisco-spam-filter

Greenbone bietet eine Erkennung auf Linux-Paketebene für alle drei oben genannten dringenden CVEs über ein breites Spektrum an Linux-Distributionen hinweg [1][2][3]. Die Abdeckung von Greenbone erstreckt sich auch auf Sicherheitsupdates für eine Vielzahl von Software- und Hardwareprodukten. Daher kann OPENVAS SCAN auch dabei helfen, die Auswirkungen von „Copy Fail“, „Copy Fail 2“ und „Dirty Frag“ in Linux-basierten Produkten von Drittanbietern zu identifizieren.

Greenbones OPENVAS SCAN verfügt über eine branchenführende Erkennung für viele Linux-Distributionen mit authentifizierten Local Security Checks (LSC). Authentifizierte LSCs bieten eine zuverlässige Erkennung, da sie Endpunktsysteme von innen analysieren, Bestandslisten erstellen, Software-Schwachstellen auf Paketebene aufdecken und andere Sicherheitsfehlkonfigurationen identifizieren.

→

Jetzt kostenlos testen

Mit kontinuierlich aktualisierter Schwachstellenerkennung, Informationen zur Risikopriorisierung und skalierbaren Abläufen hilft OPENVAS SCAN Unternehmen dabei, ihre Cybersicherheitslage zu stärken, indem es die Gefährdung durch bekannte Bedrohungen in IT-Umgebungen verringert.

Testen Sie noch heute das Flaggschiff-Produkt von Greenbone, OPENVAS SCAN. Unsere Einstiegs-Enterprise-Appliance, OPENVAS BASIC, ist kostenlos erhältlich und beinhaltet eine zweiwöchige Testversion des OPENVAS ENTERPRISE FEED.

 

Was sind Copy Fail, Copy Fail 2 und Dirty Frag? Hintergrund und Zeitplan

Der Zeitplan für die Offenlegung von Copy Fail, Copy Fail 2 und Dirty Frag verlief zügig und überschneidet sich mit Patches für den Mainline-Linux-Kernel sowie nachgelagerten Updates von Linux-Distributionen. Da mehrere damit zusammenhängende Ereignisse innerhalb kurzer Zeit auftraten, ist es sinnvoll, zunächst die Terminologie und den zeitlichen Ablauf der Ereignisse zu klären:

  • Copy Fail: Bezieht sich auf CVE-2026-31431 (CVSS 7.8), eine LPE-Sicherheitslücke im Linux-Kernel. Copy Fail wurde am 23. März 2026 privat gemeldet und am 1. April im Mainline-Linux-Kernel gepatcht. Am 22. April wurde die Schwachstelle als CVE-2026-31431 veröffentlicht, und wenige Tage später folgten ein vollständiger technischer Bericht [1] sowie ein Proof-of-Concept-Exploit (PoC) [2].
  • Microsoft meldete am 1. Mai 2026 eine aktive Ausnutzung, und die CISA fügte CVE-2026-31431 noch am selben Tag in den Katalog der bekannten ausgenutzten Schwachstellen (KEV) ein. Seitdem sind weitere technische Beschreibungen [3][4][5], PoC-Exploits [5][6] sowie ein kommerzieller Penetrationstest-Exploit [7] verfügbar geworden.
  • Copy Fail 2: Bezieht sich auf CVE-2026-43284 (CVSS 8.8), veröffentlicht am 8. Mai 2026. Die Schwachstelle wurde im Rahmen von Folgeuntersuchungen zur Grundursache von „Copy Fail“ entdeckt. „Copy Fail 2“ wurde am 30. April 2026 privat gemeldet, und der Fix wurde am 8. Mai in den Mainline-Linux-Kernel integriert. Eine technische Beschreibung [8] und ein PoC-Exploit [9] wurden am 7. Mai veröffentlicht, einen Tag bevor die Upstream-Kernel-Patches für Downstream-Linux-Distributionen verfügbar wurden. Der ursprüngliche technische Bericht weist darauf hin, dass die zugrunde liegende Schwachstelle allein für Root-Zugriff ausgenutzt werden könnte, ohne mit anderen Software-Schwachstellen verkettet zu werden, wie beispielsweise bei dem unten beschriebenen „Dirty Frag“.
  • Dirty Frag: Bezieht sich auf die verkettete Ausnutzung von CVE-2026-43284 (Copy Fail 2) und CVE-2026-43500 (CVSS 7.8). Obwohl CVE-2026-43500 am 11. Mai 2026 verantwortungsbewusst offengelegt und veröffentlicht wurde, gelangten sensible Informationen an die Öffentlichkeit, bevor ein Fix in den Mainline-Linux-Kernel übernommen wurde. Dies veranlasste den Sicherheitsforscher Hyunwoo Kim (@v4bel), am 8. Mai technische Details [9] und PoC-Code [10] zu veröffentlichen, bevor die Ursache von CVE-2026-43500 am 10. Mai 2026 im Mainline-Linux-Kernel behoben wurde.

Risikoanalyse: Warum Copy Fail und Dirty Frag so gefährlich sind

Die Schwachstellen sind breit gestreut: Linux läuft in Netzwerk- und Sicherheitsgeräten, Workstations, Cloud-Umgebungen, IoT-Geräten, eingebetteten Systemen, Industrieanlagen und kritischen Infrastrukturen. Alle drei CVEs sind zuverlässig ausnutzbar – und das auf allen großen Linux-Distributionen, was zu einer breiten globalen Gefährdung führt. Die Schwachstellen lassen sich auf drei separate Upstream-Linux-Commits zurückführen; Copy Fail [72548b093ee3] und Copy Fail 2 [cac2661c53f3] wurden 2017 eingeführt, während der Dirty-Frag-Commit [2dc334f1a63a] 2023 eingeführt wurde [1][2].

Eine aktive Ausnutzung von CVE-2026-31431 (Copy Fail) wurde von Microsoft beobachtet und in die KEV-Liste der CISA aufgenommen, obwohl nur wenige Details zu den Angriffen verfügbar sind. Microsoft stuft zudem Dirty Frag als hohes Risiko für Post-Exploitation-Aktivitäten ein. Erschwerend kommt hinzu: Technische Details und Exploit-Code für CVE-2026-43284 und CVE-2026-43500 kursierten öffentlich, bevor Patches die nachgelagerten Linux-Distributionen erreichten. Damit hatten Angreifer mehr Zeit zum Handeln. Für CVE-2026-43284 wurden sensible Details zeitgleich mit den Upstream-Kernel-Commits veröffentlicht – trotz verantwortungsbewusster Offenlegung durch die Forscher.

Bei CVE-2026-43500 erfolgte die frühe öffentliche Bekanntmachung durch einen Patch, der am 29. April an die öffentliche netdev-Mailingliste gesendet wurde.

Vollständige technische Details und PoC-Exploit-Code sind für alle drei CVEs öffentlich verfügbar, was das Risiko einer Ausnutzung durch weniger erfahrene Angreifer und Initial Access Brokers (IAB) erhöht, die unbefugten Zugriff an Cyberkriminelle verkaufen. Weltweit wurden zahlreiche nationale CERT-Warnungen herausgegeben, und zahlreiche Produktanbieter haben Sicherheitshinweise und Notfall-Patches veröffentlicht, um die Probleme zu beheben [3][4][5][6][7][8][9][10][11][12][13].

Obwohl LPE-Schwachstellen für die Ausnutzung lokalen Kontozugriff erfordern, können Angreifer den erforderlichen Zugriff auf vielfältige Weise erlangen, beispielsweise:

  • Bestehende Software-Schwachstellen [T1190] [T1203]
  • Verwendung gestohlener Anmeldedaten [T1078]
  • Phishing und Spear-Phishing [T1566]
  • Böswillige Insider [T1199]
  • Kompromittierung der Lieferkette [T1195]

Zu den potenziellen Auswirkungen einer erfolgreichen Ausnutzung gehören:

Ransomware-Angriffe

  • Ransomware-Angriffe [T1486]
  • Diebstahl von Anmeldedaten [TA0006]
  • Einsatz von Rootkits [T1014] für verdeckten, dauerhaften Zugriff [TA0003]
  • Ersetzen von Binärdateien [T1554]
  • Deaktivierung von Sicherheitstools [TA0005]
  • Einbindung in Botnetze [T1584.005]
  • Seitliche Bewegung auf andere Systeme [TA0008]
  • Ablegen von manipulierten Dateien [T1204.002]
  • Nachgelagerte Angriffe auf die Lieferkette [T1195]

Patches und Gegenmaßnahmen für Copy Fail, Copy Fail 2 und Dirty Frag

Stand 13. Mai liegen noch nicht für alle CVEs in allen gängigen Distributionen fertige Patches vor. Vorrang hat die Identifikation betroffener Systeme und die sofortige Installation verfügbarer Kernel-Patches. Bis dahin können Sicherheitsverantwortliche die anfälligen Kernel-Module algif_aead, esp6, esp4 und rxrpc deaktivieren [1][2][3][4]. In einigen Fällen könnte dieser Ansatz jedoch problematisch sein, wenn die Module erforderliche Funktionen unterstützen.

Aufgrund der aktiven Ausnutzung und der Verfügbarkeit von PoC-Exploits sollten Sicherheitsverantwortliche die Überwachung auf Indikatoren für Kompromittierung (IoCs) und verdächtige Aktivitäten in Betracht ziehen und bei Verdacht auf einen Sicherheitsvorfall Maßnahmen zur Incident Response ergreifen.

Es ist zudem wichtig zu beachten, dass „Copy Fail“, „Copy Fail 2“ und „Dirty Frag“ zusätzliche Risiken für viele Linux-basierte Produkte von Drittanbietern mit sich bringen können. Sicherheitsverantwortliche sollten die gesamte Infrastruktur auf Schwachstellen scannen und die Sicherheitsrichtlinien der betroffenen Produkthersteller befolgen.

Greenbone bietet eine Erkennung auf Linux-Paketebene für alle drei oben genannten dringenden CVEs über ein breites Spektrum von Linux-Distributionen hinweg [5][6][7]. Die Abdeckung von Greenbone erstreckt sich auch auf Sicherheitsupdates für eine Vielzahl von Software- und Hardwareprodukten, was bedeutet, dass OPENVAS SCAN dabei helfen kann, die Auswirkungen von „Copy Fail“, „Copy Fail 2“ und „Dirty Frag“ auch in Linux-basierten Produkten von Drittanbietern zu identifizieren.

Greenbones OPENVAS SCAN verfügt über eine branchenführende Erkennung für viele Linux-Distributionen mit authentifizierten Local Security Checks (LSC). Authentifizierte LSCs bieten eine zuverlässige Erkennung, da sie Endpunktsysteme von innen analysieren, Bestandslisten erstellen, Software-Schwachstellen auf Paketebene aufdecken und andere Sicherheitsfehlkonfigurationen identifizieren.

→

Jetzt kostenlos testen

Mit kontinuierlich aktualisierter Schwachstellenerkennung, Informationen zur Risikopriorisierung und skalierbaren Abläufen hilft OPENVAS SCAN Unternehmen dabei, ihre Cybersicherheitslage zu stärken, indem es die Gefährdung durch bekannte Bedrohungen in IT-Umgebungen verringert.

Testen Sie noch heute das Flaggschiff-Produkt von Greenbone, OPENVAS SCAN. Unsere Einstiegs-Enterprise-Appliance, OPENVAS BASIC, ist kostenlos erhältlich und beinhaltet eine zweiwöchige Testversion des OPENVAS ENTERPRISE FEED.

 

Fazit: Jetzt patchen – Copy Fail und Dirty Frag aktiv ausgenutzt

Copy Fail, Copy Fail 2 und Dirty Frag sind ein ernstes Problem für alle Linux-Systeme und -Geräte. Es handelt sich um LPE-Schwachstellen, die lokalen Zugriff voraussetzen – aber genau das reicht aus, um Root-Kontrolle zu erlangen. Das Risiko ist echt: PoC-Exploit-Code ist öffentlich verfügbar, CVE-2026-31431 wird aktiv ausgenutzt, und alle drei CVEs funktionieren zuverlässig auf gängigen Linux-Distributionen.

Wer OPENVAS SCAN einsetzt, sollte jetzt scannen – netzwerkweit, inklusive Drittanbieter-Software und -Hardware. Verfügbare Sicherheitsupdates sollten umgehend eingespielt werden. Wo Patches noch fehlen, helfen die Kernel-Modul-Workarounds als Überbrückung. Zusätzlich empfiehlt es sich, lokale Zugriffspfade einzuschränken und die Systeme aktiv auf IoCs zu überwachen.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von