- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 16
- 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.
- Replies within 3 days
- As the policy promises.
- 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 |
- Response
-
Within 3 days
Expect an initial response within three business days
- 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
16 assets you may test, 7 excluded.
Web 1
- https://github.com/cri-o/cri-o
Products and areas 15
- Checkpoint and restore through CRIU, including parsing of a checkpoint archive supplied from outside the node
- Confinement configuration: seccomp profiles and the seccomp notifier, AppArmor, SELinux labelling, capabilities and the no-new-privileges handling
- conmon and conmon-rs, the monitor process that sits between CRI-O and every container on the node, which the policy accepts through the same address
- Container and pod log handling, log paths and rotation, where the runtime writes files on behalf of a workload
- Device handling, volume and mount configuration, including how a path from a pod spec resolves on the host
- Image pull and storage through the shared containers/image and containers/storage code, plus registry configuration, mirrors, signature policy and short-name resolution
- Node-level resource features: CPU pinning, hugepages, RDT and the NRI plugin interface
- Pod sandbox setup in full: namespaces, cgroups, the pause process and the shared namespace model inside a pod
- systemd integration and the cgroup manager, including any property CRI-O sets on a transient unit
- The CNI network plugin boundary and the network namespace setup around it
- The CRI gRPC server and every RPC it serves: RunPodSandbox, CreateContainer, StartContainer, Exec, ExecSync, Attach, PortForward, PullImage and the rest, plus the socket they are served on
- The crio configuration surface, the drop-in configuration directory and the runtime handler definitions in it
- The metrics and monitoring endpoints CRI-O exposes on the node
- The OCI runtime boundary, covering runc and crun invocation, the generated OCI spec and how a runtime error is interpreted
- The policy asks for private report to the CNCF security list and deliberately widens scope beyond CRI-O itself to the projects it depends on, naming conmon and conmon-rs. It draws no boundary narrower than that
Out of scope (7)
- Deliberate cluster configuration, such as admitting privileged pods, granting hostPath mounts or disabling seccomp by policy
- Distribution packaging and downstream patches rather than upstream CRI-O
- OpenShift's own components layered above the runtime
- Public disclosure before the embargo lifts, which the policy sets automatically
- runc and crun themselves, where the defect is in the runtime rather than in the spec CRI-O generates or the way it invokes them
- The Kubernetes control plane and kubelet, which belong to the Kubernetes program and carry their own scope
- The Linux kernel primitives CRI-O configures
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 address on the policy page , the address named in SECURITY.md
-
GitHub private vulnerability reporting is disabled on cri-o/cri-o, so email is the channel
-
The policy accepts reports about projects CRI-O depends on as well as CRI-O itself, and names conmon and conmon-rs as examples. A finding in a dependency reachable through CRI-O belongs here
-
The policy explicitly invites reports where you are unsure how the issue affects CRI-O. Uncertainty is not a reason to hold a finding back on this channel
-
Expect an initial response within three business days
-
The embargo is automatic and runs until fixes have merged across all affected branches. CRI-O tracks Kubernetes minors in lockstep, so several release branches usually need the same patch
-
Check the OpenVEX documents CRI-O publishes per release before claiming a component is affected. The project states its own exploitability position there
-
There is no cash payment on this channel, and the one paid program in this layer names container escapes as ineligible for bounty
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 2 Last 12 months Container escape / confinement break 35 % Path traversal & symlink handling 30 % Configuration & property injection 20 % Denial of service 15 % Latest advisories Loading the feed Overview CRI-O implements the Kubernetes Container Runtime Interface, and it is the runtime under every Red Hat OpenShift cluster, since OpenShift ships it exclusively with no containerd option. That puts it beneath the largest enterprise Kubernetes distribution in production, on nodes that run untrusted workloads by design. CVE-2022-0811 is the reference point: abusing kernel.core_pattern through the runtime gave arbitrary code execution on the node. Reports go to a CNCF security list with a three-business-day response and an automatic embargo until fixes land on every branch. Nobody pays for a finding here, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for private report to the CNCF security list and deliberately widens scope beyond CRI-O itself to the projects it depends on, naming conmon and conmon-rs. It draws no boundary narrower than that The CRI gRPC server and every RPC it serves: RunPodSandbox, CreateContainer, StartContainer, Exec, ExecSync, Attach, PortForward, PullImage and the rest, plus the socket they are served on Pod sandbox setup in full: namespaces, cgroups, the pause process and the shared namespace model inside a pod The OCI runtime boundary, covering runc and crun invocation, the generated OCI spec and how a runtime error is interpreted conmon and conmon-rs, the monitor process that sits between CRI-O and every container on the node, which the policy accepts through the same address Confinement configuration: seccomp profiles and the seccomp notifier, AppArmor, SELinux labelling, capabilities and the no-new-privileges handling Container and pod log handling, log paths and rotation, where the runtime writes files on behalf of a workload Checkpoint and restore through CRIU, including parsing of a checkpoint archive supplied from outside the node Image pull and storage through the shared containers/image and containers/storage code, plus registry configuration, mirrors, signature policy and short-name resolution The CNI network plugin boundary and the network namespace setup around it Device handling, volume and mount configuration, including how a path from a pod spec resolves on the host systemd integration and the cgroup manager, including any property CRI-O sets on a transient unit The crio configuration surface, the drop-in configuration directory and the runtime handler definitions in it Node-level resource features: CPU pinning, hugepages, RDT and the NRI plugin interface The metrics and monitoring endpoints CRI-O exposes on the node Out of scope The Kubernetes control plane and kubelet, which belong to the Kubernetes program and carry their own scope runc and crun themselves, where the defect is in the runtime rather than in the spec CRI-O generates or the way it invokes them The Linux kernel primitives CRI-O configures OpenShift's own components layered above the runtime Deliberate cluster configuration, such as admitting privileged pods, granting hostPath mounts or disabling seccomp by policy Distribution packaging and downstream patches rather than upstream CRI-O Public disclosure before the embargo lifts, which the policy sets automatically Most-valued findings Anything that gets code running on the node from inside a container. CVE-2022-0811 reached arbitrary execution by abusing kernel.core_pattern through the runtime, and that is the highest-severity thing this project has produced Confinement breaks of any kind: cgroup escapes of the CVE-2023-6476 shape, namespace setup errors or seccomp and AppArmor profiles that do not apply as configured Property and configuration injection into the layer beneath, particularly systemd properties on a transient unit as CVE-2024-3154 achieved Path traversal and symlink handling wherever CRI-O writes on behalf of a workload. CVE-2025-0750 turned log path handling into an arbitrary file write, and CVE-2024-5154 used a symlink on the host mtab Checkpoint archive parsing, which takes attacker-supplied structured input directly. CVE-2024-8676 got arbitrary node access from a malformed checkpoint file Resource exhaustion on the node from container-controlled input, the class CVE-2025-4437 landed in with an oversized /etc/passwd Findings in conmon or conmon-rs, which the policy accepts explicitly. conmon is C, sits as the monitor for every container on RHEL and OpenShift nodes, and is invisible to package-ecosystem dependency scanners Anything in the shared containers/image and containers/storage code reachable through image pull, since one defect there carries across Podman, Buildah and Skopeo at the same time Cross-pod reach: any path where one pod's sandbox affects another's namespaces, mounts, devices or logs on the same node 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 [email protected] , the address named in SECURITY.md GitHub private vulnerability reporting is disabled on cri-o/cri-o, so email is the channel The policy accepts reports about projects CRI-O depends on as well as CRI-O itself, and names conmon and conmon-rs as examples. A finding in a dependency reachable through CRI-O belongs here The policy explicitly invites reports where you are unsure how the issue affects CRI-O. Uncertainty is not a reason to hold a finding back on this channel Expect an initial response within three business days The embargo is automatic and runs until fixes have merged across all affected branches. CRI-O tracks Kubernetes minors in lockstep, so several release branches usually need the same patch Check the OpenVEX documents CRI-O publishes per release before claiming a component is affected. The project states its own exploitability position there There is no cash payment on this channel, and the one paid program in this layer names container escapes as ineligible for bounty Disclosure Coordinated privately through the CNCF security list, with an initial response inside three business days and an automatic embargo that holds until fixes have merged across every affected branch. CRI-O releases in lockstep with Kubernetes minors and OpenShift consumes it directly, so the practical window is set by that release train rather than by a fixed day count. Note that this project publishes very few advisories on its own repository even where a CVE exists, so absence of a repo advisory is not evidence a fix never shipped. 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