Am 14. September 2026 legte The Hacker News Zahlen vor, die das Bild der Schwachstellenlage in der ersten Jahreshälfte 2026 zusammenfassen: 35.853 veröffentlichte CVEs, rund 49 Prozent mehr als im Vorjahr. Gleichzeitig wurden nur 495 davon als in der wilden Welt ausgenutzt dokumentiert, und 116 standen bereits am Tag der Veröffentlichung unter Angriff. Die eigentliche Herausforderung ist damit nicht mehr, Schwachstellen zu finden, sondern zu entscheiden, welche in der eigenen Umgebung tatsächlich relevant sind. Der Beitrag ist ein Gastbeitrag von Picus Security auf The Hacker News; die Kernzahlen bestätigen sich auch bei Privacy Needle.

Für einen Betrieb mit zwanzig bis achtzig Mitarbeitern bedeutet das konkret: Das Vulnerability-Management-Tool spuckt jetzt spürbar mehr Meldungen aus als noch vor einem Jahr. Wer jede High- oder Critical-Bewertung als Notfall behandelt, kommt nicht hinterher – und das ist, wie mehrere der vorgelegten Quellen betonen, auch das falsche Modell. Die Frage, die jetzt zählt, lautet: Welche dieser Schwachstellen betrifft einen Asset, der erreichbar ist, geschäftskritisch ist und bei dem weder Prävention noch Detektion greifen? Genau das kann die CVSS-Punktzahl nicht beantworten. Sie liefert eine gemeinsame Schwere-Baseline, keinen Kontext. Und in einer Umgebung, in der die Lücke zwischen Disclosure und Ausnutzung immer kleiner wird, reicht ein Score nicht mehr.

Drei Validierungsarten, die zusammenwirken müssen

Die Zahlen aus den eigenen Offenlegungsdaten von Anthropic machen die Dimension sichtbar: Modelle der Mythos-Klasse haben 26.153 Schwachstellenkandidaten in Open-Source-Software identifiziert, von denen nur 421 upstream gepatcht wurden. Die Menge an KI-generierten Befunden übersteigt damit die Kapazität traditioneller Patch-Workflows deutlich, wie Privacy Needle einordnet. Parallel dazu zeigt eine Omdia-Studie, die The Hacker News zitiert: 95 Prozent der Organisationen stufen Pentesting als Top- oder High-Priority ein, getestet wird im Schnitt aber nur 32 Prozent der Angriffsfläche pro Jahr. Die Lücke zwischen Anspruch und Abdeckung ist nicht neu, sie wird nur größer.

Um diese Lücke zu schließen, unterscheiden die Quellen drei Validierungsarten, die unterschiedliche Fragen beantworten. Exploitability-Validierung klärt, ob eine Schwachstelle in der eigenen Umgebung tatsächlich ausnutzbar ist – auch dann, wenn noch kein funktionierender Exploit existiert. Security-Control-Validierung prüft, ob Präventions- und Detection-Maßnahmen den Angriff tatsächlich blockieren oder erkennen. Agentic Pentesting führt reale Exploits sicher aus und zeigt, wie weit ein Angreifer über gekettete Schwachstellen, Credentials und Fehlkonfigurationen im Netzwerk vorrücken kann. Gartner verweist in einer Mai-Research-Note auf genau dieses Muster: validierte Angriffspfade, entscheidungsgetriebene Reaktion und Exposure-Reduktion, eingebettet in operative Workflows. CSO Online fasst die Kernaussage der Fal.Con 2026 zusammen, wo CrowdStrike-CEO George Kurtz in der Keynote auf die beschleunigte Angriffsgeschwindigkeit einging: Es geht nicht darum, mehr Schwachstellen zu finden, sondern zu verstehen, welche Credentials missbraucht werden können, ob Schwächen gekettet werden können und ob ein Angreifer geschäftskritische Systeme erreicht.

Was jetzt zu tun ist

1. Asset-Inventory aufarbeiten: Prüfen, welche Systeme in der Umgebung tatsächlich erreichbar sind und welche geschäftskritisch. Eine Schwachstelle auf einem air-gapped System, das niemand erreicht, hat ein anderes Risiko als dieselbe Schwachstelle auf dem Kassensystem. Ohne sauberes Inventory ist jede Priorisierung ein Bauchgefühl – das ist die Grundlage für alles Weitere.
2. Validierung vor dem Patch: Für die zehn relevantesten CVEs im eigenen Umfeld prüfen, ob ein funktionierender Exploit existiert, ob die betroffene Komponente erreichbar ist und ob bestehende Controls (Firewall, EDR, Netzwerksegmentierung) den Angriffsweg bereits unterbrechen. Erst dann Priorität setzen. Das spart Ressourcen und verhindert, dass man an der falschen Stelle panisch patcht.
3. Re-Validierung nach dem Patch einplanen: Nach jeder Maßnahme prüfen, ob die Schwachstelle tatsächlich geschlossen ist und die Controls greifen. Ein Ticket, das nach dem Patch einfach geschlossen wird, ohne dass jemand nachprüft, ist kein Nachweis – es ist eine Annahme. Gerade bei KI-beschleunigter Schwachstellendiskussion, bei der die Lücke zwischen Disclosure und Ausnutzung schrumpft, ist dieser Schritt kein Luxus.

Das Ärgernis an der Sache: Die Tools, die die Schwachstellen finden, liefern inzwischen mehr Daten, als man verarbeiten kann – und die Frage, was davon wirklich zählt, bleibt beim Betrieb. Wer jetzt unsicher ist, ob die eigene Priorisierungslogik noch trägt, hat damit schon die richtige Frage gestellt. Wenn Sie möchten, schauen wir uns gemeinsam an, ob Ihre aktuellen Schwachstellenmeldungen tatsächlich zu den Assets passen, die sie betreffen – hier erreichen Sie uns.