Skip to content

Apptainer

Bug bounty on Sorona apptainer.org

Accepting reports open-source
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.
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 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, 5 excluded.

Web 1

  • https://apptainer.org

Products and areas 13

  • FUSE-based image mounting as Apptainer invokes it, covering squashfuse, fuse2fs and gocryptfs
  • GPU and device passthrough setup for NVIDIA and ROCm, including the host libraries bound into the container
  • Image signature verification, key handling and the encrypted-image support
  • Instance mode, its lifecycle and the sockets and state files behind it
  • Network configuration through CNI plugins where the privileged path sets it up
  • OCI and Docker image conversion, layer extraction and the caching of pulled layers
  • Overlay and bind mount setup, including the underlay path and every mount performed before privilege is dropped
  • SIF image format parsing in full: the header, the descriptor table and every data object inside a container file
  • The build path, including builds from definition files, the %post script execution model and builds from Docker or OCI sources
  • The published security policy asks for reports to the project security address and declares one boundary: attacker-controlled content inside a container image is not treated as a risk to the user who runs it, while privilege escalation arising from image content is a valid concern
  • The setuid starter binary and the entire privileged startup path, including exactly where privilege is dropped
  • The site configuration file and the enforcement of an administrator's bind path restrictions, allowed capabilities and limits
  • The user namespace startup path and the id mapping it establishes
Out of scope (5)
  • Batch scheduler and cluster manager integration outside the Apptainer codebase
  • Defects in a container's payload rather than in the runtime
  • Kernel defects reachable from inside a container
  • Malicious content inside a container image affecting the user who chose to run it, which the policy states is not treated as a vulnerability
  • Site configuration that deliberately grants capabilities or wide bind paths

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 to the address on the policy page , the address the published security policy names
  • Read the policy's threat model boundary first.
  • Say whether you reproduced in the setuid path or in the user namespace path.
  • Name the version, since the project has been steadily moving privileged work out of the setuid starter and the answer changes by release
  • Describe the site configuration you used, including bind path restrictions and allowed capabilities.
  • Hold detail until the advisory and the fixed release are both out.

Not accepted

  • Malicious content inside a container image affecting the user who chose to run it
  • Kernel defects reachable from inside a container
  • Batch scheduler and cluster manager integration outside the Apptainer codebase
  • Site configuration that deliberately grants capabilities or wide bind paths
  • Defects in a container's payload rather than in the runtime

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

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 Local privilege escalation 45 % Image parsing 25 % Path traversal & symlink 20 % Info disclosure 10 % Latest advisories Loading the feed Overview Apptainer, formerly Singularity, is the container runtime that national labs and university HPC clusters actually run, chosen because it executes a user's container under that user's own identity on a shared batch system. Its historically setuid startup path is what makes it interesting: a privilege defect there is root on a machine shared by hundreds of researchers, most of them holding data nobody wants moved. Two advisories landed in the last twelve months. The Linux Foundation stewards the project, which publishes a security policy and a dedicated address and offers no reward of any kind, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The published security policy asks for reports to the project security address and declares one boundary: attacker-controlled content inside a container image is not treated as a risk to the user who runs it, while privilege escalation arising from image content is a valid concern The setuid starter binary and the entire privileged startup path, including exactly where privilege is dropped The user namespace startup path and the id mapping it establishes SIF image format parsing in full: the header, the descriptor table and every data object inside a container file Image signature verification, key handling and the encrypted-image support The build path, including builds from definition files, the %post script execution model and builds from Docker or OCI sources OCI and Docker image conversion, layer extraction and the caching of pulled layers Overlay and bind mount setup, including the underlay path and every mount performed before privilege is dropped FUSE-based image mounting as Apptainer invokes it, covering squashfuse, fuse2fs and gocryptfs Instance mode, its lifecycle and the sockets and state files behind it Network configuration through CNI plugins where the privileged path sets it up The site configuration file and the enforcement of an administrator's bind path restrictions, allowed capabilities and limits GPU and device passthrough setup for NVIDIA and ROCm, including the host libraries bound into the container Out of scope Malicious content inside a container image affecting the user who chose to run it, which the policy states is not treated as a vulnerability Kernel defects reachable from inside a container Batch scheduler and cluster manager integration outside the Apptainer codebase Site configuration that deliberately grants capabilities or wide bind paths Defects in a container's payload rather than in the runtime Most-valued findings Privilege escalation out of the setuid path, above everything else. On a shared HPC login node that is root against every user on the machine, and the policy accepts privilege escalation from image content as in scope Any privileged operation performed against a path a non-root user controls, including symlink handling and races during mount setup SIF parsing defects, since a container file is attacker-supplied input on systems where users routinely pull images from public registries Signature verification bypass, where an image passes as signed while unsigned or where the signature covers different content than what runs Layer extraction and cache handling from OCI or Docker sources, where an archive entry escapes its intended directory Configuration enforcement bypass, where a site's bind path or capability restrictions fail to hold User namespace and id mapping errors in the unprivileged path, which is the mode sites are migrating toward 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 the published security policy names Read the policy's threat model boundary first. Attacker-controlled content inside a container image is not treated as a risk to the user who chose to run it Privilege escalation arising from container image content is explicitly a valid concern, so frame image-driven findings around the privilege gain rather than around the hostile content Say whether you reproduced in the setuid path or in the user namespace path. They are separate startup paths with completely different privilege profiles Name the version, since the project has been steadily moving privileged work out of the setuid starter and the answer changes by release Describe the site configuration you used, including bind path restrictions and allowed capabilities. Administrator limits are part of what the runtime is meant to enforce HPC context matters for severity. Root on a shared login node with hundreds of users is a different report from root on a single-user workstation, so say which you demonstrated Disclosure Coordinated privately through the project security address under the published security policy, with CVEs assigned and the details disclosed publicly once a fix is available. HPC sites patch on their own maintenance cycles, so expect the maintainers to want a release in hand before publication. Hold detail until the advisory and the fixed release are both 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