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. Seit März 2026 hat der erste Leitlinienentwurf der Europäischen Kommission (EK) begonnen, die Details zu klären.

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.

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 der Leitlinienentwurf der Europäischen Kommission bestätigt, 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. Der Leitlinienentwurf 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 und schwerwiegende Sicherheitsvorfälle melden, die das Netzwerk und die Informationssysteme betreffen, die für die Entwicklung ihrer OSS-Produkte bereitgestellt werden
• 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. Es geht nicht nur um den Verkauf einer Lizenz. Auch die Bereitstellung von kostenpflichtigem Support, SLA-gestütztem Hosting oder professionellen Dienstleistungen rund um ein OSS-Produkt stellt gemäß des CRA eine gewerbliche Tätigkeit dar. 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 Leitlinienentwurf der Europäischen Kommission vom März 2026: Was wir derzeit wissen

Die Frist für öffentliche Stellungnahmen zum Leitlinienentwurf der Europäischen Kommission vom März 2026 endete am 31. März 2026. Einige Grenzfälle bleiben weiterhin unklar, obwohl die endgültigen Leitlinien noch im Laufe des Jahres 2026 erwartet werden. Unternehmen sollten alle auf dem Entwurf basierenden Schlussfolgerungen zum Anwendungsbereich überprüfen, sobald die endgültige Fassung veröffentlicht ist. In ihrem Leitlinienentwurf vom März 2026 zur Anwendung des CRA liefert die Europäische Kommission einige Klarstellungen zur Definition des Begriffs „gewerbliche Tätigkeit“ 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

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; Anweisungen zur Einbindung und ein Meldehandbuch werden von der ENISA voraussichtlich im Juni 2026 veröffentlicht.

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.

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 im Leitlinienentwurf 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, und achten Sie auf die Anweisungen der ENISA zur Einbindung in das SRP (voraussichtlich im Juni 2026).
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. Verfolgen Sie die endgültigen Leitlinien der Europäischen Kommission. Die Frist für Rückmeldungen endete am 31. März 2026. Wenn die Kommission die endgültige Fassung veröffentlicht, überprüfen Sie alle auf dem Entwurf basierenden Schlussfolgerungen zum Geltungsbereich erneut.

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/

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.

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

Sobald Sie ein Sicherheitsupdate oder eine Abhilfe veröffentlicht haben, reichen Sie innerhalb von 14 Tagen – oder im Falle eines schwerwiegenden Vorfalls innerhalb eines Monats – einen Abschlussbericht bei der ENISA ein. Damit ist der Meldeprozess abgeschlossen; der Bericht muss eine umfassende Beschreibung der Schwachstelle, eine Ursachenanalyse, eine Folgenabschätzung 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.

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.

Weitere Fristen im Blick

September 2026 ist der dringlichste Termin, aber nicht der einzige. Bis zum 30. August 2026 sollen harmonisierte Normen für den Umgang mit Schwachstellen (Typ A/horizontal) und die Produktsicherheit (Typ B) veröffentlicht werden – damit erhalten Hersteller ihre ersten verbindlichen Compliance-Maßstäbe. Die vollständige Produktkonformität für alle Kategorien gilt erst ab dem 11. Dezember 2027, doch Organisationen, die auf die Normen warten, bevor sie mit der Arbeit beginnen, haben nur sehr wenig Zeit für die Umsetzung.

Das bedeutet, dass der Sommer 2026 – mit weniger als 100 Tagen bis zur Meldefrist und der Veröffentlichung der harmonisierten Normen nur zwei Wochen davor – eine Phase intensiver, paralleler Compliance-Aktivitäten sein wird. Jetzt mit dieser Reise 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.

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

4. Cyber Resilience Act — ENISA (Einheitliche Meldeplattform)
   https://www.enisa.europa.eu/topics/cyber-resilience-act

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“

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.

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.

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.

• Besuchen Sie die offizielle Website für Fedora-Sicherheitsupdates
• Alle OPENVAS SCAN-Schwachstellentests für Fedora 44 anzeigen

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.

Im April 2026 wurde die Cybersicherheitslandschaft von Nachrichten über Anthropics neue KI zur Fehlersuche namens „Mythos“ und dem Projekt „Glasswing“ überschwemmt. Die optimistische Prognose lautet, dass Software in einem Jahr frei von Schwachstellen sein wird, da die KI alle Fehler finden und die Anbieter Patches bereitstellen werden. Große Softwareunternehmen werden alle ihre Produkte vor der Veröffentlichung scannen, und Software-Schwachstellen werden der Vergangenheit angehören. Die Realität sieht jedoch wahrscheinlich anders aus. Werfen wir einen Blick auf die aktuellen Entwicklungen in der Cybersicherheitslandschaft im April 2026.

Obwohl einige der größten Bedrohungen dieses Monats hier erwähnt werden, werden viele neu auftretende Schwachstellen fehlen. OPENVAS SCAN erkennt nicht nur die kritischsten Fehler in Ihrer IT-Umgebung. Der OPENVAS ENTERPRISE FEED fügt jeden Monat Tausende neuer Schwachstellentests hinzu, um Fehler in Unternehmenssoftwareanwendungen, IT-Netzwerkprodukten, gängigen Betriebssystemen und Browsern, Linux-Paketen, Produktivitätswerkzeugen, agentenbasierten KI-Tools und vielem mehr zu erkennen. Sicherheitsverantwortliche, die Schwachstellen erkennen und Schutzmaßnahmen ergreifen möchten, können Greenbones Einstiegsversion OPENVAS BASIC kostenlos testen, einschließlich einer zweiwöchigen Testversion des ENTERPRISE FEED.

 

KI-gestützte Schwachstellensuche 2026: Faktencheck zu Project Glasswing

Das Project Glasswing sorgte für einen Medienrummel, doch Transparenz blieb aus. Anthropic gab keine öffentliche Liste heraus, die der Behauptung von „Tausenden von Zero-Day-Schwachstellen“ in „allen gängigen Betriebssystemen“ und „allen gängigen Webbrowsern“ entsprach. Diesen Monat fand VulnCheck lediglich 75 veröffentlichte CVE-Einträge, in denen „Anthropic“ erwähnt wurde, und nur 40 davon wurden Anthropic-Forschern zugeschrieben. Bislang wird nur eine CVE ausdrücklich Project Glasswing zugeschrieben: CVE-2026-4747 (CVSS 8.8).

Das potenzielle Risiko durch offensive KI-Technologie ist hoch. Die dringende Empfehlung der etablierten Cybersicherheitsbehörden SANS Institute und der Cloud Security Alliance (CSA) lautet, dass Unternehmen ihre zentralen Cybersicherheitsmaßnahmen verstärken sollten. Setzen Sie auf robuste Abhilfemaßnahmen und präventive Kontrollen, wie beispielsweise das Prinzip der geringsten Berechtigungen (PoLP), Netzwerksegmentierung zur Verhinderung lateraler Bewegungen, schnellere Patches und seien Sie auf einen möglichen Anstieg hochkritischer CVEs vorbereitet. Wenn zudem potenzielle Zero-Day-Exploits ein hohes Risiko darstellen, sollten Endgeräte mit Erkennungs- und Reaktionstechnologien ausgestattet werden, und Sie sollten darauf vorbereitet sein, kritische Ressourcen mit minimalen Ausfallzeiten neu bereitzustellen. Auch Risiken durch Drittanbieter können sich direkt auf den Betrieb Ihres Unternehmens auswirken. Dies ist eine nüchternere Einschätzung der kurzfristigen Risiken, denen Unternehmen tatsächlich ausgesetzt sind.

CVE-2026-34197: Aktiv ausgenutzte RCE-Schwachstelle in Apache ActiveMQ – sofort patchen

CVE-2026-34197 (CVSS 8.8, EPSS ≥ 98. Perzentil) ist eine durch unsachgemäße Eingabevalidierung verursachte Code-Injection-Sicherheitslücke, die Apache ActiveMQ Classic betrifft. Apache ActiveMQ ist ein beliebter Java-basierter Message Broker, der die asynchrone Kommunikation über Nachrichtenwarteschlangen abwickelt und flexible Client-Optionen unterstützt. CVE-2026-34197 wurde in den Katalog „Known Exploited Vulnerabilities“ (KEV) der CISA aufgenommen und mehrere nationale CERT-Behörden haben weltweit Warnungen herausgegeben [1][2][3][4][5][6][7][8]. Es ist bekannt, dass frühere Schwachstellen in ActiveMQ bei Ransomware-Angriffen ausgenutzt wurden. Eine vollständige technische Beschreibung  sowie ein Proof-of-Concept (PoC)-Exploit-Kit sind öffentlich verfügbar, was das Risiko erhöht. Shadowserver meldet rund 8.000 exponierte Instanzen von ActiveMQ im Internet.

Die neue CVE gilt als Umgehung von CVE-2022-41678 (CVSS 8.8). Die Ausnutzung von CVE-2026-34197 erfordert bei ActiveMQ v6.0.0–6.1.1 keine Anmeldedaten aufgrund einer weiteren ungepatchten Sicherheitslücke durch fehlende Authentifizierung, CVE-2024-32114 (CVSS 8.8). Während für die Ausnutzung anderer Versionen von ActiveMQ eine Authentifizierung erforderlich ist, sind auch Standard-Anmeldedaten ein Faktor für unbefugten Zugriff. Übrigens schrieb der Sicherheitsforscher von Horizon3.ai, der CVE-2026-34197 entdeckte, 80 % des Prozesses einer Claude-AI-Version vor Mythos zu.

Der OPENVAS ENTERPRISE FEED von Greenbone enthält eine aktive Überprüfung und eine Remote-Banner-Versionsprüfung für CVE-2026-34197. Zur Behebung sollte auf Version 5.19.4 oder 6.2.3 aktualisiert werden.

CVE-2026-34621: Schadhafte PDFs ermöglichen Code-Ausführung in Adobe Acrobat und Reader

CVE-2026-34621 (CVSS 8.6 , EPSS ≥ 92. Perzentil) ist eine Schwachstelle durch Prototyp-Verunreinigung [CWE-1321], die die Ausführung von beliebigem Code im Kontext des aktuellen Benutzers ermöglicht. CVE-2026-34621 kann durch Social Engineering ausgenutzt werden und erfordert das Öffnen einer schädlichen PDF-Datei. CVE-2026-34621 wurde zur KEV-Liste der CISA hinzugefügt und Adobe bestätigte die aktive Ausnutzung in einem Sicherheitsbulletin. Weltweit wurden zahlreiche nationale CERT-Warnungen herausgegeben [1][2][3][4][5][6][7][8][9][10][11][12][13][14].

Laut Sicherheitsforschern wird die Schwachstelle seit mindestens Ende 2025 ausgenutzt, wie die Ergebnisse von VirusTotal zeigen. Die Malware decodiert eine Nutzlast per Base64 und führt sie als JavaScript aus, um Informationen vom Computer des Opfers zu extrahieren, einschließlich des Inhalts lokaler Dateien. Anschließend sendet sie die Daten an den Command-and-Control-Server (C2) des Angreifers und wartet auf weitere Anweisungen zur Ausführung. Eine weitere Malware-Analyse ergab, dass Malware, die CVE-2026-34621 ausnutzt, in der Angriffskette mehrere undokumentierte interne APIs in Adobe Acrobat und Reader missbraucht.

Betroffen sind Acrobat DC Continuous 26.001.21367 und frühere Versionen, Acrobat Reader DC Continuous 26.001.21367 und frühere Versionen sowie Acrobat 2024 Classic 2024 24.001.30356 und frühere Versionen unter Windows und macOS. Der OPENVAS ENTERPRISE FEED enthält Erkennungstests für alle betroffenen Produkte unter Windows [15][16][17] und macOS [18][19][20]. Benutzer sollten unverzüglich auf eine gepatchte Version aktualisieren.

CVE-2026-3854: RCE-Schwachstelle in GitHub Enterprise und GitHub.com über Git-Push

CVE-2026-3854 (CVSS 8.8) ermöglicht es einem authentifizierten Angreifer mit Push-Berechtigungen für ein Repository, RCE auf einem Git-Server zu erreichen. Während eines Git-Push-Vorgangs werden vom Benutzer bereitgestellte Werte nicht ordnungsgemäß bereinigt, bevor sie in interne Service-Header aufgenommen werden, was potenziell zu Befehlsinjektion [CWE-77] und RCE führen kann.

Mehrere Git-Produkte, darunter GitHub.com, GitHub Enterprise Server und GitHub Enterprise Cloud, sind betroffen. Eine vollständige technische Beschreibung wurde veröffentlicht, und öffentliche PoC-Exploits wurden von CIRCL.lu gesichtet. Obwohl die öffentliche Infrastruktur von GitHub.com betroffen war, ergab eine interne forensische Untersuchung keine Hinweise auf eine Ausnutzung in freier Wildbahn oder Indikatoren für eine Kompromittierung (IoC).

Der OPENVAS ENTERPRISE FEED enthält eine Erkennung auf Paketebene für GitHub Enterprise Server. Benutzer sollten auf die Versionen 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7 oder 3.19.4 von GitHub Enterprise Server aktualisieren.

Linux-Sicherheitslücken April 2026: Kritische CVEs in PackageKit, etcd, Vim und Flatpak

CVE-2026-41651 (Pack2TheRoot): Privilegieneskalation auf Root über Linux PackageKit

PackageKit ist die D-Bus-API auf Systemebene zur Verwaltung von Softwarepaketen über verschiedene Linux-Paketmanager hinweg, darunter APT, DNF, RPM und Pacman. CVE-2026-41651 (CVSS 8.8), auch „Pack2TheRoot“ genannt, ist eine Angriffskette, die drei separate Fehler zu einer ausnutzbaren Time-of-Check-Time-of-Use (TOCTOU)-Race-Condition kombiniert [CWE-367]. Die Schwachstelle ermöglicht es letztlich nicht-privilegierten Benutzern, beliebige Pakete als Root zu installieren.

Telekom Security hat eine technische Beschreibung veröffentlicht, einschließlich eines detaillierten PoC-Exploits. Weitere PoC-Exploits sind ebenfalls online zu finden [1][2], und weltweit wurden mehrere nationale CERT-Warnungen herausgegeben [1][2][3]. Der OPENVAS ENTERPRISE FEED enthält eine Erkennung für CVE-2026-41651, wie in den Linux-Sicherheitshinweisen berichtet. Betroffen sind die PackageKit-Versionen 1.0.2 bis 1.3.4, und Benutzer sollten auf Version 1.3.5 aktualisieren.

CVE-2026-33413: Authentifizierungsumgehung in etcd gefährdet Kubernetes-nahe Cluster

etcd ist ein verteilter Schlüssel-Wert-Speicher, der für die autoritative Datenkoordination in Linux-Umgebungen entwickelt wurde. CVE-2026-33413 (CVSS 8.8) ist eine Schwachstelle durch fehlende Autorisierung [CWE-862] in etcd-Clustern, bei denen auth aktiviert ist. Die Schwachstelle ermöglicht es Angreifern, auf sensible etcd-Funktionen in Clustern zuzugreifen, die die gRPC-API für nicht vertrauenswürdige oder teilweise vertrauenswürdige Clients offenlegen. RCE wird nicht als potenzielle Auswirkung von CVE-2026-33413 beschrieben. Ein Angreifer kann jedoch die Cluster-Topologie ermitteln, einschließlich der Member-IDs und der veröffentlichten Endpunkte, historische Revisionen dauerhaft entfernen, Watch-, Audit- und Wiederherstellungs-Workflows stören oder Denial-of-Service-Zustände (DoS) auslösen.

etcd wird häufig mit Kubernetes in Verbindung gebracht, wo es den autoritativen Status des Clusters speichert, einschließlich Knoten, Pods, Secrets und Metadaten der Steuerungsebene. Da Kubernetes jedoch nicht auf die in etcd integrierte Authentifizierung und Autorisierung zurückgreift, sind typische Kubernetes-Bereitstellungen nicht betroffen.

Deutschland [1] und Frankreich [2] haben nationale CERT-Hinweise zu dieser Schwachstelle herausgegeben. Greenbone enthält eine Remote-Banner-Versionsprüfung zur Erkennung exponierter etcd-Dienste, die von CVE-2026-33413 betroffen sind. Die etcd-Versionen 3.4.42, 3.5.28 und 3.6.9 enthalten einen Patch für CVE-2026-33413.

CVE-2026-34714: Manipulierte Dateien ermöglichen Befehlsausführung in Vim

CVE-2026-34714 (CVSS 8.6) ermöglicht die Ausführung beliebiger Betriebssystembefehle, wenn ein Benutzer eine speziell gestaltete Datei öffnet. Diese Befehle werden mit den Berechtigungen des Benutzers ausgeführt, der die Datei geöffnet hat. CVE-2026-34714 wird als Befehlsinjektionsfehler klassifiziert, der durch die unsachgemäße Neutralisierung spezieller Elemente verursacht wird [CWE-78].

Es gibt keinen öffentlichen PoC-Exploit für CVE-2026-34714, und es wird nicht davon ausgegangen, dass die Schwachstelle in freier Wildbahn ausgenutzt wird. Der OPENVAS ENTERPRISE FEED enthält eine Erkennung für CVE-2026-34714 , wie in Linux-Sicherheitshinweisen berichtet. Die Schwachstelle trat erstmals in Version 9.1.1390 auf und wurde in Version 9.2.0172 behoben.

CVE-2026-34078 (CVSS 10): Vollständiger Sandbox-Escape durch bösartige Flatpak-Apps

CVE-2026-34078 (CVSS 10) ist ein vollständiger Sandbox-Escape des Flatpak-Run-Prozesses, der durch eine ausnutzbare TOCTOU-Race-Condition [CWE-367] verursacht wird, wenn als „sandbox-expose“-Optionen angegebene Dateipfade nach der Überprüfung durch Symlinks ersetzt werden. Sobald „flatpak run“ den ausgetauschten Symlink in der Sandbox einbindet, kann eine bösartige App beliebige Dateien auf dem Host lesen und schreiben und diese unbefugten Privilegien ausnutzen, um Codeausführung zu erlangen.

Es gibt keinen öffentlichen PoC-Exploit für CVE-2026-34078, und es wird nicht davon ausgegangen, dass die Schwachstelle in freier Wildbahn ausgenutzt wird. Der OPENVAS ENTERPRISE FEED enthält eine Erkennung für CVE-2026-34078, wie in den Linux-Sicherheitshinweisen berichtet. Flatpak sollte auf Version 1.16.4 aktualisiert werden.

Microsoft Patch Tuesday April 2026: 173 CVEs, zwei Zero-Days aktiv ausgenutzt

Ein umfangreicher Patch Tuesday umfasste 173 neue Sicherheitslücken in den Kernprodukten von Microsoft. Neunzehn wurden als „Exploitation More Likely“ eingestuft, und zwei wurden umgehend in die KEV-Liste der CISA aufgenommen. Eine weitere kritische Schwachstelle, CVE-2026-40372 (CVSS 9.1), wurde außerhalb des regulären Zeitplans offengelegt. Zudem hat ein verärgerter Sicherheitsforscher den koordinierten Offenlegungsprozess mit Microsoft abgebrochen und PoC-Exploit-Code für eine ansonsten nicht offengelegte und ungepatchte Schwachstelle veröffentlicht.

Werfen wir einen Blick auf einige dieser neuen, hochriskanten Microsoft-Sicherheitslücken:

• CVE-2026-33825 (CVSS 7.8, EPSS ≥ 87. Perzentil): Eine lokale Rechteausweitung (LPE) in Microsoft Defender ermöglicht es einem lokalen Benutzer, Berechtigungen auf SYSTEM-Ebene zu erlangen. Die als „BlueHammer“ bezeichnete Schwachstelle wurde Berichten zufolge von einem verärgerten Sicherheitsforscher offengelegt, zusammen mit einem PoC-Exploit. Technische Analysen wurden ebenfalls veröffentlicht [1][2]. BlueHammer wird in der Wildnis ausgenutzt und wurde die KEV-Liste der CISA aufgenommen. Zwei weitere Zero-Days, die von dem verärgerten Forscher offengelegt wurden und die Namen RedSun und UnDefend tragen, sind von Microsoft nach wie vor ungepatcht, obwohl es PoC-Exploits gibt [3][4] und sie bei aktiven Angriffen beobachtet wurden.
• CVE-2026-32201 (CVSS 6.5): Eine neue aktiv ausgenutzte Schwachstelle in Microsoft SharePoint Server, verursacht durch eine unsachgemäße Eingabevalidierung [CWE-20], ermöglicht es einem unbefugten Angreifer, Spoofing über ein Netzwerk durchzuführen. Technische Details zu CVE-2026-32201 sind nicht öffentlich verfügbar, und es existiert kein öffentlicher PoC-Exploit. Frühere SharePoint-Schwachstellen wurden bereits von hochentwickelten staatlich gestützten Angreifern ausgenutzt [5][6][7]. CVE-2026-32201 folgt kurz auf eine weitere SharePoint Schwachstelle, CVE-2026-20963 (CVSS 9.8, EPSS ≥ 90. Perzentil), die im April 2026 in die KEV der CISA aufgenommen wurde.
• CVE-2026-32202 (CVSS 4.3, EPSS ≥ 92. Perzentil): Ein Fehler im Schutzmechanismus [CWE-693] in der Windows-Shell ermöglicht es einem unbefugten Angreifer, die Sicherheitskontrollen von Microsoft Defender aus der Ferne zu umgehen. Die Schwachstelle wurde in die KEV-Liste der CISA Ein detaillierter technischer Bericht von Akamai zeigt, dass CVE-2026-32202 ein unvollständiger Patch für CVE-2026-21510 (CVSS 8.8) ist, der bereits von APT-28 aktiv ausgenutzt wurde.
• CVE-2026-40372 (CVSS 9.1): Änderungen, die in Version 10.0.6 des AspNetCore.DataProtection-Pakets in .NET Core eingeführt wurden, führten bei einigen Benutzern zu Fehlern bei der Entschlüsselung von Geheimnissen [8][9]. Nach einer Untersuchung stellte Microsoft fest, dass das Update es unbefugten Angreifern auch ermöglicht, über ein Netzwerk Berechtigungen zu erweitern. Technische Details zu CVE-2026-40372 sind nicht öffentlich verfügbar, und es existiert kein öffentlicher PoC-Exploit. Die Versionen 10.0.0 bis 10.0.6 sind von CVE-2026-40372 betroffen, und Benutzer sollten die .NET Core-Laufzeitumgebung auf Version 10.0.7 und das .NET Core SDK auf Version 10.0.107 oder 10.0.203 aktualisieren.

Der OPENVAS ENTERPRISE FEED von Greenbone umfasst die Erkennung aller oben genannten Microsoft-CVEs sowie regelmäßig aktualisierte, speziell auf Microsoft-Produkte ausgerichtete Familien von Erkennungstests.

CVE-2026-2699 (CVSS 9.8): Nicht authentifizierte RCE in Progress ShareFile – PoC verfügbar

CVE-2026-2699 (CVSS 9.8, EPSS ≥ 96. Perzentil) ermöglicht nicht authentifizierten Lese- und Schreibzugriff auf eingeschränkte Konfigurationsseiten auf dem Progress ShareFile Storage Controller. Die Schwachstelle ermöglicht das Ändern von Systemkonfigurationen und potenziell nicht authentifizierte RCE. CVE-2026-2701 (CVSS 8.8, EPSS ≥ 70. Perzentil) hat ähnliche Auswirkungen für authentifizierte Benutzer; ein authentifizierter Angreifer kann eine schädliche Datei hochladen und ausführen, was zu RCE führen kann.

Die Produkte von Progress Software waren in der Vergangenheit häufig Ziel von Ransomware-Angriffen [1][2][3][4]. Obwohl noch keine der beiden CVEs als aktiv ausgenutzt gilt, hat watchTowr Labs einen vollständigen technischen Bericht veröffentlicht , der beide CVEs abdeckt und PoC-Exploit-Code enthält. Daten von ShadowServer zeigen, dass sich die Mehrheit der öffentlich exponierten Instanzen auf die Vereinigten Staaten konzentriert. Italien [5] und Frankreich [6] haben CERT-Warnungen für die beiden neuen CVEs herausgegeben.

Der OPENVAS ENTERPRISE FEED enthält eine Remote-Exploitability-Prüfung für CVE-2026-2699 und eine Remote-Banner-Prüfung, die sowohl CVE-2026-2699 als auch CVE-2026-2701 abdeckt. Alle Versionen des Progress ShareFile StorageZones Controllers vor 5.12.4 sind betroffen.

CVE-2025-59528 (CVSS 10): Code-Injection in Flowise wird aktiv ausgenutzt

CVE-2025-59528 (CVSS 10, EPSS ≥ 99. Perzentil) ist eine Code-Injection-Sicherheitslücke [CWE-94], die Flowise vor Version 3.0.6 betrifft. Benutzerdefinierte Konfigurationseinstellungen aus dem CustomMCP-Knoten werden direkt an den Function()-Konstruktor übergeben, der JavaScript-Ausdrücke ohne Sicherheitsüberprüfung ausführt. CustomMCP läuft mit Node.js-Laufzeitrechten und hat Zugriff auf gefährliche Module wie child_process und fs.

CVE-2025-59528 wurde im September 2025 offengelegt, doch die Schwachstelle erlangte diesen Monat unter [1][2][3] größere Aufmerksamkeit, als berichtet wurde, dass sie aktiv ausgenutzt wird. Bemerkenswert ist, dass der Anbieter zum Zeitpunkt der Veröffentlichung PoC-Exploit-Code offenlegte. Der OPENVAS ENTERPRISE FEED enthält seit der Veröffentlichung eine Remote-Banner-Versionsprüfung für CVE-2025-59528 sowie zahlreiche Tests für andere Flowise-CVEs und ein Produkt-Erkennungsmodul für Flowise. Benutzer sollten auf Version 3.0.6 aktualisieren.

CVE-2026-33785: Authentifizierte RCE-Schwachstelle in Juniper Networks Junos OS (MX-Serie)

CVE-2026-33785 (CVSS 8.8) ermöglicht es einem lokalen, authentifizierten Benutzer mit geringen Berechtigungen, gefährliche Befehle über die CLI auf dem Juniper Networks Junos OS der MX-Serie auszuführen. Eine Ausnutzung könnte zu einer vollständigen Kompromittierung der verwalteten Geräte führen. Die Ursache ist eine fehlende Autorisierung [CWE-862] für csds-Anfragen, die nur von Benutzern mit hohen Berechtigungen ausgeführt werden dürfen.

CVE-2026-33785 wird nicht als aktiv ausgenutzt angesehen, und PoC-Exploit-Code ist nicht öffentlich verfügbar. Der OPENVAS ENTERPRISE FEED enthält eine Remote-Banner-Versionsprüfung für CVE-2026-33785 sowie eine Erkennungsreihe für viele weitere Schwachstellen in Produkten von Juniper Networks. CVE-2026-33785 betrifft Junos OS auf der MX-Serie, 24.4-Versionen vor 24.4R2-S3 und 25.2-Versionen vor 25.2R2. Dieses Problem betrifft keine Junos OS-Versionen vor 24.4.

CVE-2026-3502 (TrueChaos): Supply-Chain-Angriff auf TrueConf-Clients in Südostasien

CVE-2026-3502 (CVSS 7.8, EPSS ≥ 85. Perzentil) ermöglicht es einem Angreifer, der den Übertragungsweg von Updates an TrueConf-Client-Anwendungen beeinflussen kann, ein manipulierte Update-Payload einzuschleusen und auszuführen. TrueConf ist eine Produktfamilie für Videokonferenzen und Unified Communications, die häufig vor Ort in privaten Netzwerken für sichere, souveräne Kommunikation eingesetzt wird.

CVE-2026-3502 wurde in die KEV-Liste der CISA aufgenommen, und Check Point veröffentlichte Details zu mindestens einer Angriffskampagne mit dem Namen „TrueChaos“, die auf Regierungsbehörden eines nicht namentlich genannten südostasiatischen Landes abzielte. Das manipulierte Update aktualisierte den Client des Opfers sogar von 8.5.1 auf 8.5.2, um keinen Verdacht zu erregen.

Der OPENVAS ENTERPRISE FEED von Greenbone enthält eine authentifizierte Registrierungsprüfung zur Identifizierung anfälliger Installationen des TrueConf-Clients. Alle Versionen vor 8.5.3.884 sind betroffen, und Benutzer sollten den TrueConf-Client auf Version 8.5.3.884 oder höher aktualisieren.

Fazit: KI verändert das Schwachstellenmanagement – was Sicherheitsteams jetzt tun müssen

Die KI-gestützte Erkennung von Sicherheitslücken hat zu einem rasanten Anstieg der monatlich veröffentlichten CVEs geführt. Dieser Anstieg spiegelt eine Kombination aus KI-Fehlern und legitimen, kritisch eingestuften Schwachstellen in weit verbreiteter Unternehmenssoftware. Anthropics Mythos könnte zu weiteren Offenlegungen mit erheblichen Auswirkungen führen, doch bislang fehlen dafür konkrete Belege. Das SANS Institute und die CSA haben Unternehmen geraten, ihre Anstrengungen im Bereich der zentralen Cybersicherheitskontrollen zu verdoppeln.

Sicherheitsverantwortliche sollten kontinuierliche Schwachstellenmanagement-Programme einsetzen, um das Risiko zu minimieren. OPENVAS SCAN liefert mit dem OPENVAS ENTERPRISE FEED eine branchenführende Abdeckung von Sicherheitslücken. Greenbone entwickelt monatlich Tausende neue Schwachstellentests, um Fehler in Unternehmenssoftwareanwendungen, IT-Netzwerkprodukten, gängigen Betriebssystemen und Browsern, Linux-Paketen, Produktivitätswerkzeugen, agentenbasierten KI-Tools und vielem mehr aufzudecken. Sicherheitsverantwortliche, die Schwachstellen aufspüren und Schutzmaßnahmen ergreifen möchten, können Greenbones Einstiegsprodukt OPENVAS BASIC kostenlos testen, einschließlich einer zweiwöchigen Testversion des ENTERPRISE FEED.