Cisco has warned about a batch of vulnerabilities in the ClamAV engine that ships inside its Secure Endpoint Connector. Seven flaws, disclosed on August 7, all let an unauthenticated remote attacker crash the malware scanner by feeding it a crafted file. Two of them already have public proof-of-concept code, which is why the advisory is getting attention.
What was disclosed
The vulnerabilities live in ClamAV’s file parsers, and most of the noise is around ZIP archives. CVE-2026-20337 is an out-of-bounds write in the ZIP parser. Improper boundary validation means a specially crafted archive can crash the scanning process when it is submitted for inspection. CVE-2026-20338 is the other one with public exploit code. Both are rated high severity, with CVE-2026-20337 scoring 7.5 on the CVSS scale.
They affect the Secure Endpoint Connector on Windows, macOS, and Linux. Across the whole advisory, Cisco counts seven ClamAV flaws, and all of them share the same pattern: an unauthenticated attacker submits a malicious file, the scanner chokes, and the process dies. The practical effect is a denial of service that silently switches off your malware detection.
Why a scanner crash matters
A DoS on an antivirus engine is easy to wave off as less serious than a code execution bug. That is the wrong read here. When the ClamAV process crashes, the endpoint’s protection against everything arriving after that point is gone. And the trigger is something you cannot fully control, because it is the same class of file your mail gateway and web filter are supposed to be scanning in the first place.
The attack surface is also bigger than Cisco’s own product line. ClamAV is open source and widely embedded, not just by Cisco but by mail servers, file-scanning appliances, and security tools that wrap the engine. Parser flaws in a library that lives inside that many products tend to echo well beyond the original vendor advisory. Anyone running software that bundles ClamAV needs to check whether their build is affected, not just customers of Cisco Secure Endpoint.
The public exploit angle
Public proof-of-concept code changes the timeline. A flaw with a working PoC in the open is one that threat actors can adapt quickly, and file-based attacks are exactly what automated scanning tools and exploit frameworks are good at repackaging. The disclosure also came on a Friday, which historically gives defenders a short window to patch before the weekend slows down their response teams.
It is not yet clear that the two public PoCs are being exploited in the wild, and none of the reporting has suggested active mass exploitation. But the bar for turning a DoS PoC into a nuisance attack is lower than for most vulnerability classes, so waiting to see if it gets weaponized is the wrong posture.
Checking whether you are exposed takes a couple of steps. For Cisco Secure Endpoint, confirm the Connector version against the fixed release in the advisory. For other products that bundle ClamAV, look at the library version reported by your software, then cross reference it with the patched upstream ClamAV release. The tricky part is that many appliances do not expose the embedded ClamAV version directly, so a quick call to the vendor’s patch notes is usually faster than digging through your own logs.
How to respond
The immediate step is to patch the Secure Endpoint Connector to the fixed versions in Cisco’s advisory. If the endpoint software you run bundles ClamAV independently, check the version you are on and pull the corresponding upstream fix, because the parser bug is not Cisco specific.
Until patching is done, some teams choose to reduce exposure rather than disable scanning entirely, because disabling the scanner recreates the risk the bug is supposed to exploit. Lower profile measures work too: make sure scanning happens in an isolated process that restarts cleanly on crash, and add alerting on scanner process restarts so a crash does not go unnoticed.
On the network side, treat any sudden spike of scanner crashes as a signal, not noise. A series of ClamAV process restarts across your fleet may mean an attacker is probing with crafted files. That is exactly the kind of event that should page someone, especially right after a vendor posts public exploit code.
The broader pattern
This is part of an ongoing theme across security tooling: the defenses themselves are software, and software has bugs. An email gateway crash from a malicious attachment, an antivirus that dies on a crafted archive, a security agent that gets taken down by a malformed request. The tools you rely on to catch attacks can themselves be the weakest link.
The response is not to stop trusting the scanner. It is to treat the security stack as production infrastructure that needs patching, version tracking, and crash monitoring like everything else. Publicly disclosed scanner bugs with working exploit code are a reminder that defense in depth only works if the layers underneath the front line are kept current.
Check your ClamAV version today, patch if you are on an affected build, and add alerting for scanner crashes. That combination covers the actual risk here, which is not the crash itself but the detection gap it leaves behind.