- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 10
- 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 14 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 14 days
acknowledgement within fourteen days and triage with a CVSS v3.1 score within thirty
- 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
13 assets you may test, 5 excluded.
Web 1
- https://katacontainers.io
Products and areas 12
- Attestation and confidential-containers paths where Kata implements them
- Both runtime implementations: the Go runtime and runtime-rs, including everything they build before a VM starts
- Integration with QEMU, Cloud Hypervisor and Firecracker as configured backends, covering the command lines and configuration Kata generates
- Pod and container annotations, which turn user-supplied Kubernetes metadata into runtime configuration on the host
- The agent policy engine and the checks it applies to requests arriving from the host side
- The CRI shim (containerd-shim-kata-v2) and the container lifecycle it manages
- The current SECURITY.md asks for private GitHub advisory reports against the Kata repository and routes them to a named Vulnerability Management Team. It sets no component boundary, so the runtime, the agent, the guest image and the hypervisor integrations are all inside it
- The Dragonball VMM in full, including its own virtio device implementations
- The guest image and initrd, the guest kernel configuration and the rootfs build pipeline
- The kata-agent inside the guest and the ttRPC channel the runtime drives it over
- The virtiofs data path, including how virtiofsd is invoked and every argument the runtime constructs for it
- Volume, device and block storage handling between host and guest, including direct-assigned block devices
Out of scope (5)
- Cluster configuration that grants a workload privileges the runtime was never intended to contain
- Defects inside QEMU, Cloud Hypervisor or Firecracker themselves, which run their own processes, unless Kata's configuration of them is what exposes the flaw
- Guest kernel defects rather than Kata's guest kernel configuration
- Issues already published as advisories on the repository
- Kubernetes and containerd defects above the runtime boundary
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Submit through sorona.xyz.
-
Report through GitHub private vulnerability reporting on kata-containers/kata-containers, the channel the current SECURITY.md names
-
Name the hypervisor backend and the runtime implementation.
-
Include the full pod spec with annotations.
-
If the root cause sits in virtiofsd, say so explicitly.
Not accepted
-
Defects inside QEMU, Cloud Hypervisor or Firecracker themselves
-
Kubernetes and containerd defects above the runtime boundary
-
Cluster configuration that grants a workload privileges the runtime was never intended to contain
-
Guest kernel defects rather than Kata's guest kernel configuration
-
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.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-44210 | Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. Versions prior to 3.31.0 ship with a default configuration that allows pod creators to inject arbitrary command-line arguments into the virtiofsd process through the `io.katacontainers.config.hypervisor.virtio_fs_extra_args` pod annotation. By injectin | Medium 5.8 | 23 Jul 2026 |
| CVE-2026-41326 | Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. From v3.4.0 to v3.28.0, an oversight in the CopyFile policy (and perhaps the CopyFile handler) allows untrusted hosts to write to arbitrary locations inside the guest workload image. This can be used to overwrite binaries inside the guest and exfiltrat | High 8.2 | 24 Apr 2026 |
| CVE-2026-24834 | Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. In versions prior to 3.27.0, an issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM. The current understanding is this | Critical 9.3 | 19 Feb 2026 |
| CVE-2026-24054 | Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. In versions prior to 3.26.0, when a container image is malformed or contains no layers, containerd falls back to bind-mounting an empty snapshotter directory for the container rootfs. When the Kata runtime attempts to mount the container rootfs, the bi | High 8.8 | 29 Jan 2026 |
| CVE-2020-27151 | An issue was discovered in Kata Containers through 1.11.3 and 2.x through 2.0-rc1. The runtime will execute binaries given using annotations without any kind of validation. Someone who is granted access rights to a cluster will be able to have kata-runtime execute arbitrary binaries as root on the worker nodes. | High 8.8 | 7 Dec 2020 |
| CVE-2020-28914 | An improper file permissions vulnerability affects Kata Containers prior to 1.11.5. When using a Kubernetes hostPath volume and mounting either a file or directory into a container as readonly, the file/directory is mounted as readOnly inside the container, but is still writable inside the guest. For a container breakout situation, a malicious guest can potentially modify or delete files/directori | High 7.1 | 17 Nov 2020 |
| CVE-2020-2023 | Kata Containers doesn't restrict containers from accessing the guest's root filesystem device. Malicious containers can exploit this to gain code execution on the guest and masquerade as the kata-agent. This issue affects Kata Containers 1.11 versions earlier than 1.11.1; Kata Containers 1.10 versions earlier than 1.10.5; and Kata Containers 1.9 and earlier versions. | Low 3.8 | 10 Jun 2020 |
| CVE-2020-2026 | A malicious guest compromised before a container creation (e.g. a malicious guest image or a guest running multiple containers) can trick the kata runtime into mounting the untrusted container filesystem on any host path, potentially allowing for code execution on the host. This issue affects: Kata Containers 1.11 versions earlier than 1.11.1; Kata Containers 1.10 versions earlier than 1.10.5; Kat | High 7.8 | 10 Jun 2020 |
| CVE-2020-2024 | An improper link resolution vulnerability affects Kata Containers versions prior to 1.11.0. Upon container teardown, a malicious guest can trick the kata-runtime into unmounting any mount point on the host and all mount points underneath it, potentiality resulting in a host DoS. | Medium 6.5 | 19 May 2020 |
| CVE-2020-2025 | Kata Containers before 1.11.0 on Cloud Hypervisor persists guest filesystem changes to the underlying image file on the host. A malicious guest can overwrite the image file to gain control of all subsequent guest VMs. Since Kata Containers uses the same VM image file with all VMMs, this issue may also affect QEMU and Firecracker based guests. | High 8.8 | 19 May 2020 |
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 10 Last 12 months 10 Lifetime Guest-to-host VM escape 40 % Command/argument injection 25 % Path traversal & symlink 20 % Policy bypass 15 % Latest advisories Loading the feed Overview Kata Containers boots each Kubernetes pod inside a real virtual machine, driving QEMU, Cloud Hypervisor, Firecracker or its own Dragonball VMM underneath, and it is the standard answer when a cluster needs hard multi-tenancy. Alibaba Cloud, Baidu and Red Hat's sandboxed containers all run on it. The project exists to make guest escape impossible, and the last twelve months produced ten advisories that are its entire published history, four of them critical. CVE-2026-47243 is the reference point: guest root to host root through virtiofs. The OpenInfra Foundation pays nothing for any of that, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The current SECURITY.md asks for private GitHub advisory reports against the Kata repository and routes them to a named Vulnerability Management Team. It sets no component boundary, so the runtime, the agent, the guest image and the hypervisor integrations are all inside it Both runtime implementations: the Go runtime and runtime-rs, including everything they build before a VM starts The kata-agent inside the guest and the ttRPC channel the runtime drives it over The virtiofs data path, including how virtiofsd is invoked and every argument the runtime constructs for it Pod and container annotations, which turn user-supplied Kubernetes metadata into runtime configuration on the host The Dragonball VMM in full, including its own virtio device implementations Integration with QEMU, Cloud Hypervisor and Firecracker as configured backends, covering the command lines and configuration Kata generates The guest image and initrd, the guest kernel configuration and the rootfs build pipeline Volume, device and block storage handling between host and guest, including direct-assigned block devices The CRI shim (containerd-shim-kata-v2) and the container lifecycle it manages The agent policy engine and the checks it applies to requests arriving from the host side Attestation and confidential-containers paths where Kata implements them Out of scope Defects inside QEMU, Cloud Hypervisor or Firecracker themselves, which run their own processes, unless Kata's configuration of them is what exposes the flaw Kubernetes and containerd defects above the runtime boundary Cluster configuration that grants a workload privileges the runtime was never intended to contain Guest kernel defects rather than Kata's guest kernel configuration Issues already published as advisories on the repository Most-valued findings Guest-to-host escape, the class the whole project exists to prevent. CVE-2026-47243 took guest root to host root through virtiofs, and GHSA-fgm4-mv68-h344 did it through a missing length check in Dragonball's virtio-blk Argument injection into a host-side process. CVE-2026-44210 reached virtiofsd through pod annotations that ship enabled by default, making a pod spec into a host command line Annotation handling generally, since a pod spec is attacker-controlled input in any multi-tenant cluster. CVE-2026-50540 loaded an arbitrary configuration path from one Symlink handling in host and guest file movement, the shape CVE-2026-41326 took when it subverted the CopyFile policy Anything that lets the guest drive the agent into acting on the host, or the host into resolving a guest-supplied path outside the sandbox Policy engine bypass, where a request the agent policy should refuse is carried out anyway Memory safety anywhere in the Dragonball device model, which is guest-facing by design and the newest code in the stack 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 through GitHub private vulnerability reporting on kata-containers/kata-containers, the channel the current SECURITY.md names The policy was rewritten on 2026-06-12 and is actively maintained, so read the live version rather than assuming the older text A named Vulnerability Management Team triages against OpenSSF-aligned targets: acknowledgement within fourteen days and triage with a CVSS v3.1 score within thirty A private embargo-notice mailing list carries the detail to downstream distributors before publication, so assume vendors see it during embargo Name the hypervisor backend and the runtime implementation. Dragonball, QEMU, Cloud Hypervisor and Firecracker are four different attack surfaces, and the Go runtime and runtime-rs behave differently Include the full pod spec with annotations. Several 2026 findings were driven entirely by annotations that are enabled by default If the root cause sits in virtiofsd, say so explicitly. That project has no security file of its own and reports route through here or through QEMU Disclosure Coordinated by the Kata Vulnerability Management Team through the GitHub private advisory workflow, with a CVE requested automatically at publication and the detail sent to a private embargo-notice list for downstream distributors first. The published targets are fourteen days to acknowledgement and thirty days to triage with a CVSS v3.1 score. Publication lands as a GitHub Security Advisory on the repository alongside the fixed release. 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