Welche Anforderungen der Cyber Resilience Act zum 11. September 2026 stellt, haben wir bereits in einem eigenen Beitrag zum Umsetzungsstand der CRA-Meldepflicht erläutert. Dieser Beitrag beantwortet die andere Hälfte der Frage: wie die Umsetzung bei Greenbone selbst erfolgt ist.

Eine Einordnung vorweg, weil sie für die Übertragbarkeit entscheidend ist: Wir haben nicht alle Maßnahmen neu implementiert. Vieles davon war bei uns schon vorher etablierte Praxis und musste für den CRA lediglich dokumentiert, geschärft oder in einen verbindlichen Prozess überführt werden. Wer heute vor derselben Aufgabe steht, findet im eigenen Haus vermutlich mehr Substanz als erwartet.

Anforderung: ein Prozess für Schwachstellen und Vorfälle

Der CRA verlangt keinen Meldeknopf, sondern einen belastbaren Prozess dahinter. Neben dem Prozess zur Behandlung von Incidents haben wir deshalb einen Prozess zur Coordinated Vulnerability Disclosure implementiert. Darin ist das Vorgehen bei Bekanntwerden einer Schwachstelle im Detail geregelt, inklusive der Zuständigkeiten. Dazu gehört eine Checkliste, die man Schritt für Schritt durchgehen kann. Sicherheitsvorfälle bilden wir in einem eigenen Jira-Projekt ab, so dass jeder Fall einen Vorgang mit Historie hat.

Der Prozessgedanke ist an einer Stelle besonders wichtig: Die 24-Stunden-Uhr des Artikels 14 beginnt mit der Kenntniserlangung, und was das genau heißt, hat die Kommission in ihrer im Juli 2026 gebilligten Leitlinie zur Anwendung des CRA (C(2026) 5252) präzisiert. Maßstab ist ein „hinreichender Grad an Gewissheit“ unter Verweis auf Erwägungsgrund 31 der Durchführungsverordnung (EU) 2024/2690 und die EDSA-Leitlinien 9/2022 (Rn. 211–214). Ohne einen definierten Triage-Schritt lässt sich dieser Punkt im Ernstfall nicht datieren, und ohne Datum ist die Frist nicht nachweisbar eingehalten. Zu beachten ist, dass diese Leitlinie ausdrücklich nicht bindend ist (Rn. 8); sie ist Auslegungshilfe, nicht Rechtsgrundlage.

Zwei Fristen sollte man im Prozess getrennt führen, weil sie unterschiedlich laufen: Der Abschlussbericht für eine Schwachstelle ist 14 Tage nach Bereitstellung des Fixes fällig, der für einen schwerwiegenden Sicherheitsvorfall dagegen einen Monat nach der 72-Stunden-Meldung (Rn. 215). Wer beide Uhren in einem Feld abbildet, meldet in einem der beiden Fälle zu spät.

Entlastend, und in der aktuellen Debatte oft übersehen: Für Schwachstellen, die bereits vor dem 11. September 2026 bekannt waren, entsteht keine rückwirkende Meldepflicht (Rn. 217). Der Bestand muss also nicht nachgemeldet werden.

Anforderung: Schwachstellen in Fremdkomponenten weitergeben

Stammt eine Lücke in unseren Produkten aus einem Artefakt Dritter, benachrichtigen wir dessen Anbieter, damit sie dort behoben wird. Implementieren wir selbst einen Fix, machen wir diesen upstream verfügbar.

Das deckt sich mit Abschnitt 9.2.1 der Kommissionsleitlinie zu Artikel 13(6): Wer eine Fremdkomponente integriert, muss Schwachstellen an die pflegende Stelle melden, sofern diese nicht bereits Kenntnis hat, und sollte Korrekturen möglichst maschinenlesbar und lizenzkompatibel teilen. Ebenfalls klargestellt: Die Meldepflicht selbst greift für aktiv ausgenutzte Schwachstellen im eigenen Produkt, nicht für jede nicht ausgenutzte Lücke in einer Fremdkomponente (Rn. 218).

Anforderung: Betroffene erreichbar informieren

Für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die sich auf die Sicherheit unserer Produkte auswirken können, veröffentlichen wir Advisories im CSAF-Format unter dem bekannten Pfad, bis auf eventuelle Ausnahmen unter TLP:WHITE. Bei schwerwiegenden Sicherheitslücken, die aus unserem eigenen Code stammen, beantragen und veröffentlichen wir eine CVE.

Warum maschinenlesbar? Weil ein Advisory, das nur als Webseite existiert, bei den Empfängern Handarbeit auslöst. Wer wissen will, welche Rollen im CSAF-Ökosystem welche Pflichten haben, findet die Einordnung in unserem Beitrag zu den CSAF-2.0-Stakeholdern und -Rollen.

Wichtig für die Erwartungshaltung: Die Pflicht aus Artikel 14(8), Nutzende zu informieren, ist risikobasiert und verhältnismäßig ausgestaltet und keine pauschale Pflicht zur öffentlichen Offenlegung jedes Vorgangs (Rn. 219–221). Was zu veröffentlichen ist, richtet sich nach dem Fall, nicht nach einem Automatismus. Unsere Ausnahmeregelung von TLP:WHITE ist genau dafür vorgesehen.

Was nur ein Scanner-Hersteller tun kann

Bei schwerwiegenden Sicherheitslücken in unseren Produkten erstellen wir zusätzlich einen Schwachstellentest, so dass OPENVAS SCAN die Verwundbarkeit entdeckt und meldet. Dieser Baustein ist ausdrücklich nicht zum Nachmachen gedacht: Er setzt voraus, dass man selbst Hersteller eines Schwachstellenscanners ist. Für unsere Kundschaft heißt er, dass sie die Betroffenheit der eigenen Installation nicht aus einem Advisory ableiten muss, sondern messen kann.

Anforderung: reagieren, nicht nur melden

Je nach Schwere einer Lücke erstellen wir ein Notfallrelease und stellen es der Kundschaft zur Verfügung. Nach Bearbeitung einer Schwachstelle erfolgt eine Post-Mortem-Analyse.

Anforderung: erreichbar sein für Meldungen von außen

Damit Personen, die eine Schwachstelle entdecken, uns erreichen, gibt es auf der Greenbone-Website eine Seite zum Thema Meldung von Schwachstellen in Produkten, außerdem eine security.txt nach RFC 9116.

Ein Tipp aus der Praxis, der nichts kostet und viel spart: Prozesse testen, damit man nicht erst im Ernstfall merkt, wenn etwas nicht funktioniert wie gedacht.

Offen ist bei uns noch das Testen einer Meldung an ENISA. Wie im vorherigen Beitrag beschrieben, gibt es die Plattform noch nicht in finaler Form. Diesen Punkt können wir vorbereiten, aber nicht abschließen.

Anforderung: die eigene Lieferkette kennen

Ein weiterer Bestandteil unserer Vorbereitung auf den 11. September 2026 ist, dass wir im Buildprozess automatisiert SBOMs unserer Produkte erstellen. Hier kommt OPENVAS SECURITY INTELLIGENCE ins Spiel, womit wir die SBOMs auf Schwachstellen scannen. Durch den täglich aktualisierten Metafeed können Schwachstellen in verwendeten Komponenten frühzeitig behandelt werden, so dass es gar nicht erst zu einer Ausnutzung in freier Wildbahn kommt.

Des Weiteren bietet es sich an, die Advisories seiner Zulieferer regelmäßig zu überprüfen, um frühzeitig auf gefixte Versionen updaten zu können. Immer mehr Hersteller stellen ihre Advisories im CSAF-Format bereit; das ist auch die vom BSI präferierte Methode, festgehalten in der Technischen Richtlinie BSI TR-03191 und in der Empfehlung des BSI zum Einsatz von CSAF. Auch hier bietet es sich an, OPENVAS SECURITY INTELLIGENCE zu verwenden, womit CSAF-Advisories, auch solche mit Zugangsbeschränkung, regelmäßig heruntergeladen und analysiert werden können, zum Beispiel jede Nacht oder auch stündlich.

Checkliste: Wo stehen Sie bei der CRA-Meldepflicht?

Selbst-Check: Wo stehen Sie?

• Ein Coordinated-Vulnerability-Disclosure-Prozess mit klaren Zuständigkeiten ist etabliert
• Schwachstellen in Fremdkomponenten werden an die pflegende Stelle weitergegeben
• Betroffene werden über maschinenlesbare Advisories (z. B. CSAF) informiert
• Es gibt einen definierten Prozess für Notfallreleases und Post-Mortem-Analysen
• Externe können Schwachstellen leicht melden (Kontaktseite, security.txt)
• SBOMs werden automatisiert erstellt und auf Schwachstellen überwacht

Was davon für Sie übertragbar ist

Der Aufwand für den 11. September 2026 verteilt sich ungleich. Die Meldewege selbst, security.txt, Kontaktseite, CSAF-Pfad, sind vom Aufwand her überschaubar. Der Prozess dahinter mit Zuständigkeiten, Checkliste und dokumentierter Triage braucht länger und entscheidet darüber, ob eine 24-Stunden-Frist tatsächlich haltbar ist. Und die Lieferkette braucht Automatisierung, weil eine manuell gepflegte Komponentenliste in dem Moment veraltet ist, in dem sie fertig ist.

Für die beiden letzten Punkte laufen bei uns SBOM-Scan und Zulieferer-Advisories in OPENVAS SECURITY INTELLIGENCE zusammen: eine Analyse an einem Ort, statt Feeds, Tabellen und Advisory-Seiten getrennt zu verfolgen.

Wenn Sie Ihre eigene Umsetzung gegen diese Punkte halten wollen, führen von hier zwei Wege weiter. Unsere Übersicht zum Cyber Resilience Act fasst Anforderungen, Fristen und Betroffenheit zusammen, falls Sie sich das Thema zuerst selbst erschließen möchten. Und wenn bei Ihnen ein oder mehrere Punkte aus der Checkliste oben noch offen sind — sei es der CVD-Prozess, maschinenlesbare Advisories oder automatisierte SBOMs — sprechen Sie direkt mit uns darüber.

 

Zwei Wochen vor dem Inkrafttreten der Meldepflicht gemäß Artikel 14 befindet sich die dahinterstehende Infrastruktur noch im Aufbau. Die Leitlinien der Kommission sind zwar genehmigt, aber noch nicht offiziell in Kraft getreten. Die Meldeplattform befindet sich in der Testphase und ist noch nicht live. Kein einziger harmonisierter Standard ist im Amtsblatt veröffentlicht.

Jede dieser Lücken legt noch mehr Gewicht auf die eine Kontrollmöglichkeit, die vollständig in Ihrer Hand liegt, unabhängig davon, was Brüssel, die ENISA oder die Normungsgremien als Nächstes tun: zu wissen, was tatsächlich in Ihrer Umgebung läuft und ob es ausgenutzt wird. Genau darauf ist OPENVAS ausgelegt.

Die Leitlinien der Kommission sind erschienen

Am 27. Juli 2026 hat die Europäische Kommission ihre ersten offiziellen Leitlinien zur Anwendung des CRA genehmigt: Mitteilung C(2026) 5252 final, mit einem umfassenden Anhang, der den Anwendungsbereich, freie und Open-Source-Software, wesentliche Änderungen, Supportzeiträume und Berichtspflichten abdeckt. Artikel 26 der Verordnung verlangt genau dies: Leitlinien, die gezielt darauf abzielen, Kleinstunternehmen und KMU bei der Einhaltung der Vorschriften zu unterstützen, und der Anhang liefert dies mit 67 ausgearbeiteten Beispielen.

Die formelle Verabschiedung erfolgt, sobald alle Sprachfassungen in den EU-Sprachen vorliegen. Hier der Wortlaut der Kommission zu diesem Punkt: Die Leitlinien „werden zu einem späteren Zeitpunkt, wenn alle Sprachfassungen vorliegen, von der Kommission formell verabschiedet. Erst ab diesem Zeitpunkt treten sie in Kraft.“ Der Inhalt steht fest. Die Formalitäten werden noch abgewickelt.

Die Einstufung hängt von der tatsächlichen Kernfunktionalität Ihres Produkts ab, nicht von dessen Namen oder dem Werbetext. Die Ausnahmeregelungen für FOSS funktionieren so, wie es der Leitlinienentwurf bereits Anfang des Jahres signalisiert hatte. Wir haben die Open-Source-Bestimmungen in einem separaten Beitrag ausführlich behandelt, da die Frage, was als „Steward“ gilt und welche Verpflichtungen diese Rolle mit sich bringt, eine eigene Erörterung verdient.

Die vorliegenden Leitlinien beseitigen jegliche Ausrede dafür, die Einhaltung der CRA als rein theoretisch zu betrachten. Die Kommission hat schriftlich dargelegt, was die Vorschriften bedeuten, und zwar nach einem Zeitplan, der mit der stufenweisen Anwendbarkeit der Verordnung selbst übereinstimmt: Kapitel IV ab dem 11. Juni 2026, Berichterstattung gemäß Artikel 14 ab dem 11. September 2026, vollständige Anwendung ab dem 11. Dezember 2027.

Die Meldeplattform wird derzeit noch getestet

Die Meldepflichten gemäß Artikel 14 werden am 11. September 2026, also in zwei Wochen, rechtsverbindlich. Die einheitliche Meldeplattform der ENISA soll laut ENISA-Angaben bis zu diesem Datum betriebsbereit sein, nicht unbedingt schon vorher. Die Seite der Europäischen Kommission zu den Meldepflichten bestätigt, dass derzeit Funktions- und Sicherheitstests durchgeführt werden. ENISA wird die spezielle URL der Plattform veröffentlichen, sobald diese bereit ist – nicht vorher.

Anleitungen zur Registrierung als „beauftragter Vertreter“ werden seit dem 31. Juli schrittweise bereitgestellt, wobei die Aktualisierungen bis Ende August andauern. Die Validierung Ihres registrierten Vertreters durch das CSIRT erfolgt parallel zur Meldung und stellt keine Vorbedingung dar. Der grenzüberschreitende Informationsaustausch zwischen den CSIRTs erfolgt automatisch, sobald eine Meldung eingeht. Die ENISA selbst rät dazu, sich erst dann zu registrieren, wenn Sie eine konkrete Meldung einreichen müssen, und nicht vorher.

Eine Plattform, die bis zum Tag des Inkrafttretens betriebsbereit sein soll, sich aber zwei Wochen vor diesem Termin noch in der Testphase befindet, lässt wenig bis gar keinen Spielraum für Probleme bei der Einarbeitung. Lesen Sie jetzt die Registrierungsschritte. Machen Sie sich mit dem Meldeverfahren vertraut, bevor Sie es unter Zeitdruck innerhalb von 24 Stunden durchführen müssen.

Die Normen, auf die die Hersteller gesetzt haben, sind noch nicht veröffentlicht

Stand Ende August 2026 ist im Amtsblatt für keine Produktkategorie ein Verweis auf eine harmonisierte CRA-Norm zu finden. Der zugrunde liegende Auftrag ist klar: Normungsantrag M/606, 41 Normen für horizontale und vertikale Kategorien, angenommen von CEN, CENELEC und ETSI im Rahmen des Durchführungsbeschlusses C(2025) 618 final der Kommission vom 3. Februar 2025.

Die ursprünglichen Fristen gliederten sich in drei Teilbereiche. Typ A, die Rahmenprinzipien, die für sich genommen keine Konformitätsvermutung begründen, sowie der Teil von Typ B, der sich mit dem Umgang mit Schwachstellen befasst, waren bis zum 30. August 2026 fällig. Typ C, die vertikalen, produktspezifischen Normen für die Kategorien der Anhänge III und IV, war bis zum 30. Oktober 2026 fällig. Ein dritter Termin liegt noch weiter in der Zukunft: der 30. Oktober 2027 für die andere Hälfte von Typ B, die produktübergreifende Norm, die die 13 grundlegenden Anforderungen in Anhang I, Teil 1 konkretisieren soll – jene, auf die sich die meisten Hersteller außerhalb der Kategorien der Anhänge III und IV tatsächlich stützen würden, um die Konformitätsvermutung zu erlangen. Dieser Termin stammt aus der eigenen Planung der CRA-Expertengruppe, wie von einem Mitglied der CRA-Expertengruppe beschrieben. Er ist in keinem veröffentlichten Beschluss der Kommission erschienen.

Die Kommission veröffentlichte Anfang Juli 2026 einen Entwurf zur Änderung der Fristen für 2026, wodurch die Termine für Typ A, den Umgang mit Sicherheitslücken und Typ C um etwa zwei Monate nach hinten verschoben wurden: auf den 31. Oktober 2026 bzw. den 31. Dezember 2026. Ob sich auch der Termin für die andere Hälfte von Typ B im Jahr 2027 verschiebt, ist noch nicht bestätigt. Diese Änderung wurde noch nicht offiziell verabschiedet und ist noch nicht im Amtsblatt veröffentlicht (Entwurf des Durchführungsbeschlusses; CRA Evidence).

Aktueller Stand: 17 vertikale ETSI-Entwürfe befinden sich in der öffentlichen Anhörung, wobei die Kommentierungsfristen zwischen Mitte September und Mitte November enden. Die horizontalen Normen von CEN und CENELEC befinden sich noch in der Entwicklung.

Für Hersteller „wichtiger“ Produkte der Klasse I (VPNs, Passwortmanager, Browser und ähnliche Kategorien), die eine Selbstbewertung anhand einer veröffentlichten harmonisierten Norm planen, gibt es bislang noch keine Anhaltspunkte, und die Norm, auf die die meisten von ihnen tatsächlich zurückgreifen würden – nämlich die produktübergreifende Typ-B-Norm, die alle 13 grundlegenden Anforderungen des Anhangs I abdeckt –, soll erst 2027 vorliegen, unabhängig davon, wie sich die Verzögerung bis 2026 auflöst.

Kapitel IV hat den Mitgliedstaaten die Möglichkeit eröffnet, am 11. Juni 2026 Konformitätsbewertungsstellen offiziell zu benennen. Das Ziel der Kommission für eine ausreichende Kapazität der benannten Stellen ist Dezember 2026, und sie beschreibt dieses Ziel ausdrücklich als „Best-Efforts“-Zielsetzung, nicht als Garantie. Die Benennung begann vor drei Monaten. Richten Sie Ihren Zeitplan für die Bewertung danach aus.

Die Abkürzung über die Normen verzögert sich. Der Weg über benannte Stellen ist ein System, das sich noch im Aufbau befindet. Planen Sie beides ein.

Keine dieser Lücken muss Ihre eigenen Vorbereitungen zum Stillstand bringen. Die Arbeiten an der Dokumentation, der Risikobewertung und dem Schwachstellenmanagement, die bei jeder Selbstbewertung oder jedem Audit durch Dritte letztendlich überprüft werden, warten nicht darauf, dass einer der beiden Wege frei wird. OPENVAS legt diese Grundlagen bereits jetzt: ein täglich aktualisierter Feed, CVSS-basierte Priorisierung sowie ein exportierbarer, mit Zeitstempeln versehener Scan-Verlauf – genau die Nachweiskette, die eine benannte Stelle oder eine zukünftige harmonisierte Norm erwarten wird.

Was das für Sie bedeutet

Nichts von alledem ist ein Grund zum Abwarten. Ganz im Gegenteil. Die Teile der CRA, die von der Kommission, der ENISA oder den europäischen Normungsgremien abhängen, sind noch in Arbeit. Die Teile, die von Ihnen abhängen – zu wissen, was sich in Ihrem Produktportfolio befindet, aktive Ausnutzung zu erkennen und auf Anfrage eine datierte Nachweiskette vorlegen zu können –, liegen heute vollständig in Ihren Händen.

Die Leitlinien der Kommission definieren den Begriff „Kenntniserlangung“ – den Auslöser für Ihre 24-Stunden-Meldefrist – ganz genau: Ein Hersteller gilt als in Kenntnis gesetzt, sobald er nach der Bewertung eines verdächtigen Vorfalls zu einer angemessenen Gewissheit gelangt ist, dass eine Schwachstelle aktiv ausgenutzt wird. Dieser Standard orientiert sich ausdrücklich an der Schwelle für die Meldung von Datenschutzverletzungen gemäß der DSGVO. Diese Gewissheit erlangen Sie durch aktive Überwachung. Es besteht keine rückwirkende Meldepflicht für Schwachstellen, von denen Sie bereits vor dem 11. September wussten.

Wenden Sie sich damit an den Verantwortlichen für das Budget: kontinuierliches Schwachstellenmanagement ist der einzige Teil dieses Compliance-Gesamtbildes, der heute vollständig in Ihrer Kontrolle liegt. Es ist das, was aus „wir glauben, dass alles in Ordnung ist“ eine datierte Nachweiskette macht, die eine Aufsichtsbehörde oder eine benannte Stelle tatsächlich überprüfen kann. OPENVAS bietet genau das: planmäßige Scans anhand eines täglich aktualisierten Feeds, CVSS-basierte Priorisierung sowie exportierbare, mit Zeitstempeln versehene Berichte, die für sich allein stehen und unabhängig vom Einführungszeitplan einer staatlichen Plattform sind.

Darüber hinaus gibt es noch eine schnellere Ebene, die auf dieser Basis aufbaut. OPENVAS SECURITY INTELLIGENCE erfasst CSAF-Hinweise aus vertrauenswürdigen Quellen, von Anbietern und nationalen Sicherheitsbehörden, und zwar genau für die Produkte in Ihrer Infrastruktur, und gleicht diese mit Ihrem Software-Bestand ab, um zu kennzeichnen, welche Hinweise tatsächlich für Sie relevant sind. Wenn eine 24-Stunden-Meldungsfrist beginnt, ist das der Unterschied zwischen dem manuellen Durchsehen eines Dutzends Hersteller-Hinweisseiten und einer Analyse, die bereits an einem Ort vorliegt.

Zusammenfassung

Die Leitlinien der Kommission sind inhaltlich genehmigt und gelten offiziell, sobald die Übersetzung abgeschlossen ist. Die Meldeplattform, die die Hersteller nutzen sollen, befindet sich noch in der Testphase, zwei Wochen bevor sie verbindlich wird. Die harmonisierten Normen, die den Herstellern eine Abkürzung bei der Selbstbewertung bieten sollten, sind noch nicht im Amtsblatt veröffentlicht, und weder die Verzögerung noch die Situation hinsichtlich der Kapazitäten der benannten Stellen sind vollständig geklärt. Nichts davon ändert etwas daran, was am 11. September fällig ist oder was „Kenntniserlangung“ ab diesem Tag von Ihnen verlangt.

OPENVAS bietet Ihnen den Teil, auf den Sie nicht warten müssen: einen täglich aktualisierten Schwachstellen-Feed, eine CVSS-basierte Priorisierung sowie exportierbare, mit Zeitstempel versehene Scan-Berichte, die Ihre Erkennungslage dokumentieren – unabhängig davon, wie die regulatorische Infrastruktur am ersten Tag aussieht.

Lesen Sie den vollständigen Leitfaden: Der vollständige Leitfaden zum EU-Gesetz zur Cyber-Resilienz – alle Anforderungen, Fristen und Strafen auf einen Blick.

 

Als Wiz kürzlich seine Zusammenfassung der besten Schwachstellenmanagement-Tools für 2026 veröffentlichte, fiel uns etwas auf, das uns jedoch nicht überraschte: OPENVAS belegte einen Spitzenplatz und erhielt eine hervorragende Bewertung. Wiz beschreibt OPENVAS als das „Open-Source-Äquivalent“ zu kommerziellen Schwachstellenscannern. In der Rezension wird OPENVAS als „die umfassendste Abdeckung, die auf einer einzigen Plattform verfügbar ist“ bezeichnet. Wir nehmen das Kompliment gerne an! Es gibt jedoch noch einige Punkte, die wir gerne anfechten möchten, da sie die Greenbone-Geschichte nicht ganz vollständig wiedergeben.

Was Wiz bewertet hat

Wiz hat die kostenlose Community-Edition von OPENVAS SCAN von Greenbone bewertet, was für eine Bewertung von Open-Source-Software-Tools (OSS) angemessen ist. Die Community-Edition unterliegt jedoch den Einschränkungen einer kostenlosen Version. OPENVAS ist auch als End-to-End-Unternehmensprodukt erhältlich. Sehen wir uns die Unterschiede an:

	Community Edition	Enterprise-Produkte
Einrichtung	Installation über Container, Linux-Pakete oder Quellcode	Vorkonfigurierte und optimierte virtuelle und Hardware-Appliances
Erkennungs-Feed	Ausgewählte Sicherheitsprüfungen für Verbraucher und OSS	Erweiterte Liste von OSS wie zusätzliche Linux-Distributionen sowie Cisco, Microsoft, SAP, Fortinet, Citrix und viele weitere Unternehmenssoftwareprodukte
Compliance	IT-Grundschutz	IT-Grundschutz, CIS-Benchmarks, BSI-TR-Richtlinien sowie zusätzliche Richtlinien wie die Post-Quantum-Kryptografie-Richtlinie Scans
Aktualisierungsrhythmus	Regelmäßige Aktualisierungen	Tägliche Aktualisierungen
Service und Support	Freiwillige Mitglieder des Greenbone-Community-Forums	Garantierte Service- und Support-Reaktionszeiten mit einer Service Level Agreement (SLA) sowie Professional Services

Open Source und Unternehmen: Greenbone bietet das „Beste aus beiden Welten“

Einer der größten Vorteile von Greenbone besteht darin, dass Unternehmen sich nicht zwischen Open-Source-Transparenz und einer Bereitstellung auf Unternehmensniveau entscheiden müssen. Greenbone bietet beides: die Transparenz und Flexibilität von Open-Source-Software sowie speziell entwickelte Unternehmenslösungen, die für operative Sicherheitsumgebungen konzipiert sind. Die Offenheit ist entscheidend. Die Transparenz des Quellcodes ermöglicht Einblicke in die OPENVAS SCAN-Technologie. Diese Transparenz vereinfacht Sicherheitsaudits und unabhängige Sicherheitstests.

Das Greenbone-Ökosystem umfasst mehrere Community-Edition-Bereitstellungsoptionen. Benutzer können die Community-Container ausführen, nativ auf Kali Linux installieren oder Komponenten direkt aus dem Quellcode erstellen. Community-Bereitstellungen sind jedoch nur ein kleiner Teil des Greenbone-Produktangebots. Greenbone bietet optimierte Unternehmenslösungen für Organisationen, die kommerziell unterstützte Produkte zum Schwachstellenmanagement benötigen. Unsere Produktpalette umfasst unternehmensgerechte virtuelle Appliances sowie dedizierte Hardware-Appliances.

Sie müssen Nmap nicht separat ausführen

Wiz hebt Nmap zu Recht als robustes Erkundungstool hervor und weist darauf hin, dass Sicherheitsexperten bei Port-Scans auf dieses Tool vertrauen. Nutzer müssen die Nmap-Ergebnisse jedoch nicht in unseren Scanner einspeisen. Das Nmap-Scannen ist bereits in OPENVAS SCAN integriert. Unser Scan-Workflow führt vor der Schwachstellenanalyse eine umfassende Port-Erkennung durch.

OPENVAS SCAN enthält konfigurierbare Optionen für die Port-Erkennung, die Sicherheitsteams entsprechend den Anforderungen der Zielumgebung anpassen können. Es ist nicht notwendig, separate Vorgänge zur Diensterkennung und Schwachstellenerkennung miteinander zu verknüpfen.

Mehr Kontrolle bedeutet eine ausgefeiltere Konfiguration

Wiz behauptet nicht nur, dass OPENVAS über eine „benutzerfreundliche Konsole für intuitive Steuerung“ verfügt, sondern auch, dass OPENVAS eine steile Lernkurve erfordert. Diese Beobachtung mag einen wahren Kern haben. Auf der anderen Seite ist OPENVAS SCAN eine ausgefeilte Sicherheitsplattform mit flexiblen Funktionen. Das Schwachstellenmanagement selbst ist komplex. Wenn Sicherheitsteams mehr Optionen zur Steuerung der Scans erhalten, führt dies zwangsläufig zu mehr Flexibilität als bei einem Scanner, der auf einem vereinfachten Workflow basiert.

OPENVAS SCAN bietet detaillierte Scan-Einstellungen und flexible Optionen zur Konfiguration von Zielen, Scan-Verhalten, Zeitplänen, Anmeldedaten, Ergebnissen und betrieblichen Arbeitsabläufen. Für Unternehmen, die eine Automatisierung oder eine Integration mit praktisch jeder anderen IT-Plattform wünschen, ermöglichen die Greenbone Management Protocol (GMP) und Open Scanner Protocol (OSP)-APIs ermöglichen eine umfassende programmatische Steuerung von OPENVAS SCAN.

Ja, die Beherrschung einer flexiblen Sicherheitsplattform erfordert einen gewissen Lernaufwand. Der Vorteil ist jedoch, dass Sicherheitsverantwortliche die Vielseitigkeit in sehr unterschiedlichen operativen Kontexten nutzen können.

Priorisierung geht über das Auffinden von CVEs hinaus

Das Auffinden von Schwachstellen ist nur der erste Teil des Schwachstellenmanagements. Wiz stellt zu Recht fest, dass die Priorisierung mehr Kontext erfordert als nur den reinen Schweregrad. OPENVAS SCAN liefert bereits wichtige Daten zur Priorisierung, darunter CVSS-Schweregradangaben, EPSS-Werte zur Exploit-Wahrscheinlichkeit sowie den Status des CISA Known Exploited Vulnerabilities (KEV)-Status. Dies hilft Sicherheitsverantwortlichen dabei, den Fokus von der Frage „Welche Schwachstellen gibt es?“ auf die Frage „Welche Schwachstellen verdienen zuerst Aufmerksamkeit?“ zu verlagern. Und weitere Tools zur Risikopriorisierung sind in Vorbereitung!

Ohne bereits jetzt Details preiszugeben, wird Greenbone in Kürze neue Risikomanagement-Funktionen ankündigen, die Sicherheitsverantwortlichen noch bessere Werkzeuge an die Hand geben sollen, um Schwachstellenrisiken zu verstehen, zu organisieren und zu priorisieren.

Branchenführende Abdeckung und eine wachsende Liste von Scan-Tools

Wiz behauptet, dass OPENVAS eine „begrenzte Abdeckung“ habe und „nur grundlegende Endpunkte und Netzwerke scanne“. Der abonnementbasierte Erkennungs-Feed von Greenbone, der OPENVAS ENTERPRISE FEED, bietet jedoch branchenführende Schwachstellenerkennung. Der OPENVAS COMMUNITY FEED bietet unterdessen umfassende Sicherheitsabdeckung für Linux-Umgebungen und viele andere weit verbreitete Open-Source-Anwendungen und Software-Stacks.

OPENVAS SCAN führt nicht lediglich eine Überprüfung der Netzwerkoberfläche einiger weniger Endpunkte durch. Das authentifizierte Scannen dringt tief in den Benutzerbereich ein, um Schwachstellen zu erkennen, die von außen nicht identifiziert werden können. Auch Container müssen ebenso wie andere IT-Ressourcen auf Schwachstellen überprüft werden. OPENVAS SCAN kann Container-Image-Scans durchführen, um ein einzelnes Container-Image, mehrere Container-Images oder ein komplette Registry zu prüfen.

Seit ihrer Gründung im Jahr 2009 hat die Greenbone AG das Open Vulnerability Assessment System, besser bekannt als OpenVAS, kontinuierlich gepflegt und weiterentwickelt. Infolgedessen sind die beiden Namen eng miteinander verbunden: Erwähnt man Greenbone, so ist OpenVAS oft das Erste, was einem in den Sinn kommt. Früher bekannt als der Greenbone Vulnerability Manager (GVM), hat sich auch OPENVAS SCAN kontinuierlich weiterentwickelt. Zu den wichtigen Funktionserweiterungen zählen agentenbasierte und hybride Scans als Ergänzung zum traditionellen agentenlosen, authentifizierten Scan-Modell sowie das Scannen von Container-Images. Zudem steht eine neue Generation von Risikomanagement-Funktionen kurz davor, in den Vordergrund zu rücken. Die Produktpalette von Greenbone wird außerdem um OPENVAS SECURITY INTELLIGENCE, einem neuen Enterprise-Tool für zentralisierte Verwaltung, Risikoanalyse und Priorisierung von Korrekturmaßnahmen in verteilten OPENVAS SCAN-Umgebungen erweitert.

Ja, Windows und Linux, aber noch viel mehr!

Wiz behauptet zudem, dass OPENVAS „in erster Linie für Linux- und Windows-Betriebssysteme optimiert“ sei. Diese Beschreibung lässt jedoch außer Acht, wie flexibel die Bereitstellung von Greenbone tatsächlich ist. OPENVAS SCAN lässt sich in einer Vielzahl von Virtualisierungsumgebungen bereitstellen, darunter Oracle VirtualBox für macOS sowie Typ-1-Hypervisoren wie VMware ESXi, Proxmox Virtual Environment sowie Nutanix AHV.

Zu den von uns unterstützten Hypervisor-Optionen gehören:

• Microsoft Hyper-V, Version 8.0 oder höher
• VMware vSphere Hypervisor (ESXi), Version 7.0 oder höher
• VMware Workstation Pro, Version 17.0 oder höher
• Oracle VirtualBox, Version 7.0 oder höher
• Huawei FusionCompute, Version 8.0
• Proxmox Virtual Environment (VE), Version 8.0 oder höher
• Nutanix AHV, Version 6.8 oder höher

Setzen Sie bereits auf Proxmox VE oder Nutanix AHV? So deckt OPENVAS SCAN Ihren Hypervisor ab.

Ein abschließendes Dankeschön an Wiz!

Sogar Wiz liebt Greenbone! Wir bei Greenbone freuen uns sehr, zu den führenden Technologien im Bereich Schwachstellenmanagement für das Jahr 2026 gezählt zu werden. Die Bewertung von Wiz bestätigt, was viele unserer Kunden und Nutzer bereits wissen: OPENVAS ist die Spitzenlösung unter den branchenführenden Open-Source-Plattformen für das Schwachstellenmanagement. Gerne möchten wir zudem einige Aspekte dieses Gesamtbildes näher erläutern.

Um es klar zu sagen: Die Open-Source-Transparenz von Greenbone geht Hand in Hand mit erstklassiger Einsatzfähigkeit in Unternehmen. Schwachstellenmanagement geht weit über Standard-Scan-Konfigurationen und Scans auf Knopfdruck hinaus. Sicher, OPENVAS SCAN bietet all das. Doch leistungsstarke Konfigurationsoptionen sollten nicht mit unnötiger Komplexität verwechselt werden. Die vorhandenen Tools zur Risikopriorisierung von Greenbone unterstützen Sicherheitsverantwortliche mit zentralen Risikokennzahlen, nachdem Schwachstellen entdeckt wurden.

Freuen Sie sich auf mehrere neue Funktionen, die die Möglichkeiten der Sicherheitsverantwortlichen für ein priorisiertes, risikogesteuertes Schwachstellen- und Expositionsmanagement erweitern werden! Wenden Sie sich an das Vertriebsteam von Greenbone, um zu besprechen, wie Compliance-Scans auf Unternehmensniveau mit OPENVAS SCAN die regulatorischen und sicherheitsbezogenen Governance-Anforderungen Ihrer Organisation am besten unterstützen können.

 

Broadcom hat VMSA-2026-0006 am 29. Juli 2026 veröffentlicht, um fünf Sicherheitslücken zu beheben, die VMware ESX, VMware vCenter Server, VMware Workstation und VMware Fusion betreffen. Die Probleme mit dem höchsten Risiko sind CVE-2026-59309 (CVSS 9,8) sowie CVE-2026-59310 (CVSS 9,8), die VMware vCenter Server betreffen. Beide können von einem nicht authentifizierten Angreifer mit Netzwerkzugriff ausgenutzt werden, um eine Remote-Code-Ausführung (RCE) zu erreichen.

Technische Details zu CVE-2026-59310 und CVE-2026-59309 wurden unmittelbar nach ihrer Offenlegung veröffentlicht, es sind jedoch keine Proof-of-Concept-Exploits öffentlich verfügbar. Am 11. August berichtete Defused Cyber Untersuchungen zu CVE-2026-59309. Die QUIRSO GmbH berichtet, dass die Ausnutzung von CVE-2026-59309 und CVE-2026-59310 bereits im Gange ist [1][2][3]. Keine der beiden CVEs ist in der Liste der bekannten ausgenutzten Schwachstellen (KEV) der CISA aufgeführt. Zahlreiche nationale CERT-Stellen haben Warnungen herausgegeben [4][5][6][7][8][9][10][11][12][13][14][15][16][17][18].

In der Sicherheitsmitteilung VMSA-2026-0006 wurden außerdem drei weitere Schwachstellen offengelegt. CVE-2026-47876 (CVSS 9,3) ist eine Sicherheitslücke durch einen Schreibvorgang außerhalb des zulässigen Bereichs, die den ESX-VMXNET3-Netzwerkadapter betrifft. Durch Ausnutzung dieser Schwachstelle kann ein Gast-Administrator Code auf dem Host ausführen. Die beiden anderen Schwachstellen sind CVE-2026-41703 (CVSS 7,6), die VMware ESX, Workstation und Fusion betreffen, sowie CVE-2026-41709 (CVSS 2,7), die ESX betrifft.

Eine Risikobewertung der VMware vCenter- und ESX-Schwachstellen in VMSA-2026-0006

Technische Details zu CVE-2026-59310 und CVE-2026-59309, die VMware vCenter Server betreffen, wurden unmittelbar nach ihrer Offenlegung veröffentlicht, doch sind keine Proof-of-Concept-Exploits öffentlich verfügbar. Beide CVEs können von einem Angreifer ohne Authentifizierung aus der Ferne ausgenutzt werden. Öffentlichen Berichten zufolge wird bereits aktiv von beiden CVEs in der Praxis Gebrauch gemacht [1][2][3].

VMware vCenter Server birgt ein hohes Risiko, da es die zentralisierte Verwaltung von virtualisierten Hosts und virtuellen Maschinen über eine einzige Konsole ermöglicht. In der Praxis kann eine Kompromittierung von VMware vCenter Server Auswirkungen auf die Verwaltungsebene kritischer Hosts und Workloads virtueller Maschinen haben.

Die ESX-Probleme weisen ein anderes, aber dennoch bedeutendes Risikoprofil auf. CVE-2026-47876 erfordert lokale Administratorrechte innerhalb einer Gast-VM, die den VMXNET3-Adapter verwendet. Die Auswirkung ist jedoch schwerwiegend – die Ausführung von Code auf Host-Ebene. CVE-2026-41703 erfordert Berechtigungen zur Bereitstellung von VMs und kann zur Offenlegung von Informationen oder zu einem Denial-of-Service (DoS)-Zustand im Host-Prozess führen. CVE-2026-41709 weist zwar einen geringen Schweregrad auf, schwächt jedoch die Transparenz der Überwachung, da bestimmte Administratoraktionen die Protokollierung umgehen können.

CVE-2026-59309: Aktiv ausgenutzte Umgehung der vCenter-Authentifizierung

CVSS 9,8 · KritischWird aktiv ausgenutzt

Ein Angreifer mit Netzwerkzugriff auf den VMware vCenter Server kann die Authentifizierung umgehen und sich unbefugten Zugriff auf das System verschaffen. Die Ursache ist eine fehlerhafte Implementierung eines Authentifizierungsalgorithmus [CWE-303]. Die Schwachstelle betrifft den VMware Directory Service.

CVE-2026-59310: Aktiv ausgenutzte vCenter-Verzeichnisüberquerung mit RCE

CVSS 9,8 · KritischWird aktiv ausgenutzt

Eine Verzeichnisüberquerungsschwachstelle in der Syslog-Komponente des VMware vCenter Servers ermöglicht es einem nicht authentifizierten Angreifer aus der Ferne, beliebigen Code auszuführen. Die Ursache ist eine unzureichende Beschränkung eines Pfadnamens auf ein eingeschränktes Verzeichnis [CWE-22].

Weitere in VMSA-2026-0006 offengelegte CVEs

Der Sicherheitshinweis VMSA-2026-0006 enthüllte außerdem drei weitere Schwachstellen mit geringerem Schweregrad, die VMware ESX, Workstation und Fusion betreffen:

Die drei zusätzlichen CVEs, die in VMSA-2026-0006 offengelegt wurden, jeweils mit ihrem CVSS-Schweregrad und dem EPSS-Wert für die Ausnutzungswahrscheinlichkeit

CVE-2026-47876

CVSS 9,3 · Kritisch EPSS 0,281 % (20.)

Eine kritische Sicherheitslücke durch Speicherschreiben außerhalb des zulässigen Bereichs [CWE-787] im virtuellen Netzwerkadapter VMXNET3 von VMware ESX. Durch Ausnutzung dieser Schwachstelle kann ein Angreifer mit lokalen Administratorrechten auf einer VM Code auf dem ESX-Host ausführen. Die Schwachstelle betrifft nur Gast-VMs, die den Standard-VMXNET3-Adapter verwenden. Andere Netzwerkadapter sind laut Berichten nicht von CVE-2026-47876 betroffen.

CVE-2026-41703

CVSS 7,6 · Hoch EPSS 0,556 % (44.)

Eine Sicherheitslücke durch Lesezugriff außerhalb des zulässigen Bereichs [CWE-125], die eine Offenlegung von Informationen oder einen DoS-Angriff auf den Host-Prozess ermöglicht. Die Ausnutzung erfordert Berechtigungen zur Bereitstellung von VMs. CVE-2026-41703 betrifft VMware ESX sowie VMware Workstation und Fusion. Broadcom berichtet, dass sich die Auswirkungen auf VMware Workstation und VMware Fusion auf die Offenlegung von Informationen beschränken.

CVE-2026-41709

CVSS 2,7 · Niedrig EPSS 0,382 % (31.)

Eine Schwachstelle mit geringem Schweregrad in VMware ESX führt dazu, dass bestimmte Vorgänge nicht protokolliert werden [CWE-778].

Abhilfemaßnahmen für die in VMSA-2026-0006 offengelegten CVEs

Unternehmen sollten ihre installierten Versionen den betroffenen und behobenen Versionen in Broadcoms VMSA-2026-0006-Empfehlung gegenüberstellen und die vom Hersteller bereitgestellten Updates installieren. Für keine der CVEs sind Workarounds verfügbar.

CVE-2026-59309 und CVE-2026-59310 sind am dringendsten, da beide von einem nicht authentifizierten Angreifer mit Netzwerkzugriff auf eine betroffene VMware vCenter-Instanz ausgenutzt werden können. CVE-2026-47876 sollte priorisiert werden, wenn VMware ESX-Gast-VMs den VMXNET3-Adapter verwenden, da eine Ausnutzung den Ausbruch aus der virtuellen Maschine und die Ausführung von Code auf dem ESX-Host ermöglicht. CVE-2026-41703 sollte für VMware-ESX-Instanzen, die kritische Vorgänge verwalten, eine höhere Priorität erhalten, da die Schwachstelle ausgenutzt werden kann, um DoS-Zustände auszulösen. Die VMware-ESX-Schwachstelle CVE-2026-41709 sollte gepatcht werden, wenn die Vollständigkeit der Protokollierung wichtig ist.

Zusammenfassung

Der VMSA-2026-0006-Hinweis von Broadcom bündelt fünf VMware-Sicherheitslücken, die VMware vCenter Server, VMware ESX, VMware Workstation und VMware Fusion betreffen. Das höchste Risiko geht von den Schwachstellen CVE-2026-59310 und CVE-2026-59309 aus. Beide sind als kritisch eingestufte und aktiv ausgenutzte Schwachstellen, die VMware vCenter Server betreffen [1][2][3].

Der OPENVAS ENTERPRISE FEED von Greenbone behandelt die Schwachstellen CVE-2026-59309 und CVE-2026-59310 mit einer Remote-Banner-Versionsprüfung für VMware vCenter Server. Außerdem enthält es eine Erkennung auf Paketebene für VMware ESXi hinsichtlich CVE-2026-41703 [1], CVE-2026-47876 [2] sowie CVE-2026-41709 [3]. Für Sicherheitsverantwortliche, die Angriffe erkennen und Abwehrmaßnahmen ergreifen möchten, bietet eine Testversion von OPENVAS SCAN eine kostenlose zweiwöchige Testversion des OPENVAS ENTERPRISE FEED. Die Cybersicherheitsprodukte von Greenbone sind ein bewährter Weg, um einen umfassenden Einblick zu gewinnen, wo in der Infrastruktur Ihres Unternehmens Software-Schwachstellen bestehen.

 

Im Juli 2026 tauchten zahlreiche neue Risiken für IT-Sicherheitsverantwortliche in Unternehmen auf. Anfang Juli haben wir in unserem Blog über neue Probleme berichtet, wie beispielsweise die aktive Ausnutzung von Schwachstellen im WordPress-Core [2], Adobe ColdFusion [3] sowie Check Point SmartConsole [4]; neue Schwachstellen mit kritischem Schweregrad in Cisco-Produkten [5], BeyondTrust RS und PRA [6] sowie Citrix NetScaler ADC und Gateway [7]; sowie eine Flut von Linux-CVEs, darunter auch solche, die bereits aktiv ausgenutzt werden [8][9]. In diesem Blogbeitrag werden wir kurz auf die sogenannte „Vulnpocalypse“ eingehen und die Software-Sicherheitslücken mit dem höchsten Risiko behandeln, die in unserem Blog noch nicht vorgekommen sind.

Sicherheitsverantwortliche, die Schwachstellen erkennen und Schutzmaßnahmen ergreifen möchten, erhalten mit OPENVAS SCAN eine kostenlose zweiwöchige Testversion des OPENVAS ENTERPRISE FEED. Die Cybersicherheitsprodukte von Greenbone sind ein bewährter Weg, um einen umfassenden Einblick zu gewinnen, wo in der Infrastruktur Ihres Unternehmens Software-Schwachstellen bestehen.

Wer mitten im Hype-Zyklus rund um KI-Cybersicherheit steckt, findet den Posteingang voller Berichte über KI-Sicherheitslücken. Selbst Sicherheitsverantwortliche, die sich lediglich auf das Patchen und den Schutz ihrer IT-Infrastruktur konzentrieren, wurden von ungewöhnlich zahlreichen Schwachstellenmeldungen überschwemmt, die weit verbreitete Software betreffen [1][2][3][4]. Warten wir darauf, dass sich der Staub legt, oder wird der Sturm noch an Fahrt gewinnen?

Es ist ratsam zu fragen: Hinterlässt die sogenannte „Vulnpocalypse“ eine bleibende Lücke in der Anzahl der Softwarefehler, die Sicherheitsverantwortliche in Zukunft fürchten müssen? Oder kratzt die IT-Branche lediglich an der Oberfläche der angehäuften technischen Schulden? Wie schon im April gilt: Nur die Zeit wird das wahre Ausmaß der Gefährdung offenbaren. Schließlich sollte, wie die CISA in ihren neuen Sicherheitsrichtlinien für Open-Source-Software betont, Vertrauen ein entscheidender Faktor bei der Auswahl und dem Einsatz von Unternehmenssoftware sein.

CVE-2026-6875: ServiceNow AI Platform wird aktiv ausgenutzt

CVSS 7,6 · HochAktiv ausgenutztÖffentlicher PoC

CVE-2026-6875 (CVSS 7,6, EPSS ≥ 98. Perzentil) ermöglicht es einem nicht authentifizierten Angreifer, eine Remote-Code-Ausführung (RCE) zu erreichen, indem er aus der serverseitigen Skript-Sandbox der ServiceNow AI Platform ausbricht, sofern der Endpunkt assessment_thanks.do erreichbar ist. Der nicht authentifizierte Endpunkt assessment_thanks.do übergibt den vom Angreifer kontrollierten Parameter sysparm_assessable_type an die Funktion GlideRecord.addQuery(). Werte, denen javascript: vorangestellt ist, werden in der Rhino-Skript-Sandbox von ServiceNow ausgewertet. Angreifer können die Funktion gs.include() und gemeinsam genutzte globale JavaScript-Objekte nutzen, um die Grenzen der Sandbox zu umgehen.

Durch die Ausnutzung dieser Schwachstelle können eine ServiceNow-Instanz und verbundene Proxy-Server vollständig kompromittiert werden. Entsprechende Vorfälle wurden bereits gemeldet. Obwohl CVE-2026-6875 nicht auf der KEV-Liste der CISA steht, wurden zwei frühere ServiceNow-CVEs im Jahr 2024 aufgenommen. Ein öffentlicher Proof-of-Concept-Exploit sowie eine detaillierte technische Analyse sind verfügbar, was das Risiko von Cyberangriffen erhöht. Mehrere nationale CERT-Stellen haben Warnungen zu CVE-2026-6875 herausgegeben [1][2][3][4][5].

Vom Hersteller werden keine vorläufigen Abhilfemaßnahmen beschrieben. Ein Bericht der Cloud Security Alliance (CSA) verweist jedoch auf Standardmaßnahmen zur Risikominderung: Einschränkung des Netzwerkzugriffs über Firewall-Regeln oder Einsatz einer Web Application Firewall (WAF), um Ausnutzungsversuche zu blockieren. Nutzer von selbst gehostetem ServiceNow müssen ein Upgrade auf „Australia Patch 2“, „Yokohama Patch 12 Hot Fix 1b“ oder „Patch 13“, „Zurich Patch 7b“ oder „Patch 9“ sowie „Brazil EA“ oder „GA“ durchführen. Die gepatchten Versionen beseitigen die Sicherheitslücke und führen eine Funktion zur Sandbox-Absicherung namens Guarded Script ein. ServiceNow empfiehlt außerdem, die Protokolle auf verdächtige, nicht authentifizierte Skriptausführung oder Zugriffe auf den Endpunkt assessment_thanks.do zu überprüfen.

Der OPENVAS ENTERPRISE FEED von Greenbone enthält einen Remote-Banner-Prüfung zur Identifizierung von ServiceNow-Instanzen, die von CVE-2026-6875 betroffen sind.

Aufkommende Risiken für Microsoft-Produkte: Verstärkte Ausnutzung

Microsoft-Produkte sahen sich im Juli erneut einem erhöhten Ausnutzungsdruck ausgesetzt, vor allem durch aktiv ausgenutzte SharePoint-Schwachstellen. Ein öffentlicher PoC für eine Exchange-Server-Sicherheitslücke erhöht die Dringlichkeit für Sicherheitsverantwortliche zusätzlich.

CISA warnt vor Exploit-Kampagnen gegen Microsoft SharePoint

CVSS 9,8 · KritischAktiv ausgenutztIn CISA KEV

Ein außerplanmäßiger Microsoft-Sicherheitshinweis im Juli 2026 dokumentierte 37 eigenständige CVEs, die SharePoint betreffen, mit Auswirkungen wie RCE, Rechteausweitung, Spoofing und Offenlegung von Informationen. Im Juli warnte die CISA ebenfalls, dass Angreifer mehrere CVEs in Microsoft SharePoint Server Subscription Edition, 2019 und 2016 ausnutzen, um sich unbefugten Zugriff zu verschaffen und RCE zu erreichen. Zu den Aktivitäten nach der Ausnutzung gehören der Diebstahl von IIS-Maschinenschlüsseln, der Missbrauch der Deserialisierung des ASP.NET-View-Status sowie das Einschleusen von Malware.

Die im Juli 2026 veröffentlichten SharePoint-CVEs mit dem höchsten Risiko sind:

• CVE-2026-58644 (CVSS 9,8, EPSS ≥ 91. Perzentil): Ein entfernter Angreifer, der als Site Owner oder mit einer höheren Berechtigungsstufe authentifiziert ist, kann beliebigen Code auf einem Microsoft SharePoint-Server ausführen. Die Schwachstelle wird durch die Deserialisierung nicht vertrauenswürdiger Daten verursacht [CWE-502]. CVE-2026-58644 gilt als aktiv in der Praxis ausgenutzt und wurde zwei Tage nach der Offenlegung in den KEV-Katalog der CISA aufgenommen. Weder ein öffentlicher PoC-Exploit noch eine vollständige technische Analyse sind bislang für CVE-2026-58644 verfügbar.
• CVE-2026-50522 (CVSS 9,8, EPSS ≥ 99. Perzentil): Ermöglicht es einem unbefugten Angreifer, Code über ein Netzwerk auszuführen. Die Ursache ist die Deserialisierung nicht vertrauenswürdiger Daten [CWE-502]. CVE-2026-50522 wurde in die KEV-Liste der CISA aufgenommen.
• CVE-2026-56164 (CVSS 9,8, EPSS 97. Perzentil): Ermöglicht es einem unbefugten Angreifer, über ein Netzwerk Berechtigungen zu erweitern. Die Hauptursache ist eine fehlende Authentifizierung für eine kritische Funktion [CWE-306]. Weder CISA noch Microsoft haben von aktiven Angriffen berichtet. Detaillierte technische Beschreibungen oder PoC-Exploits sind nicht öffentlich verfügbar.
• CVE-2026-55040 (CVSS 9,1, EPSS ≥ 69. Perzentil): Eine schwache Authentifizierung [CWE-1390] ermöglicht es einem unbefugten Angreifer, eine Sicherheitsfunktion über ein Netzwerk zu umgehen. Weder die CISA noch Microsoft haben von aktiven Angriffen berichtet. Detaillierte technische Beschreibungen oder PoC-Exploits sind nicht öffentlich verfügbar.

Die Warnung der CISA zu neuen Angriffen auf SharePoint enthält zusätzliche Empfehlungen für Sicherheitsverantwortliche. Dazu gehören die Verkürzung der Patch-Zyklen sowie die Aktivierung von Antimalware Scan Interface (AMSI) für jede SharePoint-Website, die Beschränkung der Kommunikation von SharePoint Central Administration, der Farm und der Datenbank auf die unbedingt erforderlichen Systeme sowie die Vermeidung der Exposition von SharePoint-Servern gegenüber dem öffentlichen Internet und vieles mehr. Unternehmen sollten Patches umgehend installieren, da exponierte SharePoint-Server weiterhin attraktive Unternehmensziele bleiben. Der OPENVAS ENTERPRISE FEED von Greenbone umfasst die regelmäßige Erkennung von Sicherheitslücken in zahlreichen Microsoft-Produkten, einschließlich aller oben genannten CVEs.

CVE-2026-45504: Öffentlicher PoC-Exploit für Microsoft Exchange Server 2019

CVSS 8,8 · HochÖffentlicher PoCKeine bekannte Ausnutzung

CVE-2026-45504 (CVSS 8,8) ermöglicht es authentifizierten Benutzern mit geringen Berechtigungen, beliebige Dateien von einem lokal installierten Microsoft Exchange Server 2019 auszulesen. Die CVE wird als Server-Side Request Forgery (SSRF)-Schwachstelle klassifiziert [CWE-918]. Die Ursache ist eine fehlende Validierung des URL-Schemas bei der OneDrive- und WOPI-Integration. Mithilfe eines bösartigen Exchange Web Services (EWS)-Referenzanhangs und einer WOPI-Antwort kann ein Angreifer Exchange dazu zwingen, eine bösartige Datei-URI zu verarbeiten. Durch die Ausnutzung dieser Schwachstelle kann ein Angreifer angehängte OAuth-Parameter umgehen und Zugriff auf Konfigurationsdateien, Anmeldedaten und andere sensible lokale Daten erlangen.

Es wurden keine aktiven Angriffe, kein Einsatz von Ransomware und keine damit verbundenen Kampagnen gemeldet. Allerdings sind eine detaillierte technische Analyse sowie PoC-Exploit-Code öffentlich verfügbar, was das Risiko erhöht. Mehrere nationale CERT-Stellen haben Warnungen zu CVE-2026-45504 herausgegeben [1][2][3][4][5][6][7][8]. Für Sicherheitsverantwortliche, die Bedrohungen erkennen und Abwehrmaßnahmen ergreifen möchten, umfasst der OPENVAS ENTERPRISE FEED:

• Eine Remote-Versionsprüfung für Microsoft Exchange Server 2016, Server 2019 und die Subscription Edition (SE)
• Eine Prüfung der ausführbaren Version für Microsoft Exchange Server 2016 Cumulative Update 23
• Prüfungen der ausführbaren Version für das kumulative Update 14 und 15 für Microsoft Exchange Server 2019 [1][2]

Living on the Edge: Neue Bedrohungen für die Perimetersicherheit

Sicherheitslücken in Geräten am Netzwerkperimeter stellen ein besonders hohes Risiko dar, da sie Angriffen durch beliebige Angreifer aus der Ferne ausgesetzt sind. Laut dem neuesten Verizon DBIR 2026 ist die Ausnutzung öffentlich bekannter Software-Schwachstellen mittlerweile weltweit der häufigste Vektor für den Erstzugang. Hier sind einige der kritischsten neuen Bedrohungen für Perimeter-Geräte im Juli 2026 aufgeführt.

SonicWall SMA 1000-Appliances werden aktiv ausgenutzt

CVSS 10 · KritischAktiv ausgenutztIn CISA KEVÖffentlicher PoCRansomware-Verbindung

CVE-2026-15409 und CVE-2026-15410 wurden beide am 14. Juli 2026 veröffentlicht und am selben Tag in die KEV-Liste der CISA aufgenommen [1][2]. Die CVEs betreffen die Modelle 6210, 7210 und 8200v der SonicWall Secure Mobile Access (SMA) 1000-Serie. Laut einem forensischen Bericht wurden die Schwachstellen bereits lange vor ihrer Offenlegung ausgenutzt. Vollständige technische Analyse [3][4] sowie PoC-Exploits [5][6] sind für CVE-2026-15409 verfügbar. Zahlreiche nationale CERT-Stellen haben weltweit Warnungen herausgegeben [7][8][9][10][11][12][13][14][15][16][17][18][19][20]. SonicWall SMA 1000 ist 17 Mal in der KEV-Liste der CISA aufgeführt, wobei 10 Einträge mit Ransomware-Angriffen in Verbindung stehen, was auf ein hohes Risiko hindeutet.

Die SMA 1000-Serie fungiert als sicheres Zugangs-Gateway für Unternehmen, das SSL-VPN und Zero-Trust-Kontrollen kombiniert, um Remote-Benutzer mit internen, in der Cloud gehosteten und hybriden Anwendungen zu verbinden. Details zu jeder neuen, aktiv ausgenutzten CVE finden Sie unten:

• CVE-2026-15409 (CVSS 10, EPSS = 100. Perzentil): Eine Schwachstelle mit höchster Schwere, die es nicht authentifizierten Angreifern ermöglicht, über die Work Place-Schnittstelle Server-Side Request Forgery (SSRF) [CWE-918] auszulösen. Die Hauptursache ist ein anfälliger /wsproxy-Endpunkt, der User-Agent– und bmID-Werte verarbeitet, um WebSocket-Tunnel zu Diensten aufzubauen, auf die nur über die Loopback-Schnittstelle des Geräts zugegriffen werden kann.
• CVE-2026-15410 (CVSS 7,2, EPSS ≥ 99. Perzentil): Ermöglicht authentifizierten Administratoren, Code in die Appliance Management Console einzuschleusen, um beliebige Betriebssystembefehle [CWE-94] mit Root-Rechten auszuführen. Die Ursache ist ein fehlerhafter Workflow zum Entfernen von Hotfixes, der ein Path-Traversal [CWE-35] ermöglicht, um ein vom Angreifer bereitgestelltes Shell-Skript als Root auszuführen.

Durch die Verkettung der beiden Schwachstellen lässt sich, wie unten beschrieben, eine nicht authentifizierte Kontrolle auf Root-Ebene über ein betroffenes SMA 1000-Gerät erlangen:

• Erster Zugriff: Ein nicht authentifizierter Angreifer nutzt CVE-2026-15409 im /wsproxy WebSocket-Proxy aus, indem er einen manipulierten host-Parameter sendet und das Gerät so zwingt, eine Verbindung zu lokal beschränkten Diensten wie dem internen Erlang-Prozess auf Port 1050 herzustellen.
• Rechteausweitung: Anschließend nutzt der Angreifer die Schwachstelle CVE-2026-15410 aus, indem er eine Path-Traversal-Nutzlast an rollbackConfirm.action sendet, wodurch der Workflow hotfix-removal ein vom Angreifer bereitgestelltes Shell-Skript als Root ausführt, bevor ein Neustart erfolgt.

Nachdem sie Root-Rechte erlangt hatten, setzten die Angreifer maßgeschneiderte Malware zur Codeausführung und zum verdeckten Tunneling ein, installierten Web-Shells für den Fernzugriff und fügten Persistenzmechanismen hinzu, um den Root-Zugriff aufrechtzuerhalten. Schädliche Java-Komponenten wurden in einen legitimen SonicWall-Prozess eingeschleust, um routinemäßige Überwachungsmaßnahmen zu umgehen, und mithilfe von Paketaufzeichnungstools wurden LDAP-Anmeldedaten erfasst und der Zugriff auf interne Verzeichnisdienste erweitert [21].

Der Hersteller beschreibt keine Abhilfemaßnahmen. SonicWall empfiehlt dringend, den entsprechenden Plattform-Hotfix unverzüglich zu installieren und das System auf Anzeichen einer Kompromittierung zu überprüfen. Der OPENVAS ENTERPRISE FEED von Greenbone enthält eine Remote-Banner-Versionsprüfung zur Erkennung beider CVEs sowie eine aktive Prüfung speziell für CVE-2026-15409.

CVE-2026-20316: Cisco Secure Firewall Management Center (FMC) wird aktiv ausgenutzt

CVSS 5,3 · MittelAktiv ausgenutztIn CISA KEV

CVE-2026-20316 (CVSS 5,3) ermöglicht es einem nicht authentifizierten Angreifer aus der Ferne, sich über fest codierte Benutzeranmeldedaten als Benutzer mit geringen Berechtigungen bei einem betroffenen Gerät anzumelden [CWE-259]. Die Schwachstelle betrifft die Weboberfläche der Cisco Secure Firewall Management Center (FMC)-Software. Mehrere Cybersicherheitsexperten zeigten sich schockiert darüber, dass in Cisco-Produkten weiterhin fest codierte Anmeldedaten vorhanden sind.

CVE-2026-20316 wird aktiv ausgenutzt und wurde am Tag der Bekanntgabe in die KEV-Liste der CISA aufgenommen. Der nominelle CVSS-Wert von 5,3 unterschätzt das operative Risiko. Cisco hat CVE-2026-20316 eine Sicherheitsauswirkungsbewertung (SIR) von „Hoch“ zugewiesen und warnt ausdrücklich, dass die Schwachstelle mit anderen FMC-Schwachstellen kombiniert werden kann, um auf nicht gepatchten Geräten Berechtigungen zu erweitern. Mehrere nationale CERT-Stellen haben Warnungen zu CVE-2026-20316 herausgegeben [1][2][3][4][5].

Betroffen sind die Cisco Secure FMC-Versionen 7.0, 7.2, 7.4, 7.6, 7.7 und 10.0. Cisco hat Hotfix-Patches für die betroffenen Produkte veröffentlicht. Wenn die Patches nicht angewendet werden können, lässt sich das Risiko verringern, indem der öffentliche Internetzugriff auf die FMC-Verwaltungsschnittstelle verhindert wird. Der OPENVAS ENTERPRISE FEED enthält eine Remote-Banner-Prüfung, mit der Sicherheitsverantwortliche anfällige Geräte identifizieren können.

Neue hochriskante Sicherheitslücken betreffen Palo Alto Networks PAN-OS

CVSS 9,9 · KritischKeine bekannte Ausnutzung

Palo Alto Networks hat Patches für 13 neue CVEs veröffentlicht. Elf dieser CVEs betreffen PAN-OS und verschiedene Komponenten, die auf diesem Betriebssystem laufen. Die kritischsten neuen CVEs aus den Offenlegungen von Palo Alto Networks vom Juli 2026 sind:

• CVE-2026-0284 (CVSS 9,9): Eine XML-Injektionsschwachstelle in der Large Scale VPN (LSVPN)-Funktionalität von PAN-OS ermöglicht es einem nicht authentifizierten Angreifer mit Netzwerkzugriff, bösartigen XML-Inhalt einzuschleusen. Die Ausnutzung dieser Schwachstelle kann zur Offenlegung oder Manipulation interner LSVPN-Satellitendaten führen.
• CVE-2026-0288 (CVSS 7,5): Mehrere Pufferüberlauf-Schwachstellen in der User-ID Terminal Server Agent (TSA)-Komponente von PAN-OS ermöglichen es einem nicht authentifizierten Angreifer mit Netzwerkzugriff, einen Denial-of-Service (DoS)-Zustand auszulösen oder potenziell beliebigen Code auszuführen, indem er speziell gestalteten Netzwerkverkehr sendet. Das durch dieses Problem verursachte Sicherheitsrisiko wird minimiert, wenn die Konnektivität des User-ID Terminal Server Agent ausschließlich auf vertrauenswürdige interne IP-Adressen beschränkt ist.

Es liegen keine Berichte über aktive Ausnutzung der neuen CVEs vor. Unternehmen sollten jedoch umgehend die neuesten Updates installieren und den Zugriff auf sensible Dienste, insbesondere den User-ID Terminal Server Agent, einschränken. Informationen zu betroffenen Versionen und Patches finden Sie auf der Sicherheitshinweis-Seite von Palo Alto Networks. Der OPENVAS ENTERPRISE FEED von Greenbone enthält authentifizierte Scan-Erkennung für alle neuen CVEs von Palo Alto Networks, die PAN-OS und dessen Komponenten betreffen.

Zwei neue Sicherheitslücken in Gitea, einschließlich Ausnutzungsversuchen

CVSS 9,8 · KritischAktiv ausgenutztÖffentlicher PoC

Von neun neu bekannt gewordenen Gitea-Schwachstellen stellen zwei ein erhöhtes Risiko dar. Sysdig hat berichtet, dass in der Praxis Ausnutzungsversuche gegen CVE-2026-20896 stattfinden.

Hier sind die Details zu beiden neu aufgetretenen CVEs mit hohem Risiko:

• CVE-2026-20896 (CVSS 9,8): Nicht authentifizierte Angreifer können die Reverse-Proxy-Authentifizierung umgehen [CWE-284], um auf Repositorys und geheime Daten zuzugreifen. Das offizielle Docker-Image von Gitea verwendet eine app.ini-Vorlage, in der eine Wildcard-Zulassungsliste fest codiert ist (REVERSE_PROXY_TRUSTED_PROXIES=*). Für die Ausnutzung sind lediglich Zugriff auf den Gitea-Port und ein gültiger Benutzername erforderlich. CVE-2026-20896 wird Berichten zufolge aktiv gegen über das Internet zugängliche Instanzen ausgenutzt. Mehrere PoC-Exploits wurden veröffentlicht [1][2][3]. Betroffen sind die offiziellen Docker-Images von Gitea vor der Version 1.26.3.
• CVE-2026-27771 (CVSS 8,2): Nicht authentifizierte Angreifer können aus der Ferne private Container-Images abrufen. Die Hauptursache ist ein fehlerhaftes Autorisierungsdesign [CWE-862], bei dem anonyme JSON Web Tokens (JWTs) von ungeschützten Lese-Endpunkten der Registry akzeptiert werden, während die Sichtbarkeit von Paketen nie an die Sichtbarkeit des Repositorys gebunden war. Eine Ausnutzung dieser Schwachstelle kann zur Offenlegung von Anmeldedaten, API-Schlüsseln, TLS-Zertifikaten, Produktionskonfigurationen und kompiliertem Quellcode führen. Eine detaillierte technische Analyse [4] sowie PoC-Exploit-Code [5] sind verfügbar. Betroffen ist die in Gitea integrierte OCI-Container-Registry vor Version 1.26.2.

Schätzungsweise 31.000 Gitea-Instanzen sind weltweit öffentlich zugänglich. Der OPENVAS ENTERPRISE FEED umfasst eine Remote-Banner-Prüfung und eine Remote-Anwendungsprüfung für CVE-2026-20896 [6][7], sowie eine separate Remote-Banner-Prüfung und eine aktive Prüfung zur Identifizierung von Gitea-Instanzen, die von CVE-2026-27771 betroffen sind [8][9].

CVE-2026-63077: Kritische Sicherheitslücke betrifft JetBrains TeamCity On-Premises

CVSS 9,8 · KritischAktiv ausgenutzt

CVE-2026-63077 (CVSS 9,8, EPSS ≥ 47. Perzentil) ermöglicht eine nicht authentifizierte RCE gegen alle früheren Versionen von TeamCity On-Premises. Die Hauptursache ist die Deserialisierung nicht vertrauenswürdiger Daten [CWE-502] im Agent-Polling-Protokoll. Eine erfolgreiche Ausnutzung ermöglicht es einem Angreifer, Befehle mit den Berechtigungen des TeamCity-Serverprozesses auszuführen. Eine Kompromittierung könnte gespeicherte Anmeldedaten offenlegen, Build-Artefakte verändern und nachgelagerte CI/CD-Pipelines gefährden.

Bis zum 1. August 2026 wurden für CVE-2026-63077 keine aktiven Angriffe, kein öffentlicher PoC und keine vollständige technische Offenlegung auf Exploit-Ebene gemeldet. TeamCity wurde jedoch dreimal in die KEV-Liste der CISA aufgenommen, wobei jeder Eintrag mit Ransomware-Angriffen in Verbindung steht. Der OPENVAS ENTERPRISE FEED von Greenbone enthält eine Remote-Banner-Versionsprüfung zur Identifizierung ungepatchter Versionen von TeamCity On-Premises. Unternehmen sollten auf Version 2025.11.7 oder 2026.1.3 aktualisieren oder die Option für automatische Updates in TeamCity aktivieren. Für Organisationen, die kein Upgrade durchführen können, steht ein Sicherheitspatch zur Verfügung.

CVE-2026-14266: 7-Zip-Sicherheitslücke ermöglicht die Remote-Codeausführung

CVSS 7,0 · HochÖffentlicher PoCKeine bekannte Ausnutzung

CVE-2026-14266 (CVSS 7,0) ist eine neu bekannt gewordene Sicherheitslücke, die 7-Zip-Versionen vor 26.02 betrifft. Die Sicherheitslücke ermöglicht es Angreifern, aus der Ferne beliebigen Code auszuführen. Die Ursache ist eine fehlerhafte Verfolgung des beschreibbaren Speicherplatzes im XZ-Decoder, was zu einem heap-basierten Pufferüberlauf [CWE-122] führt. Bei jedem Aufruf des Decoders wird fälschlicherweise die volle Größe des Ausgabepuffers übergeben, was dazu führt, dass der Decoder den verbleibenden beschreibbaren Speicherplatz nach einer Teilausgabe überschätzt. Für die Ausnutzung muss das Ziel ein bösartiges XZ-Archiv öffnen. Die Auswirkung ist die Ausführung von Code mit den Berechtigungen des aktuellen Benutzers.

Es liegen keine Berichte über aktive Ausnutzung vor. Allerdings ist ein detaillierter technischer Bericht mit einem PoC-Exploit-Generator öffentlich verfügbar. Die Existenz eines öffentlichen PoC-Exploit-Generators – selbst in einem frühen Entwicklungsstadium – bedeutet, dass auch weniger erfahrene Angreifer bald in der Lage sein könnten, CVE-2026-14266 für Angriffe in der Praxis auszunutzen. Tatsächlich ist bekannt, dass Schwachstellen in 7-Zip bei Social-Engineering-Cyberangriffen ausgenutzt werden [1][2].

Das deutsche BSI und die italienische nationale CERT-Behörde ACN haben Warnungen zu CVE-2026-14266 herausgegeben [3][4]. Benutzer sollten auf 7-Zip Version 26.02 oder höher aktualisieren. Der OPENVAS ENTERPRISE FEED enthält eine Windows-Registry-Prüfung, um Systeme zu identifizieren, auf denen 7-Zip installiert ist. CVE-2026-14266 betrifft auch eingebettete 7-Zip-Komponenten in Produkten von Drittanbietern. Greenbone wird weiterhin Linux-Prüfungen zur Paketerkennung sowie weitere anwendungsspezifische Prüfungen hinzufügen, sobald nachgelagerte Anbieter Sicherheitshinweise veröffentlichen.

CVE-2026-53412: Nicht authentifizierte Remote-Kontoübernahme betrifft Zoom Workplace

CVSS 9,8 · KritischKeine bekannte Ausnutzung

Zooms Sicherheitshinweise dokumentieren neue Schwachstellen, die Zoom Workplace und andere zentrale Zoom-Anwendungen betreffen. Das Hauptrisiko stellt CVE-2026-53412 dar, das eine nicht authentifizierte Fernübernahme von Konten ohne Benutzerinteraktion ermöglicht und als Angriff mit geringer Komplexität beschrieben wird. Es wurden keine aktiven Ausnutzungsversuche gemeldet, und es sind keine detaillierten technischen Analysen oder PoC-Exploits öffentlich verfügbar.

• CVE-2026-53412 (CVSS 9,8): Ermöglicht es einem nicht authentifizierten Angreifer aus der Ferne, durch unsachgemäße Eingabevalidierung die Kontrolle über Konten zu übernehmen. CVE-2026-53412 betrifft Zoom Workplace für Windows vor Version 7.0.0 und den Zoom Workplace VDI-Client für Windows vor den entsprechenden behobenen Versionen.
• CVE-2026-53410 (CVSS 7,0): Ermöglicht es einem authentifizierten lokalen Angreifer, über eine „Time-of-Check-to-Time-of-Use“ (TOCTOU)-Race-Condition im Installations- oder Deinstallationsprozess mehrerer Zoom-Windows-Produkte Berechtigungen zu erweitern. Zu den betroffenen Produkten gehören Zoom Workplace, VDI Client, VDI Plugin, Zoom Rooms und Remote Control for Zoom Contact Center für Windows.

Der OPENVAS ENTERPRISE FEED von Greenbone enthält Registry-Prüfungen, die Installationen von Zoom Workplace für Windows identifizieren, die für CVE-2026-53412 [1] oder CVE-2026-53410 [2] anfällig sind.

Zusammenfassung

Die im Juli 2026 auftretenden Cybersicherheitsrisiken zeigen, dass Angreifer schwerwiegende Schwachstellen in Unternehmensplattformen, Perimeter-Geräten, Entwicklungstools und weit verbreiteten Anwendungen ausnutzen. Angesichts des Drucks durch die sogenannte „Vulnpocalypse“ sollten Sicherheitsteams eine hohe Transparenz gewährleisten und die Patch-Frequenz erhöhen, wobei exponierte Systeme Vorrang haben sollten. Eine mehrschichtige Verteidigung ist entscheidend, sobald Angreifer sich einen ersten Zugriff verschafft haben.

Sicherheitsverantwortliche, die Angriffe erkennen und abwehren möchten, erhalten mit OPENVAS SCAN eine kostenlose zweiwöchige Testversion des OPENVAS ENTERPRISE FEED. Die Cybersicherheitsprodukte von Greenbone sind ein bewährter Weg, um einen umfassenden Einblick zu gewinnen, wo in der Infrastruktur Ihres Unternehmens Software-Schwachstellen bestehen.