ClamAV 1.5.4 und 1.4.6: Sieben Lücken legen den Virenscanner still

Ein Virenscanner, der abstürzt, meldet keinen Fund. Genau das ist die Lage seit dem 7. August 2026: Das ClamAV-Projekt und Cisco haben sieben Schwachstellen offengelegt, bei denen eine einzige präparierte Datei ausreicht, um den Scanner zu beenden. Angreifer brauchen dafür weder ein Konto noch eine Anmeldung, die Datei muss nur in den Scan geraten. Fixe stehen in ClamAV 1.5.4 und 1.4.6 bereit.

Betroffen ist damit die Prüfkette selbst, nicht der Host darunter. Wer ClamAV als Mail-Scanner vor Postfix oder in mailcow betreibt, als Upload-Prüfung in Nextcloud oder als Dateiscan auf einem Samba-Server, sollte diese Woche aktualisieren. Ein reines Wartungsfenster reicht dafür aus, ein Notfalleinsatz ist nicht nötig, weil bisher keine Ausnutzung gemeldet ist. Wer ClamAV gar nicht einsetzt oder nur manuell auf einer Einzelmaschine scannt, kann die Meldung entspannt einordnen.

Was ist passiert?

Alle sieben Schwachstellen sitzen in Dateiformat-Parsern. Der Scanner packt eine eingehende Datei aus und analysiert sie, dabei führen fehlerhafte Größen- und Indexberechnungen zum Absturz des Prozesses. Die schwerwiegendsten Fälle betreffen das ZIP-Format: CVE-2026-20337 beschreibt eine fehlerhafte Kapazitätsverwaltung im ZIP-Katalog, die über eine Heap-Allokation hinausschreibt, CVE-2026-20338 eine fehlerhafte Eigentumsverwaltung beim Zusammenführen von ZIP-Katalogeinträgen, die zu einem ungültigen Free führt.

Dazu kommen ein Indexfehler beim Umwandeln von GPT-Partitionsnamen (CVE-2026-20345), ein Integer-Overflow im PESpin-Unpacker (CVE-2026-20339), ein Integer-Underflow im PDF-Parser (CVE-2026-20346), undefiniertes Verhalten im Mach-O-Parser (CVE-2026-20347) und eine fehlerhafte Größenbehandlung im XAR-Parser (CVE-2026-20348). Zusätzlich hat das Projekt den Upstream-Fix für CVE-2025-8088 in der mitgelieferten UnRAR-Bibliothek übernommen, der Pfadtrenner in NTFS-Alternate-Data-Stream-Namen zurückweist. Behoben wurden außerdem Thread-Sicherheitsprobleme im STATS-Kommando von clamd, die Prozessspeicher offenlegen oder den Dämon abstürzen lassen konnten.

Wer ist betroffen?

1. ClamAV 1.5.0 bis 1.5.3 sowie 1.4.5 und älter. Die Versionsbänder unterscheiden sich je CVE, der GPT-Fall reicht bis 0.98.2 zurück, der PESpin-Fall bis 0.90.
2. Fixe stehen in ClamAV 1.5.4 und 1.4.6 sowie in den entsprechenden Docker-Images auf Basis von Alpine und Debian.
3. Typische Einsatzorte in kleinen Unternehmen: Mailserver mit Postfix, Rspamd oder mailcow, Groupware-Gateways, Nextcloud-Upload-Prüfung, Dateiserver mit Samba sowie Proxy- und Download-Scanner.
4. Betroffen sind auch Cisco-Produkte, die ClamAV als Scan-Engine einbinden. Details dazu führt das Cisco-Advisory.
5. Der UnRAR-Fall CVE-2025-8088 zielt auf das Entpacken außerhalb des temporären Scan-Verzeichnisses unter Windows, für reine Linux-Installationen ist er nachrangig.

Wie kritisch ist das?

Die praktische Auswirkung ist Denial of Service: Der Scanvorgang bricht ab, der Dämon kann sterben. Eine Übernahme des Systems ist aus den veröffentlichten Beschreibungen nicht ableitbar, auch wenn mehrere Fälle als Speicherfehler eingestuft sind. Cisco und das Projekt melden zum Stand 9. August 2026 keine Ausnutzung in freier Wildbahn, technische Details sind allerdings öffentlich.

Das eigentliche Risiko liegt im stillen Ausfall. Fällt clamd aus und ist die Mail- oder Upload-Kette nicht darauf ausgelegt, kann sie in zwei Richtungen kippen: Entweder bleiben Nachrichten liegen, oder ungeprüftes Material geht durch. Welche der beiden Varianten eintritt, entscheidet die eigene Konfiguration und nicht der Angreifer.

Was sollten Admins jetzt tun?

1. Version prüfen mit clamd --version oder clamscan --version. Alles unterhalb von 1.5.4 beziehungsweise 1.4.6 ist betroffen.
2. Auch Container erfassen: In mailcow, Nextcloud-Setups und eigenen Compose-Stacks steckt ClamAV oft in einem eigenen Image, das nicht mit dem Host-Paketmanager aktualisiert wird.
3. Aktualisieren auf 1.5.4 oder 1.4.6, danach den Dienst neu starten und einen Testscan mit der EICAR-Testdatei fahren, um zu bestätigen, dass die Prüfkette wieder läuft.
4. Verhalten bei Scanner-Ausfall klären: Lässt die Mail- oder Upload-Kette Dateien ungeprüft durch, wenn der Scanner nicht antwortet? Diese Frage jetzt beantworten, nicht erst im Vorfall.
5. Überwachung ergänzen: Ein Alarm auf einen nicht laufenden clamd ist wichtiger als der Scanner selbst, weil ein Ausfall sonst unbemerkt bleibt.
6. Bei Cisco-Produkten mit integrierter ClamAV-Engine das Herstelleradvisory prüfen und die dort genannten Softwarestände einplanen.

Einordnung für Unternehmen

ClamAV läuft in vielen kleinen Unternehmen als unauffällige Nebenkomponente, oft mitinstalliert durch ein Mailserver-Paket und danach nie wieder angefasst. Genau diese Komponenten fallen bei Update-Runden durch das Raster, weil sie keine Oberfläche haben und sich nicht melden. Der aktuelle Fall ist ein guter Anlass, den Bestand einmal zu erfassen und die Überwachung nachzuziehen.

Wichtig für die eigene Erwartungshaltung: ClamAV ist eine Basisprüfung, kein vollständiger Malware-Schutz. Der Wert liegt darin, bekannte Schadmuster früh in Mail- und Upload-Pfaden auszusortieren. Damit dieser Wert erhalten bleibt, muss der Dienst laufen und aktuelle Signaturen erhalten, beides gehört in die Überwachung.

Passende Anleitungen auf S-EDV

1. mailcow-Mailserver mit Docker aufsetzen zeigt den Aufbau, in dem ClamAV als eigener Container mitläuft.
2. Mailserver nativ mit Postfix, Dovecot und Rspamd für Installationen, in denen der Scanner direkt am Mailpfad hängt.
3. Container-Updates mit Diun und WUD im Blick behalten damit veraltete Scanner-Images nicht monatelang unbemerkt weiterlaufen.

Quellen

1. ClamAV-Blog: 1.5.4 and 1.4.6 security patch versions published
2. Cisco Security Advisory: ClamAV Vulnerabilities Affecting Cisco Products
3. OpenCVE: CVE-2026-20338
4. securityonline.info: Multiple ClamAV Flaws Let Remote Attackers Cause DoS