Skip to main content

Apptainer CVE-2026-48785

| EUVDEUVD-2026-78889 MEDIUM
Path Traversal (CWE-22)
2026-06-26 https://github.com/apptainer/apptainer GHSA-cr2j-534f-mf3g
4.8
CVSS 3.1 · Vendor: https://github.com/apptainer/apptainer
Share

Severity by source

Vendor (https://github.com/apptainer/apptainer) PRIMARY
4.8 MEDIUM
AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L
vuln.today AI
5.3 MEDIUM

Local low-privilege access suffices to exploit the prefix-match bypass; the attacker initiates the container run themselves, requiring no separate user interaction.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

Primary rating from Vendor (https://github.com/apptainer/apptainer).

CVSS VectorVendor: https://github.com/apptainer/apptainer

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
Required
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 26, 2026 - 19:52 vuln.today
Analysis Generated
Jun 26, 2026 - 19:52 vuln.today

DescriptionCVE.org

Impact

The limit container paths directive in apptainer.conf is intended to allow a system administrator limit the paths from which containers can be run, under setuid mode. Due to incorrect matching of a path string, sibling directories with similar names may incorrectly be allowed.

For example, the configuration:

limit container paths = /data/safe

Will also allow containers in /data/safe-but-unsafe to be run.

Patches

The issue is patched in apptainer version 1.5.1.

Workarounds

If developers do not use setuid mode or do not use the limit container paths functionality, then this issue does not affect their installation. Note that, as documented [1], if user namespaces are allowed for unrestricted use then this functionality does not stop users from running any container of their choice.

If developers do use the limit container paths functionality they are advised to update.

Credit

This vulnerability was discovered and disclosed to the Apptainer project by Dave Trudgian of Sylabs.

Resources

[1] https://apptainer.org/docs/admin/latest/configfiles.html#limiting-container-execution

AnalysisAI

Apptainer's limit container paths security directive in setuid mode fails to enforce path boundaries correctly because it uses string prefix matching rather than full path-component comparison, allowing local users to run containers from sibling directories whose names begin with an allowed path string. A system configured to allow only /data/safe will inadvertently also permit /data/safe-but-unsafe or any other path sharing that prefix. This affects only installations running Apptainer in setuid mode with the limit container paths directive explicitly configured; no public exploit has been identified at time of analysis, and the vendor-confirmed fix is available in version 1.5.1.

Technical ContextAI

Apptainer (the community successor to Singularity) is a Go-based container runtime widely used in HPC and scientific computing environments. Its setuid execution mode allows unprivileged users to run containers with elevated capabilities. The limit container paths directive in apptainer.conf is a security control allowing sysadmins to restrict which filesystem paths containers may be executed from. The root cause (CWE-22, Path Traversal / improper path handling) is that the path matching logic compares the configured path as a raw string prefix against the requested path, rather than normalizing and comparing full directory-component boundaries. This means any path whose string representation begins with the allowed path string - including sibling directories with extended names - satisfies the check. The affected package is go/github.com/apptainer/apptainer, versions prior to 1.5.1.

RemediationAI

The primary remediation is to upgrade Apptainer to version 1.5.1, which corrects the path comparison logic to enforce directory-component boundaries. The vendor advisory detailing the fix is at https://github.com/apptainer/apptainer/security/advisories/GHSA-cr2j-534f-mf3g. For environments that cannot immediately upgrade, two workarounds are available with trade-offs: first, disable setuid mode entirely - this eliminates the vulnerable code path but may prevent privileged container operations that require it, impacting workloads that depend on setuid capabilities. Second, remove the limit container paths directive if the path restriction is not a hard security requirement; note that without this control, local users may run containers from any path they have filesystem access to, but the bypass bug is no longer relevant. Administrators should also note that if unrestricted user namespaces are permitted on the host, the limit container paths directive provides no effective security boundary regardless of this vulnerability, per the vendor's own documentation.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise High Performance Computing 15 SP7 SUSE Linux Enterprise Module for HPC 15 SP7 Fixed
SUSE Linux Enterprise Server 15 SP6-LTSS Fixed
openSUSE Leap 16.0 Fixed
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Affected

Share

CVE-2026-48785 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy