libarchive

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. libarchive qualifies at Tier 2 through its OSS-Fuzz integration, so the ceiling is $5,000 and not the $15,000 Tier 1 headline, and the 2× and 3× memory-safety multipliers are Tier 1 only. Patches must be one to twelve months old at submission, three a month per person, and sanctions and territory exclusions apply. CVE history 10 Last 12 months 111 Lifetime Memory safety 45 % Parsing/validation 30 % Denial of service 15 % Code execution 5 % Latest advisories Loading the feed Overview libarchive is the extraction engine behind bsdtar, the default tar on macOS and FreeBSD, along with Arch Linux's pacman, CMake's file(ARCHIVE_EXTRACT) and Homebrew. Every package manager that unpacks a downloaded artifact is a consumer, so an extraction-time path traversal here is a package-installation compromise across several distributions at once. It carries the highest CVE volume in its category by a wide margin, 111 lifetime and 10 in the last twelve months, which follows from the amount of attacker-controlled input passing through its dozen-plus format readers. [email protected] processes reports with no money attached, so sorona.xyz pays you directly on qualified, reproduced findings. In scope [email protected] takes security reports on libarchive itself, and the boundary the maintainers draw is that one: a defect in a downstream consumer belongs with that project. Everything below sits inside the library The format readers in full: tar with its GNU, pax and ustar extensions, cpio, .rpm-adjacent payloads, ISO9660, 7-Zip, RAR, ZIP, LHA, XAR and WARC, every one of which parses bytes an attacker chose The filter chain that sits under those readers: gzip, bzip2, xz, lzma, lz4, zstd and compress, including the transitions between filters Extraction-time path handling: .. traversal, absolute paths, symlink and hardlink placement, and ACL and extended-attribute restore, all of which can write outside the destination The bsdtar and bsdcpio command-line front ends, which are what macOS, FreeBSD and a great many scripts actually invoke Memory accounting for compressed data with hostile expansion ratios, where a small archive claims an allocation large enough to kill the process doing the install Out of scope Downstream consumers such as pacman, CMake and Homebrew rather than libarchive itself, which belong with those projects Distribution-specific patches rather than defects in upstream libarchive Raw fuzzer crashes with no merged fix behind them, which earn nothing on the Google patch pathway Performance and format-compatibility issues, which are quality problems rather than security ones One-line patches that fix non-exploitable crashes, including crashes that only amount to resource exhaustion, which the Patch Rewards rules say will not generally be rewarded Most-valued findings Memory corruption in a format reader driven purely by a crafted archive, the dominant bug class here at 45% and the one that reaches a package manager running as root Extraction-time path traversal, or symlink and hardlink placement, that writes a file outside the destination directory during an ordinary package install A parsing defect in one of the less-travelled readers such as RAR, LHA, XAR, WARC or ISO9660, since they get far less scrutiny than tar and ZIP but are reachable by content-sniffing callers Confusion at a filter-chain boundary, where the decompressor and the format reader disagree about how many bytes exist Decompression-bomb behaviour that is an accounting defect rather than an inherent property of the format, so a small input forces an unbounded allocation 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 to [email protected] with the archive that triggers it; if it cannot be reproduced from your write-up it is not eligible Show the bug in libarchive itself rather than in a downstream consumer such as pacman, CMake or Homebrew, which have their own maintainers Give the maintainers room to ship a fix before you publish, since a libarchive fix has to reach every package manager that links it If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for one month. That is a separate pathway with its own rules libarchive reaches Patch Rewards at Tier 2 through OSS-Fuzz, so the patch ceiling is $5,000 rather than the $15,000 Tier 1 headline, and the memory-safety multiplier does not apply; patches must be one to twelve months old, capped at three per person per month Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the libarchive maintainers through [email protected] . Patch Rewards imposes no confidentiality or embargo term of its own, so publication timing is upstream's call; upstream is active with frequent releases, so the window is usually short by the standards of this category. 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