- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 16
- Public CVEs
- 24
- 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 acknowledgement inside 72 hours, and a draft GitHub Security Advisory once the report is confirmed
- 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/moby/moby
Products and areas 15
- Bind mounts, volumes and mount propagation, including how a path supplied by a container is resolved against the host filesystem
- Docker's published disclosure policy asks for private email reports and declares scope over the open-source projects Docker maintains. It carves nothing narrower out of the engine, so everything the daemon does is fair game
- Image pull and push, the registry client, manifest and layer handling, content trust and credential storage
- Logging drivers, the events stream and the metrics endpoint
- Networking through libnetwork: the bridge driver, port publishing, the iptables and nftables rules the daemon writes, firewalld integration, overlay networks and embedded DNS
- Rootless mode in full, and the differences in the privilege model it introduces
- Storage and graph drivers, overlay2 in particular, and layer extraction from untrusted images
- Swarm mode: the raft store, node join and TLS bootstrap, secrets and configs, and the cluster control plane
- The archive and copy paths, covering docker cp in both directions and the archive endpoints that back it
- The containerd and runc integration boundary, including shim handling and how runtime errors are interpreted
- The container lifecycle end to end, from create and start through exec, attach, pause and remove
- The daemon's own configuration surface, including daemon.json, the socket permission model and TLS-protected remote access
- The Engine API in full: every endpoint under containers, images, networks, volumes, plugins, exec, swarm, system and the socket they are served on
- The isolation setup the daemon performs before handing off: namespaces, cgroups, capabilities, and the generated seccomp and AppArmor profiles
- The plugin system: authorization plugins, volume and network plugins, plugin installation and the privilege model that governs what a plugin may request
Out of scope (7)
- BuildKit, which ships as a separate project with its own policy and its own entry here
- containerd and runc, which are separate upstream projects with their own security channels
- Deliberate operator choices, such as exposing the daemon socket to a container, running containers privileged or publishing the API on a network without TLS
- Docker Desktop's proprietary components and the Docker Hub service, which sit outside the moby/moby tree
- Reports filed publicly on GitHub before coordination, which the policy rules out
- The Linux kernel primitives the daemon configures, where the defect is in the kernel rather than in what Docker asked for
- Third-party plugins that are not part of the engine
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 by email to the address on the policy page , the channel named in moby/moby's SECURITY.md and in Docker's published vulnerability disclosure policy
-
Do not open a public GitHub issue for a security problem; the policy rules it out explicitly
-
GitHub private vulnerability reporting is disabled on moby/moby, so the advisory button is not available here even though Docker publishes advisories prolifically
-
Expect acknowledgement inside 72 hours, and a draft GitHub Security Advisory once the report is confirmed
-
The disclosure timeline and embargo are negotiated with the security team rather than fixed at a published day count
-
Docker offers swag and public credit for critical and high findings. There is no cash payment to negotiate and no reward terms to accept
-
State the engine version, the storage driver and whether the daemon was running rootless. Several recent findings turn on exactly those variables
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.
Sorona credits this project with 24 CVEs, 7 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 7 Last 12 months 24 Lifetime Container escape to host 40 % Authorization bypass 30 % Network exposure 20 % Input validation 10 % Latest advisories Loading the feed Overview Docker Engine is the Moby daemon behind docker , and it runs on a very large share of all Linux servers, inside every Docker Desktop install and on most CI runners. Its whole job is to hold the line between a container and the host it sits on. CVE-2026-41567 is the reference point: a request to PUT /containers/{id}/archive could get a binary from inside the container executed on the host. Docker's disclosure policy states in writing that there is no paid bounty, and its VDP offers swag and public credit instead. sorona.xyz pays you directly on qualified, reproduced findings. In scope Docker's published disclosure policy asks for private email reports and declares scope over the open-source projects Docker maintains. It carves nothing narrower out of the engine, so everything the daemon does is fair game The Engine API in full: every endpoint under containers, images, networks, volumes, plugins, exec, swarm, system and the socket they are served on The container lifecycle end to end, from create and start through exec, attach, pause and remove The archive and copy paths, covering docker cp in both directions and the archive endpoints that back it Bind mounts, volumes and mount propagation, including how a path supplied by a container is resolved against the host filesystem The plugin system: authorization plugins, volume and network plugins, plugin installation and the privilege model that governs what a plugin may request Image pull and push, the registry client, manifest and layer handling, content trust and credential storage Storage and graph drivers, overlay2 in particular, and layer extraction from untrusted images Networking through libnetwork: the bridge driver, port publishing, the iptables and nftables rules the daemon writes, firewalld integration, overlay networks and embedded DNS The isolation setup the daemon performs before handing off: namespaces, cgroups, capabilities, and the generated seccomp and AppArmor profiles The containerd and runc integration boundary, including shim handling and how runtime errors are interpreted Rootless mode in full, and the differences in the privilege model it introduces Swarm mode: the raft store, node join and TLS bootstrap, secrets and configs, and the cluster control plane Logging drivers, the events stream and the metrics endpoint The daemon's own configuration surface, including daemon.json, the socket permission model and TLS-protected remote access Out of scope containerd and runc, which are separate upstream projects with their own security channels The Linux kernel primitives the daemon configures, where the defect is in the kernel rather than in what Docker asked for Docker Desktop's proprietary components and the Docker Hub service, which sit outside the moby/moby tree BuildKit, which ships as a separate project with its own policy and its own entry here Deliberate operator choices, such as exposing the daemon socket to a container, running containers privileged or publishing the API on a network without TLS Third-party plugins that are not part of the engine Reports filed publicly on GitHub before coordination, which the policy rules out Most-valued findings Any path from inside a container to code execution or a file write on the host. CVE-2026-41567 got a container's own binary executed on the host through the archive endpoint, and that class is the highest-value thing this codebase produces Races in path resolution during copy and archive operations. CVE-2026-42306 redirected a bind mount to a host path by winning a race in docker cp Authorization plugin bypass, where a request that the plugin should reject reaches the daemon anyway. CVE-2026-34040 did it with an oversized request body Defects in the plugin privilege model, including off-by-one and boundary errors in privilege validation of the CVE-2026-33997 shape Firewall and network rule generation that leaves a published port or a container network reachable from somewhere it should not be, the class the 2025 firewalld pair landed in Anything that lets an unauthenticated caller on the API socket reach daemon-level operations, and anything that widens what a container-reachable socket can do Untrusted image handling: manifest, layer and archive parsing where a crafted image affects the host during pull or unpack Rootless mode escapes, where the reduced privilege model turns out not to hold Swarm control-plane defects that let one node read or write another's secrets and configs 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 by email to [email protected] , the channel named in moby/moby's SECURITY.md and in Docker's published vulnerability disclosure policy Do not open a public GitHub issue for a security problem; the policy rules it out explicitly GitHub private vulnerability reporting is disabled on moby/moby, so the advisory button is not available here even though Docker publishes advisories prolifically Expect acknowledgement inside 72 hours, and a draft GitHub Security Advisory once the report is confirmed The disclosure timeline and embargo are negotiated with the security team rather than fixed at a published day count Docker offers swag and public credit for critical and high findings. There is no cash payment to negotiate and no reward terms to accept State the engine version, the storage driver and whether the daemon was running rootless. Several recent findings turn on exactly those variables Disclosure Coordinated privately with Docker's security team by email, acknowledged inside 72 hours, and published as a GitHub Security Advisory alongside a patched release. The embargo length is agreed with the team rather than published as a fixed count of days, so expect the clock to be set by the release schedule. Docker backports engine fixes across supported branches and downstream distributions pick them up quickly, so hold detail until the advisory and the patched builds are out. 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