Anwender schätzen es, wenn sich Software problemlos in ihre bestehende IT-Umgebung integrieren lässt. Für Anbieter bedeutet dies, eine plattformübergreifende Mischung aus Betriebssystemen und Infrastruktur zu unterstützen. Greenbone freut sich, die Unterstützung unserer Virtualisierungsplattform zu erweitern und Nutanix AHV in unsere Familie der unterstützten Hypervisoren aufzunehmen. Diese Erweiterung bietet mehr Flexibilität bei der Bereitstellung von OPENVAS SCAN und erweitert die ohnehin schon vielfältige Hypervisor-Unterstützung von Greenbone, zu der auch Microsoft Hyper-V, Oracle VirtualBox, VMware vSphere (ESXi) und Workstation Pro, Huawei FusionCompute sowie Proxmox VE gehören. Unsere breite Palette an unterstützten Hypervisoren stellt sicher, dass Sicherheitsverantwortliche unsere Lösung in praktisch jeder IT-Umgebung einsetzen können.

Eine kostenlose Testversion von Greenbones OPENVAS BASIC steht Nutanix-Anwendern und anderen Nutzern zur Verfügung, um ihre IT-Infrastruktur auf Schwachstellen zu überprüfen und Cyberangriffen einen Schritt voraus zu sein. Eine vollständige Übersicht über unser Produktangebot finden Sie in unserem Lösungsvergleich.

Im weiteren Verlauf dieses Artikels werden wir erläutern, wie sich die virtuellen Appliances von OPENVAS SCAN in den Nutanix AHV Type-1-Hypervisor integrieren lassen.

Die virtuelle Appliance „OPENVAS SCAN“ unterstützt nun den Nutanix AHV Typ-1-Hypervisor

Greenbone freut sich, die Unterstützung für die Nutanix AHV-Virtualisierung hinzuzufügen. AHV (kurz für Acropolis Hypervisor) ist der native Hypervisor der Nutanix Cloud Infrastructure-Plattform. Als Typ-1-Hypervisor läuft AHV direkt auf der Hardware des Hosts. Dadurch sind virtualisierte Appliances näher an der zugrunde liegenden Hardware und bieten eine hohe Leistung sowie einen Betrieb mit geringer Latenz. Das Ergebnis ist eine schnellere und zuverlässigere Virtualisierungsumgebung. Im Gegensatz dazu laufen Typ-2-Hypervisoren auf einem Standard-Desktop-Betriebssystem, das nicht auf Effizienz und Zuverlässigkeit optimiert ist.

Nutanix basiert auf dem KVM-Hypervisor des Linux-Kernels und dem QEMU-Hardware-Emulator. Es handelt sich um denselben Open-Source-Virtualisierungsstack, der einem Großteil moderner Rechenzentren und öffentlicher Clouds zugrunde liegt. Im Gegensatz zu herkömmlichen Hypervisoren ist AHV ohne zusätzliche Lizenzkosten in der Nutanix Cloud Infrastructure-Plattform enthalten und wird über Nutanix Prism verwaltet.

Ganz gleich, ob Sie bereits Greenbone-Unternehmenskunde sind und nach neuen Virtualisierungsoptionen suchen oder bereits Nutanix AHV einsetzen und Support benötigen – Greenbone hat jetzt die passende Lösung für Sie.

So richten Sie OPENVAS SCAN auf Nutanix AHV ein

Kunden können eine Nutanix-fähige Instanz der virtuellen Appliance OPENVAS SCAN bei einem Mitarbeiter des Greenbone-Vertriebsteams anfordern. Dieses spezielle Image wird im QEMU Copy-On-Write (QCOW)-Format bereitgestellt, das für Nutanix AHV optimiert ist. Sobald Sie die .qcow-Datei erhalten haben, führen Sie die folgenden Schritte in Nutanix Prism aus, um die virtuelle OPENVAS SCAN-Appliance zu installieren und zu konfigurieren:

1. Melden Sie sich bei der Nutanix AHV-Weboberfläche an und öffnen Sie das Einstellungsmenü in der oberen rechten Ecke.
2. Wählen Sie Image-Konfiguration und klicken Sie auf Image hochladen. Geben Sie dem Image einen Namen, stellen Sie Image-Typ auf DISK ein, wählen Sie Datei hochladen, wählen Sie die QCOW-Datei der Appliance aus und klicken Sie auf Speichern.
3. Wechseln Sie über das Dropdown-Menü in der oberen linken Ecke zur Ansicht VM und klicken Sie auf VM erstellen.
4. Geben Sie einen Namen für die virtuelle Maschine ein, legen Sie dann die Anzahl der virtuellen CPUs und Kerne sowie die Speichergröße fest und wählen Sie UEFI als Boot-Konfiguration aus. Die Appliance erfordert den EFI/UEFI-Boot-Modus.
5. Klicken Sie auf Neue Festplatte hinzufügen, wählen Sie als Vorgang Aus Image-Dienst klonen aus, wählen Sie als Bus-Typ SATA, wählen Sie das in Schritt 1 hochgeladene Image aus und klicken Sie auf Hinzufügen.
6. Klicken Sie unter Netzwerkadapter (NIC) auf Neue Netzwerkkarte hinzufügen, fügen Sie mindestens eine Netzwerkschnittstelle hinzu und klicken Sie anschließend auf Speichern. Der Import kann bis zu 10 Minuten dauern.
7. Nach dem Import wählen Sie die Appliance auf der Registerkarte Tabelle aus, klicken Sie auf Einschalten und schließen Sie den Einrichtungsvorgang für OPENVAS SCAN ab.

Eine vollständige Schritt-für-Schritt-Anleitung mit Screenshots finden Sie in der Greenbone-Dokumentation.

Welche Hypervisoren unterstützt die virtuelle OPENVAS SCAN-Appliance?

Hier finden Sie eine Übersicht über die unterstützten Hypervisoren und die Ressourcenanforderungen für die virtuelle OPENVAS SCAN-Appliance.

Die virtuelle OPENVAS SCAN-Appliance benötigt folgende Ressourcen:

• 2 virtuelle CPUs
• 12 GB RAM
• 500 GB virtuelle Festplatte (kann dynamisch zugewiesen werden)

Zusammenfassung

Greenbone unterstützt nun die Bereitstellung unserer OPENVAS SCAN-Virtual-Appliance auf dem Nutanix AHV Typ-1-Hypervisor und erweitert damit unsere branchenführende Flexibilität. Diese neue Funktion erweitert die Virtualisierungsmöglichkeiten und stellt sicher, dass Anwender OPENVAS SCAN problemlos in jede IT-Umgebung integrieren können – einschließlich der wachsenden Zahl von Rechenzentren, die auf Nutanix basieren. Eine kostenlose Testversion von Greenbones OPENVAS BASIC steht Nutanix-Anwendern und anderen Nutzern zur Verfügung, um ihre IT-Infrastruktur auf neue Bedrohungen zu überprüfen und Cyberangriffen einen Schritt voraus zu sein.

Der am 6. Juli 2026 veröffentlichte BeyondTrust-Sicherheitshinweis BT26-03 beschreibt mehrere neue Sicherheitslücken in BeyondTrust Remote Support (RS) und BeyondTrust Privileged Remote Access (PRA). Zu den Schwachstellen zählen zwei kritische Fehler, die ohne Authentifizierung ausgenutzt werden können, sowie weitere Probleme mit hohem Schweregrad in der Netzwerkkommunikation und in Webanwendungskomponenten. Für die Ausnutzung aller Fehler sind bestimmte Konfigurationen erforderlich, doch BeyondTrust hat die Konfigurationsdetails nicht offengelegt.

Laut BeyondTrust wurden die Probleme im Rahmen einer internen, KI-gestützten Schwachstellenforschung unter Verwendung öffentlich verfügbarer KI-Modelle entdeckt und vor einer Ausnutzung behoben. Der Anbieter gibt zudem an, dass die Schwachstellen vor der Behebung weder ausgenutzt wurden noch außerhalb des Unternehmens bekannt waren.

Es gibt keine Hinweise darauf, dass eine der CVEs in der Praxis ausgenutzt wurde, und es wurden keine öffentlichen Proof-of-Concept-Exploits (PoC) veröffentlicht. CISA hat seit Ende 2024 drei Sicherheitslücken, die BeyondTrust RS und PRA betreffen, in den KEV-Katalog aufgenommen, was darauf hindeutet, dass die Produkte beliebte Ziele für Angreifer sind. CVE-2026-1731 wurde Anfang 2026 hinzugefügt und wird mit Ransomware-Angriffen in Verbindung gebracht. Zahlreiche nationale CERT-Stellen haben Warnungen herausgegeben [1][2][3][4][5][6][7][8][9], was auf ein hohes globales Risiko hindeutet.

OPENVAS ENTERPRISE FEED enthält eine Remote-Banner-Versionsprüfung, die CVE-2026-40138, CVE-2026-40140 und CVE-2026-40141 in BeyondTrust PRA abdeckt, sowie eine separate Remote-Banner-Versionsprüfung für CVE-2026-40138, CVE-2026-40139, CVE-2026-40140 und CVE-2026-40141 in BeyondTrust RS. Mit OPENVAS SCAN und einer kostenlosen zweiwöchigen Testversion des OPENVAS ENTERPRISE FEED gewinnen sie sofort einen umfassenden Einblick, wo in der IT-Infrastruktur Ihres Unternehmens Software-Schwachstellen bestehen.

Sicherheitslücken, die im BeyondTrust-Sicherheitshinweis BT26-03 offengelegt wurden

Der BeyondTrust-Sicherheitshinweis BT26-03 umfasst zwei kritische und zwei hochgradige CVEs in zwei Produkten: BeyondTrust RS und PRA. Es gibt keine Hinweise auf eine Ausnutzung in der Praxis, und für keine der in BT26-03 offengelegten CVEs existieren öffentlich zugängliche PoC-Exploits. Allen Schwachstellen wurden moderate EPSS-Werte zugewiesen: 36. bis 48. Perzentil.

Betroffene Produkte und Versionen

BeyondTrust gibt an, dass alle in der Cloud gehosteten RS- und PRA-Instanzen zum 21. April 2026 gepatcht wurden. Für selbst gehostete Bereitstellungen weist der Anbieter die Kunden an, den Sicherheits-Rollup-Patch vom April anzuwenden oder auf die korrigierten Produktversionen zu aktualisieren. Die vorgelegten Nachweise identifizieren RS 25.3.2 und früher sowie PRA 25.3.2 und früher als betroffen. BeyondTrust bietet keine Workarounds für die Sicherheitslücken an.

BeyondTrust Remote Support (RS) ist ein Enterprise Remote-Support-Tool, das von IT-Service-Desks, Helpdesks und Support-Teams verwendet wird, um eine Verbindung zu Remote-Systemen und -Geräten herzustellen und diese zu steuern. In der Praxis bedeutet dies, dass das Produkt häufig im Rahmen der Fernfehlerbehebung, des administrativen Supports und der Interaktion mit Endgeräten zum Einsatz kommt.

BeyondTrust Privileged Remote Access (PRA) dient zur Verwaltung des Fernzugriffs auf kritische Systeme für privilegierte Benutzer und Drittanbieter. Das Produkt umfasst Sitzungsüberwachung, Auditierung, Aufzeichnung und Kontrollen zur Einhaltung des Prinzips der geringsten Berechtigungen. BeyondTrust beschreibt die B-Series-Appliance zudem als zentralen Kommunikationsknotenpunkt für sicheren Fernzugriff, der die Vermittlung von Sitzungen, die Authentifizierung, die Protokollierung, die Auditierung und die Verschlüsselung übernimmt.

Zusammenfassung

BT26-03 fasst vier bestätigte Schwachstellen in BeyondTrust Remote Support und BeyondTrust Privileged Remote Access zusammen. Die wichtigsten Probleme sind die beiden kritischen Schwachstellen vor der Authentifizierung, gefolgt von den Schwachstellen mit hohem Schweregrad in den Komponenten für Netzwerkkommunikation und Webanwendungen. Obwohl keine der CVEs bekanntermaßen in der Praxis ausgenutzt wurde und kein öffentlicher PoC-Exploit existiert, hat die CISA seit Ende 2024 drei Sicherheitslücken, die BeyondTrust RS und PRA betreffen, in ihren KEV-Katalog aufgenommen. CVE-2026-1731 wurde Anfang 2026 hinzugefügt und steht im Zusammenhang mit Ransomware-Angriffen. Zahlreiche nationale CERT-Behörden haben Warnungen herausgegeben, die auf ein hohes globales Risiko hinweisen. Der OPENVAS ENTERPRISE FEED von Greenbone bietet Fernüberprüfungen der Banner-Version für die BT26-03-CVEs und hilft Sicherheitsverantwortlichen dabei, betroffene BeyondTrust RS- und PRA-Appliances zu identifizieren und Abhilfemaßnahmen zu priorisieren.

Welche tatsächlichen Auswirkungen eine KI mit Cybersicherheitsbewusstsein auf die globale Bedrohungslage haben wird, bleibt abzuwarten. Einigen Berichten zufolge steigt die Zahl der CVE-Einträge für Software großer Anbieter. Dieser Threat Report vom Juni 2026 kratzt nur an der Oberfläche der wichtigsten Cybersicherheitsbedrohungen dieses Monats. Der Monat brachte eine konzentrierte Welle aktiv ausgenutzter Unternehmensschwachstellen mit sich, wobei die CISA im Laufe des Monats mehrere neue Einträge in ihren Katalog „Known Exploited Vulnerabilities“ (KEV) aufnahm. Mindestens ein neuer kritischer Exploit für Perimeter-Netzwerke stand in Verbindung mit einer aktiven Ransomware-Gruppe.

Die Erkennungstiefe von Greenbone zu Sicherheitslücken geht weit über die großen, Schlagzeilen machenden IT-Sicherheitsereignisse hinaus, wie sie in diesem monatlichen Threat Report beschrieben werden, und hält mit der Flut von KI-gestützten Offenlegungen Schritt. Holen Sie sich eine Kopie des OPENVAS SCAN mit einer kostenlosen zweiwöchigen Testversion des OPENVAS ENTERPRISE FEED — ein todsicherer Weg, um tiefgreifende Einblicke zu gewinnen, wo in der IT-Infrastruktur Ihres Unternehmens Software-Schwachstellen bestehen.

Hier sind einige der wichtigsten aufkommenden Bedrohungen für die IT-Sicherheit von Unternehmen ab Juni 2026.

CVE-2026-20253: Nicht authentifizierte RCE in Splunk Enterprise wird aktiv ausgenutzt

CVSS 9,8 · KritischWird aktiv ausgenutztIn CISA KEVÖffentlicher PoC

CVE-2026-20253 (CVSS 9,8, EPSS ≥ 95. Perzentil) ermöglicht es einem nicht authentifizierten Angreifer aus der Ferne, beliebige Dateien in Splunk Enterprise 10.2 vor 10.2.4 und 10.0 vor 10.0.7 zu erstellen oder zu kürzen. Die Schwachstelle ist auf eine fehlende Authentifizierung [CWE-306] am Endpunkt eines PostgreSQL-Sidecar-Dienstes zurückzuführen. Splunk bestätigte eine begrenzte Ausnutzung in der Praxis, und CISA hat die Schwachstelle in die KEV aufgenommen. Eine vollständige technische Beschreibung mit PoC-Exploit-Code wurde von WatchTowr veröffentlicht und demonstriert nicht authentifizierte RCE. Shadowserver hat mehr als 1.400 im Internet exponierte Splunk-Instanzen erfasst.

CVE-2026-20253 wurde in Splunk Enterprise 10.2.4 und 10.0.7 behoben, und Kunden sollten umgehend ein Upgrade durchführen. Ist ein Patch nicht möglich, lässt sich die Ausnutzung der Schwachstelle verhindern, indem der PostgreSQL-Sidecar-Dienst deaktiviert wird. Die Deaktivierung des Dienstes kann jedoch zu Störungen bei den Datenpipelines von Edge Processor, OpAmp oder SPL2 führen. Der OPENVAS ENTERPRISE FEED enthält einen Remote-Analyse-Test sowie einen separaten Remote-Banner-Test zur Identifizierung betroffener Instanzen.

CVE-2026-28318: SolarWinds Serv-U bei DoS-Angriffen ausgenutzt

CVSS 7,5 · HochWird aktiv ausgenutztIn CISA KEVÖffentlicher PoC

CVE-2026-28318 (CVSS 7,5, EPSS ≥ 60. Perzentil) ermöglicht es einem nicht authentifizierten Angreifer aus der Ferne, einen Denial-of-Service (DoS) im SolarWinds Serv-U Managed File Transfer und FTP-Server auszulösen. CISA hat die Schwachstelle in den KEV-Katalog aufgenommen; es wurde jedoch keine Zuordnung zu einer bestimmten Kampagne vorgenommen. Eine technische Beschreibung wurde veröffentlicht. Die Ausnutzung erfolgt durch einfaches Einfügen des Content-Encoding: deflate-Anfrage-Headers und kann zum Absturz des Serv-U-Dienstes führen. Die Schwachstelle wird durch unkontrollierten Ressourcenverbrauch [CWE-400] bei der Verarbeitung speziell gestalteter HTTP-POST-Anfragen verursacht.

Es besteht ein erhebliches Risiko von Betriebsstörungen bei exponierten Dateiübertragungsservern, die in regulierten Branchen wie dem Gesundheitswesen, dem Finanzsektor und der öffentlichen Verwaltung eingesetzt werden. Die Anzahl der exponierten Serv-U-Instanzen wurde ursprünglich von Shodan mit mehr als 12.000 und von Shadowserver mit etwa 3.000 angegeben. Die Zahl der von Shodan erfassten Instanzen ist jedoch bis Ende Juni auf weniger als 10.000 gesunken.

SolarWinds rät seinen Kunden, Serv-U 15.5.4 Hotfix 1 umgehend zu installieren. Falls die Installation des Patches nicht sofort möglich ist, können Nutzer POST-Anfragen blockieren, die den Content-Encoding: deflate-Header enthalten, ohne dabei an Funktionalität einzubüßen. Der OPENVAS ENTERPRISE FEED umfasst einen Remote-Banner-Test zur Erkennung anfälliger Instanzen.

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 aktuellen Verizon DBIR 2026-Bericht 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 Juni 2026 aufgeführt.

CVE-2026-50751: Check Point Security Gateway bei Ransomware-Angriffen ausgenutzt

CVSS 9,3 · KritischWird aktiv ausgenutztIn CISA KEVÖffentlicher PoCIm Zusammenhang mit Ransomware

CVE-2026-50751 (CVSS 9,3, EPSS ≥ 98. Perzentil) sowie CVE-2026-50752 (CVSS 7,4, EPSS ≥ 90. Perzentil) betreffen Check Point VPN Remote Access, Mobile Access, Security Gateways und Spark Firewalls. CVE-2026-50751 wird aktiv ausgenutzt, wobei mindestens ein Fall einer Kompromittierung nach dem Angriff mit einer Qilin-Ransomware-Gruppe in Verbindung gebracht wird. Die CISA hat CVE-2026-50751 in ihren KEV-Katalog aufgenommen. Die ersten Angriffe wurden am 7. Mai 2026 beobachtet. Weltweit waren mehrere Dutzend Organisationen betroffen. PoC-Exploit-Code und eine vollständige technische Beschreibungfür CVE-2026-50751 sind öffentlich zugänglich. CVE-2026-50752 wird nicht als aktiv ausgenutzt gemeldet.

Die CVEs werden im Folgenden beschrieben:

• CVE-2026-50751 (CVSS 9,3, EPSS ≥ 98. Perzentil): Nicht authentifizierte Angreifer können über eine Schwachstelle im Logikablauf und bei der Zertifikatsvalidierung in IKEv1-Implementierungen einen VPN-Zugang herstellen.
• CVE-2026-50752 (CVSS 7,4, EPSS ≥ 90. Perzentil): Könnte es nicht authentifizierten Angreifern ermöglichen, Man-in-the-Middle-Angriffe gegen VPN-Site-to-Site-Verbindungen durchzuführen.

Check Point hat Empfehlungen zur Abschaffung der Unterstützung für veraltete Protokolle und zur Aktualisierung betroffener Instanzen auf behobene Versionen veröffentlicht und gibt zusätzliche Ratschläge zur Sicherheitshärtung [1][2]. Der OPENVAS ENTERPRISE FEED enthält Remote-Banner-Erkennung für Gaia, das einheitliche Sicherheitsbetriebssystem von Check Point für Security Gateways, Sicherheitsmanagement-Produkte, Software Blades, Check-Point-Appliances sowie Open-Server. Check Point Gaia Versionen R80.20, R80.40, R81, R81.10, R81.20, R82 und R82.10 sind betroffen.

Drei CVSS-10-Schwachstellen im Ubiquiti UniFi OS ermöglichen unauthentifizierte RCE

CVSS 10 · KritischAls Zero-Day ausgenutztIn CISA KEV

Drei neue Schwachstellen mit einem CVSS-Wert von 10, die UniFi-OS-Systeme betreffen, wurden veröffentlicht und in die KEV-Liste der CISA aufgenommen. Die Schwachstellen ermöglichen es Angreifern insgesamt, Dateien und Konten des zugrunde liegenden Betriebssystems zu verändern und Befehle auszuführen. Benutzerberichte deuten darauf hin, dass die Schwachstellen wahrscheinlich als Zero-Day-Exploits ausgenutzt wurden, um betrügerische Administratorkonten zu erstellen. Das Risiko ist erhöht, da UniFi-OS-Geräte die Netzwerkinfrastruktur zentral verwalten, sodass eine erfolgreiche Kompromittierung einen potenziellen Weg für laterale Bewegungen in Unternehmensumgebungen darstellt.

Die CVEs werden im Folgenden beschrieben:

• CVE-2026-34908 (CVSS 10): Ein Angreifer mit Netzwerkzugriff kann eine Schwachstelle bei der Zugriffskontrolle [CWE-284] in UniFi-OS-Geräten ausnutzen, um unbefugte Änderungen am System vorzunehmen.
• CVE-2026-34909 (CVSS 10): Ein Angreifer mit Netzwerkzugriff kann eine Path-Traversal-Sicherheitslücke [CWE-22] in UniFi-OS-Geräten ausnutzen, um auf Dateien auf dem zugrunde liegenden System zuzugreifen und diese zu manipulieren und auf Konten zuzugreifen.
• CVE-2026-34910 (CVSS 10): Ein Angreifer mit Netzwerkzugriff kann eine Schwachstelle durch unsachgemäße Eingabevalidierung [CWE-20] in UniFi-OS-Geräten ausnutzen, um Befehlsinjektionsangriffe auszuführen.

Bishop Fox veröffentlichte eine vollständige technische Analyse, aus der hervorgeht, dass CVE-2026-34908 und CVE-2026-34909 eine Umgehung des Authentifizierungs-Gateways ermöglichen, die durch speziell gestaltete NGINX-Anfragen verursacht wird. Die Ausnutzung legt interne Routen offen und ermöglicht eine Befehlsinjektion über CVE-2026-34910.

Die Ausnutzung aller oben genannten CVEs wurde für UniFi OS Version 5.0.6 validiert. Ubiquiti hat die Schwachstellen in UniFi OS Server Version 5.0.8 behoben, die am 21. Mai 2026 veröffentlicht wurde. Es sind keine Workarounds verfügbar. Der OPENVAS ENTERPRISE FEED enthält eine Fernprüfung auf Sicherheitslücken sowie einen Remote-Banner-Test für das Ubiquiti UniFi OS auf verschiedenen Geräten, eine zusätzliche Remote-Schwachstellenprüfung und einen Remote-Banner-Test für Ubiquiti UniFi OS Server Version 5.0.6 und früher.

Squidbleed (CVE-2026-47729) Speicherleck mit öffentlichem PoC

CVSS 6,5 · MittelÖffentlicher PoCKeine ITW-Ausnutzung

CVE-2026-47729 (CVSS 6,5), auch bekannt als Squidbleed, ermöglicht es einem autorisierten Squid-Proxy-Benutzer, die HTTP-Anfragedaten eines anderen Benutzers im Klartext offenzulegen. Die Schwachstelle wird durch einen Heap-Überlesefehler im FTP-Verzeichnislisten-Parser verursacht. Zu den offengelegten Daten können Anmeldedaten, Sitzungstoken, API-Schlüssel und Autorisierungs-Header gehören. Öffentlicher Proof-of-Concept-Exploit-Code sowie eine vollständige technische Beschreibung sind öffentlich verfügbar. Es wurden jedoch noch keine Ausnutzungen in freier Wildbahn gemeldet. Überraschenderweise wurde CVE-2026-47729 trotz eines GitHub-Sicherheitshinweises, der die CVE anhand ihrer ID nennt, bis zum 1. Juli 2026 weder auf MITREs CVE.org noch im NIST NVD veröffentlicht.

Die Schwachstelle betrifft gemeinsam genutzte Proxy-Umgebungen, in denen Squid HTTP-Daten im Klartext überprüfen oder TLS vollständig beenden kann, sowie alle Squid-Versionen seit einer Änderung am FTP-Parser im Jahr 1997. Für die Ausnutzung muss die Squid-Instanz in der Lage sein, einen vom Angreifer kontrollierten FTP-Server über den TCP-Port 21 zu erreichen. Die Schwachstelle wurde in der Squid 7.6-Version vom Juni 2026 behoben, kann aber auch durch Deaktivierung der FTP-Unterstützung gemindert werden, sofern diese nicht benötigt wird. Der OPENVAS ENTERPRISE FEED enthält Erkennung auf Paketebene für Linux-Distributionen, die Sicherheitshinweise veröffentlicht haben, sowie eine Fernerkennung von Bannern für betroffene Versionen des Squid-Proxys.

CVE-2026-10520 und CVE-2026-10523 in Ivanti Sentry

CVSS 10 · KritischWird aktiv ausgenutztIn CISA KEVÖffentlicher PoC

CVE-2026-10520 (CVSS 10) sowie CVE-2026-10523 (CVSS 9,8) ermöglichen es einem entfernten, nicht authentifizierten Angreifer, RCE auf Root-Ebene zu erlangen und beliebige Administratorkonten in Ivanti Sentry anzulegen. CVE-2026-10520 wurde in den KEV-Katalog der CISA aufgenommen, nachdem Ausnutzungsversuche gegen Honeypots gemeldet worden waren. watchTowr veröffentlichte eine vollständige technische Analyse einschließlich eines öffentlichen PoC-Exploits. Shadowserver berichtete über eine groß angelegte Ausnutzung von CVE-2026-10520 und identifizierte bei seinen Scans 19 anfällige Instanzen, von denen mindestens zwei als kompromittiert eingestuft wurden.

• CVE-2026-10520 (CVSS 10): Eine Schwachstelle durch Befehlsinjektion im Betriebssystem [CWE-78] ermöglicht es einem entfernten, nicht authentifizierten Benutzer, Remote-Code auf Root-Ebene auszuführen.
• CVE-2026-10523 (CVSS 9,8): Eine Sicherheitslücke zur Umgehung der Authentifizierung [CWE-288] ermöglicht es einem nicht authentifizierten Angreifer aus der Ferne, beliebige Administratorkonten zu erstellen und vollständigen Administratorzugriff zu erlangen.

Die Ausnutzung erfordert Zugriff auf den Verwaltungsport 8443. Zu den betroffenen Versionen gehören Ivanti Sentry 10.5.1, 10.6.1, 10.7.0 sowie frühere Versionen; Korrekturen sind in den Versionen 10.5.2, 10.6.2 und 10.7.1 verfügbar. Der OPENVAS ENTERPRISE FEED von Greenbone enthält einen aktiven Check sowie einen Remote-Banner-Test, die beide CVEs abdecken.

HTTP/2-Bomb: DoS-Angriff auf alle gängigen Webserver

CVSS 7,5 · HochÖffentlicher PoCHerstellerübergreifender DoS

HTTP/2-Bomb ist eine remote ausführbare, nicht authentifizierte Denial-of-Service-Technik (DoS) gegen HTTP/2-Serverimplementierungen. Die Schwachstelle betrifft die Standard-HTTP/2-Konfigurationen im Apache HTTP Server, NGINX, Microsoft IIS, Envoy Proxy und Cloudflare Pingora sowie in weiteren digitalen Produkten, die diese Komponenten enthalten. Ein ausführlicher technischer Bericht ist verfügbar, und Califs HTTP/2-Bomb-Begleit-Repository listet eigenständige, servereigene PoCs und Docker-Labore für die wichtigsten betroffenen Webserver auf, was das Risiko erhöht. HTTP/3 gilt Berichten zufolge nicht als direkt anfällig für die aktuelle HTTP/2-Bomb-Technik.

Der Exploit nutzt legitime HTTP/2-Funktionen auf eine Weise, die die HPACK-Header-Komprimierung nicht vorsieht. Betroffene Webserver haben es versäumt, die zusätzlichen Beschränkungen durchzusetzen, die erforderlich sind, um diese Funktionen sicher zu machen. Der Exploit weist Berichten zufolge eine Speicherverstärkung zwischen 70:1 und 5,7K:1 auf und ermöglicht es, innerhalb von Sekunden 32 GB bis 64 GB Server-Speicher zu verbrauchen. Die Hauptursache ist eine fehlerhafte Verarbeitung von HTTP/2-Anfragen, bei der die HPACK-gesteuerte Cookie-Erweiterung eine übermäßige Speicherzuweisung und Datenverstärkung auslöst. Calif.io gibt zudem an, dass die tiefer liegende Ursache ein Problem in der Protokollspezifikation ist. Die wichtigsten Produkte im Zusammenhang mit HTTP/2-Bomb werden im Folgenden beschrieben:

• CVE-2026-49975 (CVSS 7,5) — Apache HTTP Server mod_http2: Apache HTTP Server Versionen 2.4.17 bis 2.4.67 sind betroffen; das Problem wurde in Apache HTTP Server Version 2.4.68 behoben.
• CVE-2026-47774 (CVSS 7,5) — Envoy Proxy: Envoy-Versionen vor 1.35.11, 1.36.7, 1.37.3 und 1.38.1 sind betroffen.
• CVE-2026-49160 (CVSS 7,5) — Microsoft HTTP.sys / IIS: Betrifft Microsoft HTTP.sys, den Windows-HTTP-Stack, der von IIS und anderen Windows-HTTP-Diensten verwendet wird. Microsoft hat das Problem in den Sicherheitsupdates vom 9. Juni 2026 behoben.
• Keine CVE zugewiesen — nginx: Alle nginx-Versionen vor 1.29.8 sind betroffen; das Problem wurde in nginx 1.29.8 behoben. Red Hat gibt an, dass das nginx-Upstream-Projekt keine CVE für HTTP/2-Bomb vergeben hat.

Quang Luong von Calif.IO führt die Entdeckung von HTTP/2-Bomb auf OpenAI Codex zurück. Es ist zu erwarten, dass viele weitere CVEs auftauchen, sobald Hardware- und Softwareanbieter ihre Produkte patchen. Greenbone enthält zahlreiche Schwachstellentests zur Erkennung von HTTP/2-Bomb über eine Vielzahl von Linux-Distributionen und anderen betroffenen Produkten hinweg. Dies umfasst die Erkennung betroffener Apache-HTTP-Server-Produkte (CVE-2026-49975), Envoy Proxy (CVE-2026-47774), Microsoft IIS (CVE-2026-49160) sowie nginx trotz fehlender CVE-Abdeckung.

Mehrere kritische Schwachstellen in SAP SE und SAP NetWeaver AS ABAP sowie ABAP Platform

CVSS 9,9 · KritischKeine bekannte AusnutzungPatch verfügbar

Drei neue kritische Schwachstellen in SAP-Produkten wurden veröffentlicht. Zusammen betreffen die Schwachstellen NetWeaver AS ABAP und ABAP Platform, den SAP NetWeaver Application Server Java Web Container, SAP Commerce Cloud sowie SAP Data Hub. Das Risiko ist erhöht, da die Schwachstellen in mehreren Fällen unbefugten Zugriff, die Offenlegung sensibler Daten, Dateiänderungen, Anwendungsabstürze, Speicherbeschädigung, die Ausführung beliebigen Codes und das Kapern von Verbindungen ohne Benutzerinteraktion ermöglichen können. Eine aktive Ausnutzung in freier Wildbahn wurde nicht beobachtet. Öffentliche PoC-Exploits oder eine vollständige öffentliche Exploit-Kette sind nicht verfügbar. Zur Behebung sollten die Updates des SAP Security Patch Day vom Juni 2026 umgehend eingespielt werden.

Details zu den drei CVEs finden Sie nachfolgend:

• CVE-2026-44748 (CVSS 9,9): Ein authentifizierter Angreifer mit normalen Berechtigungen kann eine gültige signierte Nachricht erlangen und modifizierte signierte XML-Dokumente an den Prüfer senden. Dies kann dazu führen, dass manipulierte Identitätsinformationen akzeptiert werden, was unbefugten Zugriff auf sensible Benutzerdaten und eine Störung der normalen Systemnutzung ermöglicht. Betroffen sind SAP NetWeaver AS ABAP Version 7.02, 7.31, 7.40, 7.50, 7.51, 7.52, 7.53, 7.54, 7.55, 7.56, 7.57, 7.58, 8.16, 9.18 und 9.19. Der OPENVAS ENTERPRISE FEED enthält einen Remote-Banner-Test zur Identifizierung betroffener Instanzen.
• CVE-2026-27671 (CVSS 9,8): Aufgrund einer unzureichenden RFC-Protokollvalidierung im SAP-Kernel kann ein nicht authentifizierter Angreifer eine speziell gestaltete RFC-Anfrage senden, die logische Fehler in der Speicherverwaltung ausnutzt und zu einer Speicherbeschädigung führt. Betroffen sind SAP NetWeaver AS ABAP Version 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 9.16, 9.18 und 9.19. Der OPENVAS ENTERPRISE FEED enthält einen Remote-Banner-Test zur Identifizierung betroffener Instanzen.
• CVE-2026-40128 (CVSS 9,0): Ein nicht authentifizierter Angreifer kann eine bösartige HTTP-Anmeldeanfrage erstellen, die Parameter zur Dateieinbindung manipuliert. Die Ausnutzung ermöglicht Path Traversal und die Verarbeitung der eingebundenen Datei und erlaubt es dem Angreifer, sensible Informationen einzusehen oder zu verändern oder beliebige Teile des lokalen Systems unverfügbar zu machen. Betroffen ist SAP NetWeaver AS Java Version 7.50. Der OPENVAS ENTERPRISE FEED enthält einen Remote-Banner-Test zur Identifizierung betroffener Instanzen.

Zusammenfassung

Der Juni 2026 verdeutlichte das zunehmende Unternehmensrisiko durch aktiv ausgenutzte Schwachstellen in Splunk, SolarWinds Serv-U, Check-Point-Gateways, Ubiquiti UniFi OS, Ivanti Sentry, Squid, HTTP/2-Implementierungen und SAP-Plattformen. Öffentliche PoCs, KEV-Einträge, Ransomware-Verbindungen und exponierte, mit dem Internet verbundene Assets unterstreichen die Notwendigkeit von schnellem Patchen, kompensierenden Kontrollen und kontinuierlicher Schwachstellenerkennung über Perimeter- und Kerninfrastruktur hinweg.

Greenbones OPENVAS BASIC ist kostenlos verfügbar und beinhaltet eine zweiwöchige Testversion des OPENVAS ENTERPRISE FEED — damit erhält Ihr Sicherheitsteam sofortigen Zugang zur automatisierten Schwachstellenerkennung für die in diesem Report behandelten CVEs und Zehntausende weitere. Starten Sie noch heute Ihre kostenlose Testversion.

Zum ersten Mal nutzen Angreifer ungepatchte Sicherheitslücken häufiger aus, als dass sie Zugangsdaten stehlen. Laut dem „2026 Data Breach Investigations Report“ von Verizon macht die Ausnutzung von Sicherheitslücken mittlerweile 31 % aller Sicherheitsvorfälle aus und liegt damit vor dem Diebstahl von Zugangsdaten mit 13 %. Und die Entwicklung geht für die Verteidiger in die falsche Richtung: Die mittlere Zeit bis zur vollständigen Behebung einer Sicherheitslücke stieg von 32 Tagen im Vorjahr auf 43 Tage, während Unternehmen nur 26 % der Sicherheitslücken auf der CISA-Liste der bekannt ausgenutzten Sicherheitslücken behoben haben – ein Rückgang gegenüber 38 % im Jahr 2024 (wir haben hier aufgeschlüsselt, was diese Verschiebung antreibt).

Scanner sind hier nicht der Engpass. Das Aufspüren einer Sicherheitslücke und deren tatsächliche Behebung sind zu zwei getrennten Problemen geworden, wobei das zweite an hinterherhinkt.

Die Erkennung war nie der schwierige Teil

OPENVAS von Greenbone hat fast zwei Jahrzehnte damit verbracht, die erste Hälfte zu perfektionieren: ein Netzwerk zu scannen, Schwachstellen zu identifizieren und deren Gefährlichkeit zu bewerten. Elmar Geese, CEO von Greenbone, vergleicht dies gerne mit einem Schwarm von Robotern, die jede Tür und jedes Fenster eines Hauses überprüfen. Sie sind schnell und gründlich, und wenn sie ein defektes Schloss finden, schlagen sie Alarm.

Doch ein Alarm nützt nur etwas, wenn jemand darauf reagiert. In den meisten Unternehmen stockt der Prozess genau an dieser Stelle. Ein Scan-Ergebnis landet in einem Bericht, einem Posteingang oder einer Tabelle, die niemand öffnet – bis zum nächsten Audit. Jemand muss es lesen, herausfinden, was es konkret für die jeweiligen Systeme bedeutet, entscheiden, wer für die Behebung zuständig ist, und daraus eine nachverfolgbare Aufgabe mit einer Frist machen. Dieser Schritt erfordert Sicherheitsfachwissen, über das nicht jedes IT-Team verfügt, und genau hier geht etwas verloren: Der Schweregrad wird falsch eingeschätzt, Tickets werden doppelt angelegt oder gar nicht erst erstellt, und über die Zuständigkeit wird im Nachhinein gestritten, anstatt sie im Vorfeld festzulegen.

Dies ist der Teil des Schwachstellenmanagements, der in der Werbung für Scanner nicht erwähnt wird, aber genau hier liegt der größte Teil der tatsächlichen Verzögerung.

Was sich durch die Integration tatsächlich ändert

Rico Barth, CEO von KIX, bringt es auf den Punkt: Die Partnerschaft schließt die Lücke „zwischen der Erkennung und der Behebung von Schwachstellen“. In dieser Lücke war früher ein Vermittler erforderlich, um einen Sicherheitsbefund weiterzuleiten. Das ist nun nicht mehr der Fall.

KIX, die Open-Source-ITSM-Plattform, und Greenbone haben eine direkte Verbindung zwischen den beiden Hälften des Problems hergestellt. Wenn OPENVAS eine Schwachstelle meldet, erstellt es nicht nur einen Bericht und belässt es dabei. Es eröffnet automatisch ein Ticket in KIX: klassifiziert als Sicherheitsvorfall, verknüpft mit dem konkreten betroffenen Gerät oder der betroffenen Software und an das Team gesendet, das für diese Ressource zuständig ist. Der Workflow zur Behebung – mit Fristen, Erinnerungen und Eskalationen – beginnt in dem Moment, in dem die Schwachstelle bestätigt wird, und nicht erst, wenn jemand dazu kommt, die Scan-Ergebnisse zu lesen.

Das bedeutet auch, dass ein IT-Administrator, der ein Ticket eröffnet, nicht bei Null anfängt. Die Ressource, das betroffene System, wer benachrichtigt werden muss und wie sich dies in alle anderen derzeit offenen Fälle einfügt – all diese Informationen liegen bereits vor. Niemand muss drei verschiedene Tools miteinander abgleichen, um herauszufinden, was tatsächlich vor sich geht.

Der Bonus, um den niemand gebeten hat: Dinge finden, von denen man gar nicht wusste, dass man sie hat

Es gibt einen Nebeneffekt, der sich als fast ebenso wichtig erweist wie das Ticketing selbst. OPENVAS scannt mehr als nur die Systeme, die der IT-Abteilung bereits bekannt sind. Es findet den Laptop, den eine Abteilung ohne Rücksprache mit der IT gekauft hat, oder den Server, den jemand vor zwei Jahren in Betrieb genommen und dann vergessen hat. Dieses Inventar fließt nun direkt in die Asset-Datenbank von KIX ein.

Shadow-IT wird üblicherweise als ein Problem der Richtlinien dargestellt. In der Praxis handelt es sich jedoch um ein Transparenzproblem, das sich mit dem Wachstum der Netzwerke verschärft. Greenbone-Kunden sind regelmäßig überrascht davon, was zutage tritt, wenn ihre Umgebung zum ersten Mal ordnungsgemäß gescannt wird. Die Einbindung dieser Erkenntnisse in dasselbe System, das bereits Tickets und Zuständigkeiten verwaltet, bedeutet, dass ein unbekanntes Gerät sofort in den normalen IT-Prozess integriert wird, anstatt in einem eigenen toten Winkel zu verbleiben.

Warum dies angesichts der Frage, wer die Arbeit tatsächlich erledigt, umso wichtiger ist

IT- und Sicherheitsteams sind fast überall überlastet, und der manuelle Auswertungsschritt im Schwachstellenmanagement ging bisher immer davon aus, dass genügend Fachpersonal vorhanden ist, um diese Aufgabe gut zu bewältigen. Diese Annahme wird von Jahr zu Jahr unsicherer. Entfällt der Schritt, bei dem ein Mensch jeden Befund manuell sichten, klassifizieren und weiterleiten muss, müssen kleinere oder generalistisch aufgestellte IT-Teams nicht mehr auf externes Sicherheits-Know-how zurückgreifen, das sie intern nicht haben, nur um Schritt zu halten.

Es hilft auch bei etwas, das mehr Zeit in Anspruch nimmt, als es sollte: dem Nachweis, dass man die Arbeit tatsächlich erledigt hat. Dokumentation, Fristen und der Verlauf der Behebung landen automatisch in KIX, was Audits nach Rahmenwerken wie NIS-2, ISO 27001 oder BSI-Grundschutz erheblich erleichtert, da die Nachweiskette bereits vorhanden ist und nicht erst im Nachhinein rekonstruiert werden muss.

Probieren Sie es dort aus, wo es darauf ankommt

Wenn Ihr Team derzeit OPENVAS und KIX separat einsetzt oder eines der beiden Systeme evaluiert, lohnt sich ein genauerer Blick auf diese Integration – gerade weil sie einen Schritt einspart, anstatt einen hinzuzufügen. Nehmen Sie Kontakt mit uns auf, um zu erfahren, wie der Übergang vom Scan zur Behebung in Ihrer eigenen Umgebung funktioniert und was für die Einrichtung erforderlich wäre. Und falls Sie noch nicht mit OPENVAS scannen, OPENVAS BASIC ist ein guter Ausgangspunkt, bevor Sie die übrigen Komponenten anbinden.

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

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

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

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

Die 5 Stufen der Reife im Schwachstellenmanagement verstehen

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

Stufe 1 – Ad-hoc

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

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

Die Grenzen eines ad-hoc / anfänglichen Sicherheitsprogramms

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

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

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

Stufe 2 – Wiederholbar / Operativ

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

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

Die Grenzen eines wiederholbaren / operativen Sicherheitsprogramms

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

Zu den üblichen Einschränkungen gehören:

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

Stufe 3 – Definiert / Verwaltet

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

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

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

Die Grenzen eines definierten / verwalteten Sicherheitsprogramms

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

Zu den üblichen Einschränkungen zählen:

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

Stufe 4 – Integriert / Kontrolliert

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

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

Die Grenzen eines integrierten / kontrollierten Sicherheitsprogramms

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

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

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

Stufe 5 – Optimiert / Strategisch

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

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

Die Grenzen eines optimierten / strategischen Sicherheitsprogramms

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

Häufige Optimierungsbereiche können sein:

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

Zusammenfassung

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

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

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