ClamAV

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. ClamAV qualifies at Tier 2 through its OSS-Fuzz integration, which caps at $5,000 and does not carry the Tier 1 memory-safety multiplier. Patches must be between one and twelve months old, Cisco Talos holds a veto, the panel may split the award with them, and it is rate-limited to three submissions a month. Sanctions and territory exclusions apply. CVE history 10 Last 12 months 151 Lifetime Memory safety 45 % Denial of service 25 % Parsing/validation 20 % Code execution 8 % Latest advisories Loading the feed Overview ClamAV is the default open-source anti-virus engine of the mail world. It ships inside effectively every self-hosted mail stack, from Mailcow and Mailu to Zimbra and Proxmox Mail Gateway, is wired into the standard content-filter chain through amavisd-new, MailScanner, ClamSMTP and Rspamd, and beyond mail it is the default file-upload scanner for a long list of web applications and NAS appliances. Its entire job is to parse hostile files on an unattended process, so it carries 151 lifetime CVEs, several times any other project in this niche and on a much smaller codebase, 45 percent of them memory safety. Cisco Talos maintains it actively and pays nothing for a vulnerability report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope ClamAV publishes its security policy in the Cisco-Talos/clamav repository and takes reports on the engine through it. Signature-database and detection-quality questions sit outside, since those are a content matter rather than a defect in the code, and everything below sits inside The scanning engine and every file-format parser it ships: OLE2, PDF, HFS+, UDF, XAR, ARJ, CHM and the various unpackers, all of them driven by a file an attacker chose Archive and container handling end to end, including the size and offset arithmetic that a later allocation or copy trusts The bytecode interpreter, which executes signature logic against attacker-supplied content The database and signature-file loading path, where the engine parses files it did not itself produce The clamd daemon and its client tooling, covering the scan protocol, the worker model, and the sandboxing and privilege separation that decide what a parser bug reaches once it fires The Rust components already in the tree and the ongoing migration of untrusted-input parsers from C to Rust, a named qualifying-patch category Out of scope A vulnerability report on its own where the patch money is concerned: that rail pays only on a change merged upstream that then survives a month without reverts One-liner patches that fix non-exploitable crashes, and denial of service by resource exhaustion, which is called out by name and which describes a large fraction of ClamAV's historical fuzz findings Signature-database or detection-quality issues, which are not a question about the security of the code Patches Cisco Talos declines, since Google explicitly declines to second-guess a maintainer's decision Patches outside the one-to-twelve-month age window, and anything past three submissions per person per month The Tier 1 ceiling and the Tier 1 memory-safety multiplier, neither of which ClamAV can reach: it qualifies at Tier 2 through OSS-Fuzz, not as a named Tier 1 project Most-valued findings Memory corruption in a file-format parser reachable from a sample that arrives as an ordinary mail attachment, which is 45 percent of the record and the highest-value class here because the engine parses hostile input by design Anything that turns a scanned sample into code execution in the scanner process, since clamd runs unattended and pre-authentication on every attachment reaching the gateway A structural fix that hardens a whole parser family rather than one format, since the top reward band is for changes that almost certainly prevent major vulnerabilities in the affected code Porting one of the untrusted-input parsers to Rust, which the project has already started and which removes an entire class rather than one instance of it Scanner-versus-consumer parsing divergence that lets malware through the gateway intact, which is a real bypass rather than the resource-exhaustion crash the program declines to pay for Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report with the sample that triggers it; if we can't reproduce it, it isn't eligible Report through the security policy published in the Cisco-Talos/clamav repository and give Talos room to ship a fix before any public writeup Signature-database and detection-quality complaints are not security findings. A missed or false detection is a content question rather than a defect in the code Resource-exhaustion denial of service is explicitly not rewarded on the patch rail, which rules out a large share of naive fuzz output here If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month. That is a separate pathway with its own one-to-twelve-month age window and a cap of three submissions a month Disclosure Coordinated with Cisco Talos through the repository's published security policy, and fixes arrive in ClamAV's own releases with an advisory. Routing works here: the Patch Rewards rules contain no confidentiality, embargo or third-party clause, only sanctions and territory limits, and the patch money is claimed on a change that is public by the time you claim it. Hold the detail until the fixed release is out. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability