- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- 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
14 assets you may test, 7 excluded.
Web 1
- https://github.com/moby/buildkit
Products and areas 13
- Cache mounts, cache import and export, and the registry, local, inline and GitHub Actions cache backends
- Dockerfile parsing and every instruction, including heredocs, ARG and ENV handling, and the interaction between build arguments and instruction expansion
- The build sandbox as BuildKit configures it: seccomp, AppArmor, namespaces, capabilities and the runc or containerd worker
- The buildx client integration and the remote and container driver paths, where a build is dispatched to a shared builder
- The content store, the storage root and the snapshotter layer, including garbage collection
- The frontend interface in full, covering the built-in Dockerfile frontend, gateway frontends and third-party frontends loaded from an image reference
- The git source: URL parsing, ref and subdirectory handling, submodules, bundles and the credential forwarding that goes with them
- The gRPC control API, the session channel and everything forwarded over it: secrets, SSH agent sockets and registry credentials
- The HTTP source and the image source, plus the registry client, manifest handling and layer extraction underneath them
- The LLB solver and the full operation set it executes: file operations, exec operations, source operations, merge and diff operations
- The local source and its destination-path validation, including how files from the client are placed inside the build
- The policy asks for private email reports on security issues in BuildKit and points at a written security boundary in PROJECT.md rather than a narrow component list. Everything below sits inside that boundary
- Windows container support, including WCOW cache mounts and NTFS junction handling
Out of scope (7)
- A Dockerfile that does something dangerous the author asked for, such as running an untrusted script during a build the author controls
- containerd, runc and the kernel primitives BuildKit configures
- Docker Engine itself, which ships as a separate project with its own policy and its own entry here
- Findings outside the published security boundary in PROJECT.md
- Operator decisions such as running a builder privileged, sharing one builder between untrusted tenants without isolation, or mounting the host Docker socket into a build
- Public disclosure ahead of coordination
- Third-party frontends and downstream builders, where the defect is theirs rather than in the interface BuildKit exposes
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 privately by email to the address on the policy page , the address named in the policy
-
Read PROJECT.md#security-boundary before writing the report.
-
Do not open a public GitHub issue for a security problem
-
State whether the finding needs a custom frontend, a hostile Dockerfile, a hostile build context or only a hostile remote source.
Not accepted
-
Findings outside the published security boundary in PROJECT.md
-
A Dockerfile that does something dangerous the author asked for
-
Operator decisions such as running a builder privileged
-
Third-party frontends and downstream builders, where the defect is theirs rather than in the interface BuildKit exposes
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 35 minutes 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 9 Last 12 months Path traversal / file escape 40 % Command injection 25 % Sandbox confinement bypass 20 % Destructive file operations 15 % Latest advisories Loading the feed Overview BuildKit is the build engine behind docker build , the default since Docker 23, and it is also embedded in docker buildx , nerdctl, Cloud Native Buildpacks and most managed CI build services. Effectively every container image built today passes through this code, usually while running with elevated privilege on a shared runner. CVE-2026-33747 is the reference point: a malicious build frontend could write files outside the storage root. Nine advisories landed in the last year, five of them on a single day. The policy states there is no paid bounty, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for private email reports on security issues in BuildKit and points at a written security boundary in PROJECT.md rather than a narrow component list. Everything below sits inside that boundary The LLB solver and the full operation set it executes: file operations, exec operations, source operations, merge and diff operations The frontend interface in full, covering the built-in Dockerfile frontend, gateway frontends and third-party frontends loaded from an image reference Dockerfile parsing and every instruction, including heredocs, ARG and ENV handling, and the interaction between build arguments and instruction expansion The git source: URL parsing, ref and subdirectory handling, submodules, bundles and the credential forwarding that goes with them The local source and its destination-path validation, including how files from the client are placed inside the build The HTTP source and the image source, plus the registry client, manifest handling and layer extraction underneath them Cache mounts, cache import and export, and the registry, local, inline and GitHub Actions cache backends The content store, the storage root and the snapshotter layer, including garbage collection The gRPC control API, the session channel and everything forwarded over it: secrets, SSH agent sockets and registry credentials The build sandbox as BuildKit configures it: seccomp, AppArmor, namespaces, capabilities and the runc or containerd worker Windows container support, including WCOW cache mounts and NTFS junction handling The buildx client integration and the remote and container driver paths, where a build is dispatched to a shared builder Out of scope Docker Engine itself, which ships as a separate project with its own policy and its own entry here containerd, runc and the kernel primitives BuildKit configures A Dockerfile that does something dangerous the author asked for, such as running an untrusted script during a build the author controls Operator decisions such as running a builder privileged, sharing one builder between untrusted tenants without isolation, or mounting the host Docker socket into a build Third-party frontends and downstream builders, where the defect is theirs rather than in the interface BuildKit exposes Findings outside the published security boundary in PROJECT.md Public disclosure ahead of coordination Most-valued findings Anything a hostile frontend can do that the sandbox is supposed to prevent. CVE-2026-33747 escaped the storage root from a malicious frontend, and GHSA-7236-3392-c5c6 got a custom frontend past Seccomp and AppArmor entirely File writes that land outside the intended destination. CVE-2026-15789 bypassed destination-directory validation on the local source, and CVE-2026-33748 reached restricted files through a git URL subdirectory Command injection out of anything BuildKit fetches. CVE-2026-15793 got there through a git bundle checkout, so every place a remote value reaches a command line is worth attacking Destructive LLB file operations, of the CVE-2026-15791 shape where an operation wiped /tmp Cache-mount escapes, including the Windows NTFS junction path CVE-2026-15788 used. Cache mounts are shared state on shared builders, so both directions matter Cross-build contamination on a shared builder, where one tenant's build reads or poisons another's cache, secrets or content store Secret and SSH forwarding leaking into a committed layer, into build history or into a cache export Registry credential exposure during pull, push or cache export, particularly where the credential is forwarded over the session channel Layer and archive extraction handling in the image source: symlinks, hardlinks, absolute paths and traversal entries 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 address named in the policy The policy is at .github/SECURITY.md inside the repo. There is no repo-root SECURITY.md and the moby org has no .github repo, so GitHub's Security tab shows nothing for this project GitHub private vulnerability reporting is disabled on moby/buildkit, so email is the only private channel Read PROJECT.md#security-boundary before writing the report. BuildKit publishes a written security boundary, and framing a finding against it settles the in-scope question up front Do not open a public GitHub issue for a security problem There is no cash payment here. The policy states the project does not currently offer a paid bounty and leaves the door open to changing that State whether the finding needs a custom frontend, a hostile Dockerfile, a hostile build context or only a hostile remote source. The boundary treats those very differently Disclosure Coordinated privately with Docker's security team by email and published as a GitHub Security Advisory alongside a patched release. The 2026 record shows the pipeline moving in batches, with five advisories published together on 16 July, so plan for an embargo that runs to the next batched security release. Fixes reach users through Docker, buildx and the many downstream builders that embed BuildKit, so the coordination window is set by that fan-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