The Sleuth Kit

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 land upstream yourself and that stays merged, without reverts, for one month. It does not pay for the report. This project sits in Tier 2, where awards run from $100 to $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. Patches must be between one and twelve months old, submissions are capped at three per person per month, memory-safety hardening can carry a 2× or 3× multiplier, and sanctions and territory exclusions apply. CVE history 3 Last 12 months 18 Lifetime Memory safety 55 % Parsing/validation 25 % Denial of service 15 % Info disclosure 4 % Latest advisories Loading the feed Overview The Sleuth Kit is the filesystem-forensics engine of the open-source DFIR world and, through Autopsy, of law-enforcement and corporate investigation practice. It ships in Kali, SIFT, REMnux and CAINE, its libraries are embedded in commercial forensic suites, and automated triage pipelines point it at disk images at scale. The threat model is inverted: the input is a disk image taken from a machine the attacker controlled, the parser is decades-old C reading on-disk structures with almost no sanity guarantees, and the operator is an examiner on a workstation inside the investigating organisation. An attacker who expects to be imaged can plant a filesystem structure that runs code on the examiner's box. The project pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go to [email protected] , per the repository's SECURITY.md, against upstream sleuthkit/sleuthkit . Autopsy is a separate repository, so the boundary is the TSK tree and all of it The filesystem layer in tsk/fs in full: NTFS, FAT12/16/32 and exFAT, Ext2/3/4, HFS+, APFS, UFS, YAFFS2, ISO9660 and everything else it claims to read The volume-system layer in tsk/vs , covering DOS, GPT, BSD and Sun partition tables The image layer in tsk/img , covering the raw, AFF, E01/EWF, VMDK and VHD containers that are parsed before any filesystem logic runs The command-line tools investigators point straight at seized media, tsk_recover , fls , icat , mmls and blkls among them The Java bindings in bindings/java and the SQLite case database that Autopsy drives on top of them The carving code paths and the hash-database lookups, NSRL handling included Out of scope Autopsy itself, which is a separate repository and not part of this target Third-party ingest modules and Autopsy plugins, which are neither maintained nor merged here Non-exploitable crashes whose fix is a one-liner, which Google explicitly declines to reward on the patch rail Patches over twelve months old, which Patch Rewards will not consider For the Google money specifically, anything reported but never patched upstream, since that pathway pays only on a merge Most-valued findings Heap corruption in an tsk/fs parser driven purely by the bytes of a crafted image, since memory safety is 55% of this project's history and the image is the one input the examiner cannot vouch for A defect in the E01/EWF, AFF or VMDK container layer, which is parsed before any filesystem logic runs and therefore sits earliest on the attacker's path Partition-table and volume-system confusion in tsk/vs that makes the tools read structures outside the extent they believe they are reading Anything reachable through fls , icat or tsk_recover as an examiner runs them in the ordinary triage sequence, rather than through a flag nobody uses Bugs in the Java bindings or the case database that let a hostile image influence what Autopsy stores and later renders to the investigator 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 and attach the disk or filesystem image that triggers it; if the maintainers can't reproduce it, it isn't eligible One vulnerability per report unless a chain is needed to show the real impact Only upstream sleuthkit/sleuthkit counts. Autopsy is a separate repository and is not covered here Give the maintainers room to ship a fix before any public writeup; upstream moves at a slower cadence than most projects on this rail If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month. The patch must be between one and twelve months old and you may submit at most three a month Google cannot pay researchers on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated with the maintainers through [email protected] , per the repository's SECURITY.md. Upstream review is slower than most projects on this rail, so allow real time before publishing; nothing in the Google rules restricts routing the finding through sorona.xyz. 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