Skip to content

containerd

Bug bounty on Sorona containerd.io

Accepting reports open-source
Top reward
$1,500
Top severity paid
Critical
Assets in scope
15
Public CVEs
25
Last change
No changes yet

At a glance

What to know before you start testing.

Pays from $1,500
for critical bugs.
Partial safe harbor
Some legal protection; read the terms.
Replies within 1 day
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 Reward
Critical $1,500+
High $700+
Medium $300+
Low $100 $100 / 1 month Claude Max
Response
Within 1 days Acknowledgement comes within 24 hours
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

15 assets you may test, 6 excluded.

Web 1

  • https://containerd.io

Products and areas 14

  • ctr and the other command line tools the project ships
  • Every snapshotter the project ships, including overlayfs, native, btrfs, devmapper and zfs, along with the mount setup each performs
  • Exec, attach and the streaming endpoints that carry a process's input and output
  • Image unpacking and the archive handling behind it, covering tar entries, symlinks, hard links, device nodes and whiteout files
  • The content store, the lease and garbage collection machinery, and the metadata database behind them
  • The CRI plugin, the interface Kubernetes drives containerd through, including sandbox and container lifecycle operations
  • The events subsystem, the NRI plugin interface and the plugin loading path
  • The gRPC API and the socket it listens on, including the permissions on that socket and what a local caller can do through it
  • The image pull path in full: manifest and index handling, layer download, digest verification and OCI media type dispatch
  • The isolation primitives containerd configures on a workload's behalf: namespaces, cgroups, capabilities, seccomp profiles, AppArmor and SELinux labels, and user namespace ID mapping
  • The published policy asks for a private GitHub Security Advisory on containerd/containerd and declares no boundary narrower than the containerd tree. Everything below sits inside that
  • The registry client and its authentication: credential handling, token exchange, registry mirrors and redirect following
  • The runtime shim and the v2 shim API, plus the OCI runtime specification containerd generates and hands to runc
  • The Windows path through hcsshim where containerd drives it
Out of scope (6)
  • A container an operator deliberately ran privileged, with host namespaces, or with a host path mounted in
  • Docker and Moby's own daemon above containerd, and the kubelet above the CRI plugin
  • Reports filed as public GitHub issues rather than through the private advisory flow
  • runc and other OCI runtimes, which are separate projects with their own security processes, unless the defect is in the specification containerd generates
  • The host kernel, including its namespace and cgroup implementations
  • Third-party snapshotters and plugins not shipped in the containerd tree

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 containerd/containerd
  • Do not file this at the Kubernetes HackerOne programme.
  • State the runtime configuration precisely: shim version, snapshotter, whether user namespaces were enabled and whether the workload ran under Kubernetes or Docker.
  • Show the path from a container or an image to the effect on the host.
  • Hold detail until the advisory and the patched release are public.

Not accepted

  • A privileged container reaching the host is the documented behaviour of a privileged container

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.

Search NVD

Sorona credits this project with 25 CVEs, 8 of them recent. The individual records appear here after the next sync.

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 8 Last 12 months 25 Lifetime Container escape 35 % Access control 25 % Path traversal 25 % Info disclosure 15 % Latest advisories Loading the feed Overview containerd is the runtime under most of the world's production container hosts. It is the default CRI runtime for Kubernetes and the engine inside Docker, so it is the privileged process that pulls images, unpacks their layers, sets up namespaces and cgroups, and builds the boundary between a container and its host. A defect that crosses that boundary hands an attacker the node and every other workload scheduled on it. containerd sits in its own GitHub organisation, outside the paid Kubernetes bug bounty, and runs no programme of its own. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for a private GitHub Security Advisory on containerd/containerd and declares no boundary narrower than the containerd tree. Everything below sits inside that The CRI plugin, the interface Kubernetes drives containerd through, including sandbox and container lifecycle operations The image pull path in full: manifest and index handling, layer download, digest verification and OCI media type dispatch Image unpacking and the archive handling behind it, covering tar entries, symlinks, hard links, device nodes and whiteout files Every snapshotter the project ships, including overlayfs, native, btrfs, devmapper and zfs, along with the mount setup each performs The runtime shim and the v2 shim API, plus the OCI runtime specification containerd generates and hands to runc The gRPC API and the socket it listens on, including the permissions on that socket and what a local caller can do through it The isolation primitives containerd configures on a workload's behalf: namespaces, cgroups, capabilities, seccomp profiles, AppArmor and SELinux labels, and user namespace ID mapping The registry client and its authentication: credential handling, token exchange, registry mirrors and redirect following The content store, the lease and garbage collection machinery, and the metadata database behind them Exec, attach and the streaming endpoints that carry a process's input and output The events subsystem, the NRI plugin interface and the plugin loading path ctr and the other command line tools the project ships The Windows path through hcsshim where containerd drives it Out of scope runc and other OCI runtimes, which are separate projects with their own security processes, unless the defect is in the specification containerd generates Docker and Moby's own daemon above containerd, and the kubelet above the CRI plugin A container an operator deliberately ran privileged, with host namespaces, or with a host path mounted in The host kernel, including its namespace and cgroup implementations Third-party snapshotters and plugins not shipped in the containerd tree Reports filed as public GitHub issues rather than through the private advisory flow Most-valued findings Container escape to the host through the shim, the mount setup or the OCI specification containerd builds. This is the highest-severity class the project has and it takes the node with it Image unpack defects where a crafted layer writes outside the snapshot root, through path traversal, symlink following or hard link handling Registry client defects where a redirect, a mirror or a manifest an attacker controls causes containerd to fetch or trust content it should reject, including digest verification that does not actually verify The gRPC socket, where a local user with access to it creates a container with privileges the platform above containerd never granted them Isolation primitives that do not apply as configured: a seccomp profile, capability set, AppArmor label or user namespace mapping that is silently weaker than the specification asked for User namespace and ID mapping errors, where a UID inside the container resolves to a privileged UID outside it Snapshotter defects that expose one container's layers or writable upper directory to another Credential and token disclosure through events, logs or the metadata database, since registry credentials there reach the whole image supply chain 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 containerd/containerd , the channel SECURITY.md in the containerd/project repository documents. Acknowledgement comes within 24 hours Do not file this at the Kubernetes HackerOne programme. containerd is a separate GitHub organisation and that paid scope does not reach it The embargoed security-announce list is sponsor-gated and exists to notify distributors. It is not the reporting channel and joining it is not a prerequisite State the runtime configuration precisely: shim version, snapshotter, whether user namespaces were enabled and whether the workload ran under Kubernetes or Docker. The boundary differs in each Show the path from a container or an image to the effect on the host. A privileged container reaching the host is the documented behaviour of a privileged container Nothing is paid at any severity and there are no reward terms to accept Disclosure Coordinated through the GitHub advisory flow with the containerd maintainers, who acknowledge within a day and notify distributors through an embargoed announce list before publishing. Because containerd ships inside Kubernetes distributions and Docker, the embargo runs to the coordinated patch release across those consumers rather than to a fixed day count. Hold detail until the advisory and the patched release are public. 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