- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
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.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
12 assets you may test, 5 excluded.
Web 1
- https://github.com/seccomp/libseccomp
Products and areas 11
- Architecture and multi-architecture support, including the syscall number translation tables for every supported ABI
- Argument comparison logic, particularly 64-bit argument handling and any merging or optimisation applied across comparisons
- Filter export and import, including seccomp_export_bpf and seccomp_export_pfc and anything that parses those outputs
- Memory allocation and object lifetime across the whole library, since callers hold filter contexts for the life of a process
- Support for the user notification interface and the file descriptor handling around it
- Syscall table generation and the pseudo-syscall handling for architectures with multiplexed calls
- The BPF code generator, covering instruction ordering, jump resolution and the exact filter it emits
- The filter construction API in full: seccomp_init, seccomp_rule_add and every variant, along with the attribute setters and the reset path
- The internal rule database and the transaction machinery behind it
- The published Security Vulnerability Handling Process asks for reports to the named maintainers, works to a 90-day default disclosure window and notifies linux-distros and oss-security at disclosure. It declares no boundary narrower than the library itself
- The scmp_bpf_sim tool and the Python bindings shipped with the project
Out of scope (5)
- A weak policy a caller wrote deliberately, such as a runtime that allowlists a dangerous syscall on purpose
- Defects in a consumer's use of the API rather than in the library's behaviour
- Distribution packaging and downstream patches
- Issues already published as advisories on the repository
- Kernel-side seccomp defects, which belong to the Linux kernel security process
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report privately to the two named maintainers, Paul Moore and Tom Hromatka, as the published Security Vulnerability Handling Process directs, or through GitHub advisory reporting on seccomp/libseccomp
-
The process runs a 90-day default disclosure window and develops the fix in a private fork before merging
-
Show the emitted filter. seccomp_export_bpf and seccomp_export_pfc output alongside the rule set is the clearest possible reproduction on this codebase
-
Name the architecture and the ABI. Multi-architecture filters and secondary ABIs are where the translation logic gets thin
Not accepted
-
Kernel-side seccomp defects, which belong to the Linux kernel security process
-
A weak policy a caller wrote deliberately, such as a runtime that allowlists a dangerous syscall on purpose
-
Defects in a consumer's use of the API rather than in the library's behaviour
-
Distribution packaging and downstream patches
-
Issues already published as advisories on the repository
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
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 CVE history 3 Last 12 months Memory safety 40 % Sandbox policy weakening 35 % Incorrect argument comparison 15 % Denial of service 10 % Latest advisories Loading the feed Overview libseccomp is the userspace library that compiles a syscall policy into a BPF filter, and nearly every container runtime links it: Docker, containerd, runc, crun, Podman and systemd, along with Firefox and Chrome. A defect here degrades every one of those sandboxes at once. Three advisories landed on a single day in July 2026, and the sharpest was an incorrect 64-bit comparison merge that silently produced a weaker filter than the policy asked for. Two maintainers run a documented handling process with a 90-day window and no money attached, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The published Security Vulnerability Handling Process asks for reports to the named maintainers, works to a 90-day default disclosure window and notifies linux-distros and oss-security at disclosure. It declares no boundary narrower than the library itself The filter construction API in full: seccomp_init, seccomp_rule_add and every variant, along with the attribute setters and the reset path The internal rule database and the transaction machinery behind it The BPF code generator, covering instruction ordering, jump resolution and the exact filter it emits Argument comparison logic, particularly 64-bit argument handling and any merging or optimisation applied across comparisons Architecture and multi-architecture support, including the syscall number translation tables for every supported ABI Syscall table generation and the pseudo-syscall handling for architectures with multiplexed calls Filter export and import, including seccomp_export_bpf and seccomp_export_pfc and anything that parses those outputs Support for the user notification interface and the file descriptor handling around it Memory allocation and object lifetime across the whole library, since callers hold filter contexts for the life of a process The scmp_bpf_sim tool and the Python bindings shipped with the project Out of scope Kernel-side seccomp defects, which belong to the Linux kernel security process A weak policy a caller wrote deliberately, such as a runtime that allowlists a dangerous syscall on purpose Defects in a consumer's use of the API rather than in the library's behaviour Distribution packaging and downstream patches Issues already published as advisories on the repository Most-valued findings Anything that makes the emitted filter permit a syscall the policy denied. The July 2026 comparison-merge bug did exactly that, and a silently weakened filter is a sandbox bypass for every runtime that linked the library Argument comparison errors, particularly on 64-bit values where the high and low halves are handled separately Memory corruption reachable from filter construction. Two of the July 2026 advisories were heap corruption and a double free triggered by oversized filters Architecture translation errors, where a syscall number maps to the wrong call on a secondary ABI and the filter guards nothing Defects in filter import and export parsing, since that output is consumed by tooling that may take it from an untrusted source Rule ordering or optimisation defects that change the semantics of a policy after the rules were added User notification handling that lets a supervised process race its supervisor 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. Report privately to the two named maintainers, Paul Moore and Tom Hromatka, as the published Security Vulnerability Handling Process directs, or through GitHub advisory reporting on seccomp/libseccomp The process runs a 90-day default disclosure window and develops the fix in a private fork before merging Disclosure includes mandatory notification of linux-distros and oss-security, so assume the detail reaches distribution security teams and a public list on a schedule you do not control A silently weakened filter is the highest-value finding here. If your bug makes the emitted BPF permit something the policy denied, say so in the first line Show the emitted filter. seccomp_export_bpf and seccomp_export_pfc output alongside the rule set is the clearest possible reproduction on this codebase Name the architecture and the ABI. Multi-architecture filters and secondary ABIs are where the translation logic gets thin Consumers matter for severity. Say which of the runtimes linking this library inherit the weakness through their default profiles Disclosure Coordinated with the two named maintainers under the published handling process, with a 90-day default window, the fix developed in a private fork and mandatory notification of linux-distros and oss-security at disclosure. Publication lands as advisories on the repository with CVE identifiers, and the July 2026 record shows three released together, so expect batching rather than individual releases. 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