Zero-Day-Exploits: Arten, Beispiele und wie man sich dagegen schützt

Wichtigste Erkenntnisse

• Ein Zero-Day-Exploit ist ein funktionierender Angriffscode für eine Sicherheitslücke, für die es noch keinen öffentlich verfügbaren Patch gibt.
• Die Ausnutzung kann bereits beginnen, bevor ein Patch verfügbar ist – oft noch bevor jemand außerhalb des Angreiferkreises davon weiß.
• Software, deren Lebenszyklus zu Ende geht, kann neue Schwachstellen hinterlassen, für die es überhaupt keine Korrektur durch den Upstream-Entwickler gibt.
• Sie können beeinflussen, wie schnell ein Fix Ihre Flotte erreicht, sobald er verfügbar ist.

Ihr Scanner zeigt einen fehlerfreien Bericht an. Ihr Patch-Zyklus ist auf dem neuesten Stand. All das hilft jedoch nichts, wenn eine Sicherheitslücke bereits ausgenutzt wird und noch kein Distributor ein Paket mit dem entsprechenden Fix veröffentlicht hat.

Das ist ein Zero-Day-Exploit: Angriffscode für eine Sicherheitslücke, für die es noch keinen öffentlich verfügbaren Patch gibt. Manchmal bleibt dieser Code monatelang geheim. Manchmal landet der Exploit noch am selben Tag auf GitHub – genau das geschah, als „Dirty Frag“ im Mai 2026 Linux-Distributionen traf. So oder so ist der Exploit nur der erste Schritt. Ein großer Teil der Kosten, die Ihnen letztendlich entstehen, hängt davon ab, wie lange dieses Sicherheitslückenfenster danach offen bleibt.

Zero-Day-Sicherheitslücke vs. Exploit vs. Angriff

Eine Sicherheitslücke ist der Fehler. Ein Exploit ist der funktionierende Code. Ein Angriff ist dieser Code, der auf ein reales Ziel gerichtet ist. Eine Abwehr ist bereits lange vor dieser letzten Phase möglich, und eine Fehlerbehebung wird möglich, sobald eine Korrektur vorliegt. Nachdem die Ausnutzung begonnen hat, verschaffen Ihnen Erkennung und Eindämmung Zeit.

Begriff	Was ist das?	Kannst du entsprechend handeln?
Zero-Day-Sicherheitslücke	Die Sicherheitslücke im Code, die möglicherweise intern bekannt ist, aber noch nicht öffentlich bekannt gegeben oder behoben wurde	Nicht immer. Solange die Schwachstelle nicht identifiziert ist, gibt es nichts Konkretes, was behoben werden könnte, und danach sind möglicherweise Abhilfemaßnahmen möglich, während an einer Lösung gearbeitet wird.
Zero-Day-Exploit	Funktionsfähiger Code, der diese Schwachstelle zuverlässig ausnutzt	Zum Teil. Durch Gegenmaßnahmen, Modul-Blocklisten und Sicherheitsoptimierungen lässt sich diese Technik unterbinden.
Zero-Day-Angriff	Eine Live-Kampagne, bei der dieser Exploit gegen echte Ziele eingesetzt wird	Ja. Die Erkennung und Eindämmung erfolgen sofort, die Installation des Patches erfolgt, sobald eine Korrektur verfügbar ist.

 Eine Schwachstelle kann jahrelang im Kernel vorhanden sein, ohne dass jemand einen Vorfall meldet. Die Schwachstelle war die ganze Zeit über vorhanden, auch wenn das tatsächliche Risiko davon abhing, ob sie überhaupt ausgenutzt werden konnte. Ein funktionierender Exploit verändert jedoch die Wahrscheinlichkeit, dass dieses Risiko eintritt. Sobald die Schwachstelle oder die Ausnutzungsmethode bekannt ist, lassen sich die einzelnen Phasen der Reaktion zeitlich planen, messen und verkürzen.

Arten von Zero-Day-Exploits

Zero-Day-Schwachstellen sind nicht gleichmäßig über Ihren Stack verteilt, und am sinnvollsten ist es, sie danach zu sortieren, wo sie auftreten. In seinem Bericht „Look What You Made Us Patch“zählte die Google Threat Intelligence Group (GTIG) 90 Zero-Days, die im Jahr 2025 in freier Wildbahn ausgenutzt wurden – ein Anstieg gegenüber 78 im Jahr 2024, aber immer noch weniger als die 100, die 2023 verzeichnet wurden. Betriebssysteme waren mit 44 % der Gesamtzahl bzw. 39 Schwachstellen die am häufigsten ausgenutzte Produktkategorie. Unternehmenssoftware und -geräte, die als Gruppe und nicht als einzelne Kategorie gezählt wurden, wiesen 43 Schwachstellen oder 48 % auf, was laut GTIG in beiden Fällen den höchsten Wert seit Beginn der Erfassung darstellt.

Die Anzahl der Angriffe auf Browser entwickelte sich in die entgegengesetzte Richtung und sank auf einen historischen Tiefstand. Die Angriffe auf Unternehmensinfrastrukturen und Edge-Geräte blieben hingegen auf einem hohen Niveau, was auch dadurch begünstigt wurde, dass die meisten Edge-Geräte nicht über eine standardmäßige EDR-Abdeckung verfügen.

Exploits für Betriebssysteme und Kernel

Betriebssysteme stellten in den GTIG-Daten für 2025 die größte Einzelkategorie dar und umfassten Desktop-, Mobil- und Server-Systeme sowie Schwachstellen im Linux-Kernel zeigen, wie groß der Wirkungsradius ist. Ein erfolgreicher Angriff auf dieser Ebene kann die Grenzen zwischen Anwendungen, Containern und Mandanten untergraben und die auf dem Host gespeicherten Anmeldedaten offenlegen.

 

Die Sicherheitslücken im Linux-Kernel von 2026, die eine Ausweitung von Berechtigungen ermöglichen, sind ein gutes Beispiel dafür. „Copy Fail“ (CVE-2026-31431, CVSS 7,8) befand sich seit einer In-Place-Optimierung im Jahr 2017 im Modul „algif_aead“ der Krypto-API des Kernels. Ein nicht privilegierter lokaler Benutzer konnte die im Speicher befindliche Seiten-Cache-Kopie einer Setuid-Binärdatei wie „su“ schrittweise um jeweils vier kontrollierte Bytes überschreiben, ohne dass eine Race-Condition auftrat und ohne dass Offsets je nach Distribution erraten werden mussten. Auf der Festplatte änderte sich nichts, sodass die Dateiintegritätsüberwachung nichts zu melden hatte.

Dirty Frag tauchte eine Woche später auf und verband CVE-2026-43284 in den IPsec-ESP-Modulen mit CVE-2026-43500 in rxrpc. Es handelt sich dabei um zwei unabhängige Wege zum selben Schreibvorgang im Seiten-Cache und nicht um eine Kette, und der öffentliche Exploit probiert denjenigen aus, den der Host zulässt, sodass das Schließen eines Pfades den anderen nicht schließt. 

TuxCare hat Live-Patches für „Copy Fail“ veröffentlicht, nachdem der vollständige Upstream-Fix-Satz anhand des veröffentlichten Exploits validiert worden war, und veröffentlichte anschließend innerhalb von 24 Stunden nach der Offenlegung am 7. Mai „Dirty Frag“-Patches. Wenn der Exploit öffentlich bekannt ist und der Fix einen Neustart auf tausend Hosts erfordert, kann der Neustart zum Engpass bei der Bereitstellung werden. Diese spezielle Lücke zu schließen, ist das Ziel von KernelCare dazu da.

Wussten Sie schon: Im September 2026 umfasste der Katalog der bekannten ausgenutzten Sicherheitslücken der CISA 31 Einträge zu Schwachstellen im Linux-Kernel. Zum gleichen Zeitpunkt zählte ein öffentlicher Tracker über 6.500 im Jahr 2026 veröffentlichte CVEs für den Linux-Kernel , die im Laufe des Jahres 2026 veröffentlicht wurden. Beide Zahlen ändern sich ständig, überprüfen Sie sie daher, bevor Sie sie irgendwo zitieren.

Sicherheitslücken in Enterprise-Edge- und Appliance-Systemen

Firewalls, VPN-Konzentratoren, Dateiübertragungsgeräte und Virtualisierungsplattformen gehören zu den wertvollsten Zero-Day-Zielen in Unternehmen, und der Grund dafür ist struktureller Natur. Sie befinden sich an der Netzwerkgrenze, verfügen über privilegierte Zugangsdaten und sind meist nicht durch standardmäßige EDR-Lösungen für Endgeräte abgedeckt.

GTIGs Anbieterübersicht für 2025 zeigt die großen Technologiekonzerne an der Spitze, dicht gefolgt von Sicherheitsanbietern, und hebt Cisco und Fortinet als ständige Ziele im Netzwerk- und Sicherheitsbereich hervor, ebenso wie Ivanti und VMware, bei denen der Schwerpunkt auf VPN- und Virtualisierungszugängen liegt. Weitere 20 Anbieter waren jeweils von genau einem Zero-Day-Angriff betroffen, was verdeutlicht, wie breit Angreifer ihr Netz auswerfen. GTIG berichtete zudem, dass staatlich geförderte Spionagegruppen weiterhin Edge-Geräte und Sicherheitsappliances priorisierten; etwas mehr als die Hälfte der diesen Gruppen zugeschriebenen Zero-Day-Exploits zielte auf diese Art von Infrastruktur ab.

Das Muster wiederholt sich: Remote-Code-Ausführung vor der Authentifizierung, Diebstahl von Anmeldedaten oder Schlüsseln und eine Persistenz, die über den Patch hinaus Bestand hat. ToolShell-Angreifer entwendeten ASP.NET-Maschinenschlüssel von SharePoint-Servern ab, wodurch sie noch lange nach der Aktualisierung des Servers gültige Payloads fälschen konnten. Durch das Patchen wurde die Sicherheitslücke geschlossen, aber jeder, der bereits im Besitz dieser Schlüssel war, behielt seinen Zugang, bis die Schlüssel ausgetauscht wurden. Wenn Ihr Gerätebestand in einer vierteljährlichen Tabelle erfasst ist, stellt diese Tabelle ein Sicherheitsrisiko dar.

Sicherheitslücken in Anwendungen und in der Lieferkette

Die dritte Kategorie umfasst Code, den Sie nicht selbst geschrieben und oft auch nicht bewusst installiert haben. Log4Shell ist das Paradebeispiel: eine kritische Schwachstelle in Log4j, einer Logging-Bibliothek, die mehrere Ebenen tief in der Abhängigkeitsstruktur Tausender Java-Anwendungen verborgen ist. Bei einer anfälligen Konfiguration genügte bereits eine vom Angreifer kontrollierte JNDI-Zeichenkette – beispielsweise eine, die über einen protokollierten HTTP-Header übermittelt wurde –, die einen anfälligen Log4j-Aufrufpfad erreichte.

Schwachstellen in Abhängigkeiten sind schwieriger zu beheben, da man nichts beheben kann, was man nicht auflisten kann. Nach der Log4Shell-Sicherheitslücke verbrachten Teams wochenlang damit, allein schon eine Bestandsaufnahme zu erstellen, und es tauchen immer noch zahlreiche weitere auf versteckte Log4j-Sicherheitslücken. Die Verwirrung um Abhängigkeiten ist ein ganz anderes Kaliber – ein Angriff auf die Lieferkette, bei dem ein bösartiges Paket eingeschleust wird, anstatt einen Fehler in einem legitimen Paket zu finden, der jedoch genau denselben blinden Fleck ausnutzt.

Das Überprüfen von Paketen, bevor sie in einen Build gelangen, wird einen Fehler, den noch niemand entdeckt hat und der in einer ansonsten legitimen Abhängigkeit liegt, nicht zuverlässig aufdecken. Was es jedoch aufspüren kann, sind bösartige und durch Typosquatting missbrauchte Pakete, und es liefert Ihnen das Abhängigkeitsverzeichnis, das Sie andernfalls erst mitten in einem Vorfall zusammenstellen müssten. Das ist die Lücke , den TuxCare mit SecureChain schließen soll – auf der Open-Source-Seite.

Bemerkenswerte Beispiele für Zero-Day-Exploits von 2021 bis 2026

Die folgende Liste reicht vom Mailserver über eine Protokollierungsbibliothek und ein Tool für die verwaltete Dateiübertragung bis hin zu einer Plattform für die Zusammenarbeit und schließlich zum Kernel selbst. Zero-Day-Angriffe beschränken sich nicht auf eine einzige Schicht des Stacks.

Jahr	Sicherheitslücke / CVE	Ziel	Warum es als Zero-Day galt
2021	ProxyLogon / CVE-2021-26855	Microsoft Exchange vor Ort	Die groß angelegte Ausnutzung begann bereits vor der Veröffentlichung des Out-of-Band-Patches
2021	Log4Shell / CVE-2021-44228	Apache Log4j 2	Die Ausnutzung wurde bereits Tage vor der öffentlichen Bekanntgabe und der Behebung festgestellt
2023	MOVEit / CVE-2023-34362	Fortschritt bei MOVEit Transfer	Cl0p hat Daten abgezogen, noch bevor die Sicherheitswarnung veröffentlicht wurde
2025	ToolShell / CVE-2025-53770	SharePoint Server vor Ort	CVSS 9.8 – RCE-Schwachstelle wurde bereits ab dem 18. Juli ausgenutzt, noch bevor der Notfall-Patch verfügbar war
2026	Dirty Frag / CVE-2026-43284, CVE-2026-43500	Linux-Kernel (ESP, rxrpc)	Der Exploit wurde öffentlich bekannt gegeben, bevor irgendein Distributor einen Patch ausgeliefert hatte

 Zwei davon haben eine etwas kompliziertere Vorgeschichte. Die Forschung hinter ToolShell begann im Mai 2025 als Demonstration beim Pwn2Own Berlin, bei der die Schwachstellen CVE-2025-49704 und CVE-2025-49706 miteinander verkettet wurden; Microsoft hat beide im Juli desselben Jahres behoben. Die in der Tabelle aufgeführte Schwachstelle ist nicht diese. 

CVE-2025-53770 ist eine Umgehung des im Juli veröffentlichten Patches, und die Schwachstelle wurde bereits ausgenutzt, als Microsoft ihr die Kennung zuwies. „Dirty Frag“ unterlag einer koordinierten Offenlegung, bis jemand die Sperrfrist brach und eine vorzeitige Veröffentlichung erzwang. In keinem der beiden Fälle war eine böswillige Forschungsquelle erforderlich. Entscheidend war, dass eine Ausnutzung möglich war, bevor die Verteidiger über einen vollständigen Patch verfügten.

Warum Zero-Day-Exploits so gefährlich sind

Ein Zero-Day-Angriff ist weniger deshalb gefährlich, weil er unbekannt ist, sondern vielmehr wegen des Geschwindigkeitsgefälles. Angreifer können innerhalb weniger Stunden zuschlagen. Die Behebung des Problems in Unternehmen, die durch Tests, Änderungskontrollen und Wartungsfenster eingeschränkt ist, dauert oft Tage oder Wochen. Der „M-Trends 2026“-Bericht von Mandiant schätzt die durchschnittliche Zeit bis zur Ausnutzung einer neuen Sicherheitslücke auf minus sieben Tage, was bedeutet, dass die Ausnutzung mittlerweile regelmäßig beginnt, bevor überhaupt ein Patch verfügbar ist. Mandiants eigene Trendlinie wies für die Jahre 2018 und 2019 denselben Wert von 63 Tagen auf.

 

1. Es gibt keinen Patch, wenn man ihn braucht

Die meisten Schwachstellenmanagement-Prozesse gehen davon aus, dass ein Hersteller-Patch verfügbar ist. Während der Phase vor der Veröffentlichung eines Patches für einen Zero-Day-Angriff greifen Sie stattdessen auf kompensierende Kontrollmaßnahmen zurück: Deaktivieren einer Funktion, Einschränken der Netzwerkexposition, Ändern der Konfiguration oder – unter Linux – das Blockieren eines Kernelmoduls und die Verschärfung von Seccomp-Profilen. Diese Maßnahmen verringern die Exposition, schränken jedoch teilweise auch legitime Funktionen ein, weshalb sie getestet werden müssen, bevor sie flottenweit eingeführt werden. Im Fall von „Dirty Frag“ bestand die CERT/CC-Umgehungslösung darin, esp4, esp6 und rxrpc auf die Blockliste zu setzen, sie zu entladen und den Seitencache zu leeren. Da dies auch IPsec und AFS außer Kraft setzt, war diese Lösung nie kostenlos.

Stellen Sie sich vor, ein Team, das eine Kubernetes-Plattform mit 300 Knoten betreibt, erhält mitten in der Woche diese Sicherheitsempfehlung, der bereits ein öffentlich zugänglicher Exploit beigefügt ist. Um die Module auf die Sperrliste zu setzen, muss zunächst nachgewiesen werden, dass in der gesamten Infrastruktur kein Bedarf an IPsec besteht – und dieser Nachweis dauert länger, als ein Angreifer auf einem Host benötigt, den er bereits erreichen kann.

2. Die signaturbasierte Erkennung hat von vornherein einen Nachteil

Sowohl signaturbasierte Antivirenprogramme als auch CVE-basierte Scans stützen sich auf Dinge, die bereits von anderen identifiziert und katalogisiert wurden. Ein brandneuer Zero-Day-Angriff verfügt noch über keine CVE-spezifische Signatur und wird noch von keinem Scanner erkannt.

Die Verhaltenserkennung schließt einen Teil dieser Lücke und ist heute weitaus besser als noch vor fünf Jahren. Sie ist jedoch auch anfällig für Fehlalarme, und die Kernel-Schwachstellen von 2026 haben gezeigt, wo ihre Grenzen liegen. „Copy Fail“ betraf lediglich den Seiten-Cache im Arbeitsspeicher, sodass die Datei auf der Festplatte byteweise identisch blieb und die Dateiintegritätsüberwachung keine Meldung ausgab. Durch einen Neustart wurde die saubere Seite neu geladen, wodurch auch dieses spezielle Artefakt entfernt wurde.

Zu all dem kommt noch das Problem mit dem Scanner hinzu. Die Teams versinken in falschen Positiven durch falsch identifizierte Backports, hören auf, die Scan-Ergebnisse genau zu lesen – und genau dann wird ein echter Befund als Störsignal abgetan.

3. Systeme am Ende ihres Lebenszyklus können Zero-Day-Schwachstellen auf unbestimmte Zeit ungepatcht lassen

Auf einem unterstützten System ist ein Zero-Day ein Zeitfenster, das sich in der Regel schließt, sobald ein Patch oder eine praktikable Abhilfemaßnahme verfügbar ist. Auf einem End-of-Life-Version Version gibt es keine weiteren Updates vom Hersteller für diese Version mehr, sodass das Fenster offen bleibt, bis man einen anderen Weg findet, es zu schließen.

Das wird zu Sicherheitsrückstand und nicht nur zu einem einzelnen Vorfall. Jede neu bekannt gewordene Sicherheitslücke, die diese Version betrifft – ob Zero-Day oder nicht –, fügt einen weiteren nicht gepatchten Eintrag hinzu, und diese häufen sich an.

Teams bleiben aus triftigen Gründen bei Betriebssystemen am Ende ihres Lebenszyklus: zertifizierte Anwendungsstacks, Hardware-Einschränkungen, Validierungszyklen, die sich in Quartalen bemessen. Der „Endless Lifecycle Support“ von TuxCare ist genau für diese Situation gedacht und stellt Sicherheitspatches für die abgedeckten EOL-Systeme und -Software bereit, während die Migration nach einem Zeitplan erfolgt, den das Unternehmen selbst festlegt. Dies ist ein anderes Problem als bei einem Zero-Day, bei dem eine Korrektur erwartet wird, diese aber noch nicht veröffentlicht wurde. Bei einer alternden Systemflotte verstärken sich diese beiden Faktoren gegenseitig.

So schützen Sie sich vor Zero-Day-Exploits

Man kann keine CVE-Prüfung für etwas durchführen, das noch niemand identifiziert hat; bauen Sie Ihren gesamten Plan also nicht darauf auf. Zwei Ziele sind hier von entscheidender Bedeutung: die Zeit zwischen der Verfügbarkeit eines Patches und dessen Implementierung zu verkürzen und den Umfang der Auswirkungen eines Exploits zu begrenzen, sobald dieser erfolgreich ausgenutzt wird. Erkennung, Reaktion auf Vorfälle und Zugriffskontrolle sind nach wie vor wichtig, doch gerade bei diesen beiden Zielen haben die meisten Teams den größten Handlungsspielraum.

 

Die Zeit bis zur Bereitstellung eines Patches verkürzen, sobald eine Lösung vorliegt

Sie haben keinen Einfluss darauf, wann der vorgelagerte Anbieter die Updates bereitstellt. Was Sie jedoch beeinflussen können, ist das anschließende Bereitstellungsfenster – und für viele Unternehmen sind es gerade diese Wochen in diesem Fenster, nicht der Patch selbst, die Zeit kosten.

Patching ohne Neustart beseitigt die Einschränkung auf Kernel-Ebene. Wenn Ihre Systemflotte Neustarts innerhalb eines Tages verkraften kann, ist herkömmliches Patchen möglicherweise völlig ausreichend. Wenn ein Kernel-Neustart ein Zeitfenster von drei Wochen erfordert, kann das Patchen ohne Neustart diese Bereitstellungslücke deutlich verkürzen, ohne dass Sie in der Zwischenzeit ein dreiwöchiges Sicherheitsrisiko in Kauf nehmen müssen.

Verringern Sie den Explosionsradius, bevor es nötig wird

Unter Druck getroffene Entscheidungen zur Risikominderung sind schlechte Entscheidungen. Treffen Sie sie frühzeitig.

Das bedeutet, dass Kernel-Module, die in Ihrer Infrastruktur nicht verwendet werden, auf die Blockliste gesetzt werden, sodass der Pfad geschlossen ist, bevor er überhaupt offengelegt wird. Es bedeutet Seccomp-Profile für nicht vertrauenswürdige Workloads, CI-Runner und Multi-Tenant-Knoten. Das Standardprofil von Docker verweigert „unshare“, wodurch die Einrichtung von Benutzer- und Netzwerk-Namespaces blockiert wird, die der veröffentlichte xfrm/ESP-Dirty-Frag-Exploit benötigt, sowie Tests auf EKS, GKE und Talos ergaben, dass „RuntimeDefault“ ausreicht, um diesen Zugriffspfad auf einem ansonsten anfälligen Kernel zu unterbinden. Dieselben Tests ergaben, dass ein nicht festgelegtes Seccomp-Profil auf EKS oder GKE nicht mit „RuntimeDefault“ gleichzusetzen ist, und dass Pods, die ohne Profil liefen, bis zur Container-Root-Ebene ausgenutzt wurden; daher hilft dies nur dort, wo „RuntimeDefault“ tatsächlich durchgesetzt und nicht nur vorausgesetzt wird. Es ist wichtig zu wissen, dass dieselbe Kontrollmaßnahme bei „Copy Fail“ wirkungslos war, da AF_ALG selbst unter der Pod-Sicherheitsstufe „Restricted“ erreichbar blieb. Das bedeutet, nicht vertrauenswürdigen Code von Hosts fernzuhalten, auf denen Produktionszugangsdaten gespeichert sind, und anschließend die Systeme so zu segmentieren, dass ein kompromittierter VPN-Konzentrator die Datenbankebene nicht erreichen kann.

Sowohl „Copy Fail“ als auch „Dirty Frag“ erfordern die Ausführung von lokalem Code. Überall dort, wo ein Angreifer sich diesen Zugang verschaffen kann – in gemeinsam genutzten CI-Umgebungen, Container-Build-Farmen, mandantenfähigen Kubernetes-Umgebungen oder auf jedem Host, der nach dem Erlangen eines ersten Fußfalls erreichbar ist –, konzentriert sich das Sicherheitsrisiko.

Wissen, was tatsächlich läuft und was tatsächlich gepatcht ist

Die Reaktionsgeschwindigkeit hängt von der Genauigkeit der Bestandsdaten ab. Ein Team, das in Echtzeit sehen kann, auf welchen Hosts betroffene Kernel laufen, kann diese Hosts schneller patchen – und genau darum geht es, wenn der Exploit bereits öffentlich bekannt ist. Ein Team, das diese Übersicht nicht hat, verbringt die Zeit während des Vorfalls damit, eine Tabelle zu erstellen.

Hier sind zwei Dinge entscheidend. Erstens eine genaue Bestandsaufnahme der Ressourcen und Versionen, einschließlich Containern und Appliances. Zweitens eine Patch-Überprüfung, die das tatsächlich ausgeführte System widerspiegelt und nicht die Metadaten der Pakete – denn genau hier neigen Scanner, die den Status aus Versionszeichenfolgen ableiten, dazu, Backports und Korrekturen ohne Neustart falsch zu interpretieren.

Führen Sie die Expositionsübung durch, bevor Sie sie brauchen. Ein ganz normaler Dienstag, ein fiktives CVE – und schauen Sie, wie lange es dauert, bis feststeht, welche Hosts betroffen sind und ob die Probleme behoben wurden. Lücken im Bestandsverzeichnis fallen oft als Erstes auf.

Die besten Tools zum Schutz vor Zero-Day-Exploits

Keine dieser Methoden kann versprechen, eine unbekannte Schwachstelle zu erkennen, bevor sie ausgenutzt wird. Sie verkürzen jedoch das Zeitfenster danach und ermöglichen es Ihnen, nachzuweisen, in welchem Zustand Sie sich tatsächlich befinden.

1. TuxCare

TuxCare deckt drei verschiedene Aspekte des Zero-Day-Problems ab, und dies ist bewusst so gewählt und keine Folge einer Produktflut, da eine Kompromittierung die Grenzen zwischen Kernel, Userspace und der bereits aufgegebenen Upstream-Software nicht berücksichtigt.

KernelCare patcht den laufenden Linux-Kernel ohne Neustart und ohne Wartungsfenster für eine breite Palette wichtiger Unternehmensdistributionen – was in gemischten Umgebungen von Bedeutung ist, in denen Tools für jedes Betriebssystem separate Verträge und separate Sicherheitslücken bedeuten. LibCare erweitert denselben Ansatz auf User-Space-Bibliotheken wie glibc und OpenSSL. Endloser Lebenszyklus-Support liefert Sicherheitspatches für abgedeckte Betriebssysteme, Laufzeitumgebungen, Bibliotheken und Frameworks, deren Lebenszyklus beendet ist (EOL), über die Standard-Paketverwaltung – auch lange nachdem der Upstream-Support eingestellt wurde.

2. CISA-Katalog bekannter ausgenutzter Sicherheitslücken

Kostenlos, zuverlässig und der schnellste Weg, um „theoretisch ausnutzbare“ Schwachstellen von solchen zu unterscheiden, die „gerade jetzt gegen Menschen ausgenutzt werden“. Der KEV-Katalog listet CVEs auf, deren Ausnutzung in der Praxis bestätigt wurde, und die zivilen Bundesbehörden erhalten für jeden Eintrag verbindliche Fristen für die Behebung der Sicherheitslücke.

Verwenden Sie ihn als Triage-Filter. Ein CVE, das in KEV landet, rückt an den Anfang der Warteschlange, unabhängig von seinem CVSS-Wertan die Spitze der Warteschlange. Der Haken liegt im Timing, denn KEV ist ein nachlaufender Indikator, und ein Zero-Day wird bereits lange ausgenutzt, bevor er dort auftaucht. „Copy Fail“ wurde am 1. Mai hinzugefügt, zwei Tage nach der Offenlegung, und der öffentliche Exploit war bereits seit genau diesen zwei Tagen im Umlauf. Es bleibt eines der stärksten öffentlichen Signale für die Priorisierung bestätigter Ausnutzungen.

3. Verhaltensbasierte EDR und Laufzeit-Erkennung

Endpunkt- und Laufzeit-Tools, die das Verhalten statt Signaturen überwachen, können Angriffe auch ohne spezifische Erkennung von Sicherheitslücken aufdecken – und genau darin liegt ihr Sinn und Zweck. Laufzeit-Tools wie Falco oder Ihr eigenes eBPF Probes können die Syscall-Muster kennzeichnen, auf die Exploits zurückgreifen – wie beispielsweise die auf „Splice“ basierenden Sequenzen zum Ausleihen von Seiten, mit denen der veröffentlichte „Dirty Frag“-Code seine Schreibprimitive für den Seiten-Cache erreichte.

Zwei Einschränkungen: Erkennung ist keine Prävention, daher muss bei einer Warnmeldung immer noch jemand wach sein, um darauf zu reagieren. Und auf vielen Geräten und Netzwerkkomponenten lässt sich einfach kein Agent ausführen, was mit ein Grund dafür ist, dass GTIG im Jahr 2025 14 Zero-Day-Angriffe auf Edge-Geräte gezählt hat und darauf hinwies, dass diese Zahl das tatsächliche Ausmaß wahrscheinlich unterschätzt.

Schützen Sie Ihre Systeme mit TuxCare vor Zero-Day-Exploits

Zero-Day-Angriffe werden uns auch weiterhin begleiten. Die Möglichkeit, dass Angriffe bereits beginnen, bevor ein Patch verfügbar ist, ist ein fester Bestandteil des Softwarebetriebs und wird ohne Vorwarnung wieder auftreten.

Sie können jedoch steuern, wie lange das Wartungsfenster offen bleibt. Durch das Patchen des Kernels ohne Neustart entfällt das Wartungsfenster gänzlich. Der erweiterte Support stellt einen Patch-Pfad für unterstützte EOL-Systeme wieder her. Eine genaue Patch-Überprüfung zeigt Ihnen, welche Hosts tatsächlich behoben sind – und nicht nur scheinbar.

Wenn Sie Linux in großem Maßstab einsetzen und das Anwenden von Kernel-Patches immer noch an einen Neustart-Zeitplan gebunden ist, sollten Sie diese Lücke zuerst schließen. KernelCare wurde genau für diesen Zweck entwickelt.

FAQs