Apptainer allowlist bypass permits containers from unintended paths in setuid mode

Apptainer is an open source container platform. Prior to version 1.5.1, Image.AuthorizedPath applies plain string-prefix matching to the limit container paths directive in apptainer.conf, so an allowed path such as /data/safe also authorizes a sibling path such as /data/safe-but-unsafe. A local user can consequently run a container from a directory outside the administrator's intended allowlist when Apptainer operates in setuid mode. Installations that do not use setuid mode or do not configure limit container paths are not affected, and unrestricted user namespaces already allow users to run containers of their choice. This issue is fixed in version 1.5.1.

• Apptainer: versions < 1.5.1 are affected when the installation uses setuid mode and limit container paths contains a path that is a string prefix of another path not intended to be allowed.
• Installations that do not use setuid mode or do not configure limit container paths are not affected according to the vendor advisory.
• When user namespaces are unrestricted, limit container paths does not prevent users from running containers of their choice, so the setting does not provide an effective allowlist in that model.
• The record and vendor materials confirm the fix in 1.5.1. No separate boundary for other parallel branches is established by the available evidence.

The affected component is Image.AuthorizedPath, which evaluates values from the limit container paths directive in apptainer.conf. Before the fix, it used plain string-prefix matching instead of checking path boundaries or the relative path from an allowed directory. As a result, an allowed path such as /data/safe also matched the sibling directory /data/safe-but-unsafe.

A local user on a setuid installation could select a container image in such a sibling directory and have Apptainer accept it as an allowed path. The normalized record maps the issue to CWE-22, while the vendor advisory does not provide a CWE mapping. The exact host-level data or privilege consequences depend on the container configuration and permitted mounts, so they are not established by the available evidence.

The issue is locally reachable and is not a network-triggered vulnerability. An attacker needs a local account with low privileges and must interact with Apptainer to run or select a container, so user interaction is required; the supplied assessment describes the attack complexity as low.

The supplied record does not identify a public exploit, and the known-exploitation status is unknown. The inspected vendor materials describe the flaw and its fix, but do not establish evidence of exploitation in the wild.

The direct technical outcome is bypass of the administrator-configured source-directory restriction, allowing a local user to run a container from a sibling path that policy intended to exclude. Possible consequences include execution of an unapproved workload and access to or modification of data visible to that container, depending on runtime policy and permitted mounts.

The flaw requires local access and user interaction, and it does not establish a remote attack path. The available evidence does not confirm container escape, host privilege escalation, or a change in security scope to another component. Actual impact is therefore bounded by the setuid deployment, path configuration, and permissions granted to the container.

The flaw weakens the directory boundary administrators use to restrict where containers may be run. An organization may therefore have to account for unapproved workloads or images being executed from directories that policy intended to exclude.

Depending on the image, bind mounts, and data exposed to the container, running a workload outside the intended allowlist could permit access to, modification of, or resource consumption within the container's effective scope. The available evidence does not establish a specific breach, host compromise, or privilege escalation.

1. Upgrade Apptainer to the confirmed patched release, 1.5.1.
2. Before upgrading, review every limit container paths entry for other directories with the same string prefix. Do not rely on such entries as an effective path boundary until the installation is updated.
3. Confirm which installations genuinely require setuid mode and limit container paths. If operationally acceptable, removing either condition places the installation outside the stated affected conditions, but the change should be assessed against the deployment's security model and container requirements.
4. After updating, recheck the configuration and verify that a sibling path whose name begins with an allowed path is no longer accepted as part of the allowlist.

1. Inventory Apptainer installations and compare their running versions with the vendor's patched release.
2. Identify which installations use setuid mode, because this is required for the flawed allowlist enforcement to apply.
3. Inspect apptainer.conf for the limit container paths directive and record every configured path.
4. Check for other directories that share each allowed path's string prefix, such as /data/safe and /data/safe-but-unsafe. This is a configuration review, not a confirmed IOC.
5. As a precaution, review available logs or audit records for local users running containers from sibling directories that were intended to be excluded. The absence of such records does not prove that an installation is safe, because the available evidence defines no specific log event or indicator.