Einleitung
Vulnerability Detection ist nur dann wirklich hilfreich, wenn Findings korrekt eingeordnet werden können. Gerade bei CVEs mit hohem Schweregrad führt eine falsche oder missverständliche Zuordnung schnell zu Verunsicherung – insbesondere in Audits oder Compliance-Prüfungen. Ein aktuelles Beispiel ist CVE-2024-56180, das in Wazuh auf Ubuntu 24.04 LTS als kritisch gemeldet wird, obwohl das betroffene Produkt Apache EventMesh auf dem System gar nicht installiert ist. Dieser Artikel erklärt, warum das passiert, warum es sich dabei nicht um einen klassischen Wazuh-False-Positive handelt und wie man damit im Betrieb sinnvoll umgeht.
Ausgangslage / Problemstellung
In der Vulnerability Inventory von Wazuh 4.14.1 auf Ubuntu 24.04 LTS erscheint CVE-2024-56180 mit Severity Critical.
Die naheliegende Annahme: Das System müsse Apache EventMesh installiert haben, da viele öffentliche CVE-Beschreibungen die Schwachstelle eindeutig diesem Java-Projekt zuordnen und ein Update auf EventMesh ≥ 1.11 empfehlen.
Faktenlage auf dem betroffenen Server:
- Kein Apache EventMesh installiert
- Lediglich Apache HTTP Server vorhanden
- Dennoch: Kritische CVE im Inventory
Die zentrale Frage lautet daher:
Handelt es sich um einen False Positive oder um ein reales Risiko?
Technische Analyse
1. Unterschiedliche Datenquellen, unterschiedliche Zuordnungen
CVE-2024-56180 ist ursprünglich eine Deserialisierungs-Schwachstelle im Apache-EventMesh-Projekt.
Mehrere öffentliche CVE-Aggregatoren und Security-News-Seiten beschreiben sie ausschließlich im Kontext von EventMesh.
Ubuntu hingegen führt dieselbe CVE in seiner eigenen Security-Datenbank als relevant für Kernel-Pakete (linux-image-*). Diese Zuordnung ist öffentlich einsehbar und wird von Ubuntu selbst gepflegt.
Damit existieren zwei parallel gültige, aber widersprüchliche Interpretationen derselben CVE:
- Upstream / Community-Sicht: Apache EventMesh (Java-Anwendung)
- Ubuntu-Sicht: Linux-Kernel-Pakete
Wazuh wiederum verlässt sich bei der Distribution-basierten Vulnerability Detection explizit auf Vendor-Security-Daten (OSV, OVAL, Distribution Advisories) – nicht auf redaktionelle CVE-Artikel.
2. Warum Wazuh korrekt arbeitet – auch wenn das Ergebnis irritiert
Wazuh prüft nicht, welche Software du bewusst installiert hast, sondern:
- welche Pakete laut Paketmanager vorhanden sind
- welche CVEs der jeweilige Distributor diesen Paketen zuordnet
Wenn Ubuntu eine CVE einem Kernel-Paket zuweist und dieses Paket installiert ist, muss Wazuh diese CVE melden.
Aus Sicht der Engine ist das Ergebnis also technisch korrekt, selbst wenn die inhaltliche Zuordnung der CVE fragwürdig ist.
Debian klassifiziert dieselbe CVE übrigens als NOT-FOR-US – ein weiteres Indiz dafür, dass es sich um ein Problem in der CVE-Attribution, nicht in Wazuh, handelt.
3. Kein klassischer False Positive, sondern „Vendor Attribution Conflict“
Wichtig für die Einordnung:
- ❌ Kein Erkennungsfehler von Wazuh
- ❌ Kein falsch erkanntes Paket
- ✔️ Konflikt zwischen CVE-Beschreibung und Distribution-Security-Advisory
Das ist ein bekannter Grenzfall in CVE-basierten Systemen, insbesondere wenn CVEs mehrere Ökosysteme betreffen oder automatisiert weiterverarbeitet werden.
Lösung / Best Practices
1. Operative Einordnung statt blinder Alarmierung
In solchen Fällen sollte die CVE als „nicht anwendbar im gegebenen Kontext“ dokumentiert werden, statt sie reflexartig zu patchen oder zu ignorieren.
Empfehlungen:
- Vendor-Advisory (Ubuntu) prüfen
- Vergleich mit anderen Distributionen (z. B. Debian)
- Interne Risikobewertung dokumentieren (z. B. kein EventMesh, kein Java-RPC-Pfad)
2. Umgang mit Audits und Compliance
Für Audits ist entscheidend:
- Nachvollziehbare Begründung, warum die CVE kein reales Risiko darstellt
- Verweis auf widersprüchliche Vendor-Einstufungen
- Dokumentation im Vulnerability-Management-Prozess
Wazuh liefert hier die technische Erkennung – die fachliche Bewertung bleibt bewusst beim Betreiber.
3. Technische Workarounds (mit Einschränkungen)
Aktueller Stand:
- CVEs können nicht vollständig aus der Vulnerability Inventory entfernt werden.
- Rules mit
level="0"können zwar Alerts unterdrücken, nicht aber den Inventory-Eintrag. - Eine native „CVE-Suppression“ auf Inventory-Ebene ist bekannt und seit längerem auf der Roadmap, aber noch nicht umgesetzt.
Bis dahin bleibt nur:
- organisatorische Ausnahmebehandlung
- ggf. Dashboard-Filter für operative Ansichten
- saubere Dokumentation pro CVE
Lessons Learned / Best Practices
- Wazuh bewertet CVEs paket- und vendorbasiert, nicht „produktorientiert“ im menschlichen Sinn.
- CVE-Texte aus Blogs oder News-Seiten sind keine verlässliche Entscheidungsgrundlage für Vulnerability-Management.
- Unterschiedliche Distributionen können dieselbe CVE völlig unterschiedlich einstufen.
- Nicht jede kritische CVE ist automatisch ein relevantes Risiko – Kontext ist entscheidend.
- Fehlende CVE-Suppressionsmechanismen sollten frühzeitig in Audit-Strategien berücksichtigt werden.
Fazit
CVE-2024-56180 auf Ubuntu 24.04 LTS ist kein klassischer False Positive von Wazuh, sondern das Ergebnis einer widersprüchlichen CVE-Zuordnung durch den Distributor. Wazuh verhält sich korrekt, indem es die von Ubuntu gemeldete Kernel-Relevanz abbildet. Für Betreiber bedeutet das: weniger Aktionismus, mehr Einordnung. Solche Fälle lassen sich nicht technisch „wegkonfigurieren“, sondern müssen sauber bewertet und dokumentiert werden. Genau hier zeigt sich, dass Vulnerability Detection ein Entscheidungswerkzeug ist – kein automatischer Patch-Trigger.
Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
https://wazuh.slack.com/archives/C0A933R8E/p1768483187161039