What is the CVSS score of CVE-2026-47215?

CVE-2026-47215 has a CVSS 3.1 base score of 4.8 (Medium). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-47215?

Yes, a patch is available for CVE-2026-47215. Update the affected software to the latest version immediately.

SingularityCE CVE-2026-47215

MEDIUM

Path Traversal (CWE-22)

2026-06-04 https://github.com/sylabs/singularity

GHSA-wqcr-7rf3-f64m

Path Traversal

4.8

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

4.8 MEDIUM

AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

Required

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

Jun 04, 2026 - 18:06 vuln.today

Analysis Generated

Jun 04, 2026 - 18:06 vuln.today

DescriptionGitHub Advisory

Impact

The limit container paths directive in singularity.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

This issue is patched in SingularityCE 4.4.2 and SingularityPRO 4.3.9 / 4.1.14

Workarounds

If you do not use the limit container paths functionality, then this issue does not affect your installation.

If you do use the limit container paths functionality then you must update. Please also review the documented limitations when user namespaces are enabled [1].

AnalysisAI

Path restriction bypass in SingularityCE allows local authenticated low-privilege users to execute containers from directories whose names share a string prefix with administrator-configured allowed paths, defeating the limit container paths security control in setuid mode. The flaw exists only when this directive is actively configured in singularity.conf; installations not using the directive are entirely unaffected per the vendor advisory. No public exploit identified at time of analysis, and the CVE is not listed in CISA KEV.

Technical ContextAI

The root cause is CWE-22 (Improper Limitation of a Pathname), specifically an incorrect path authorization algorithm in the AuthorizedPath function within pkg/image/image.go. The original code used strings.HasPrefix(dirname, match) to determine whether a container image path falls within an administrator-specified allowed directory. Because this is a raw string comparison rather than a filesystem hierarchy check, any sibling directory whose name begins with the allowed path string (e.g., /data/safe-but-unsafe against allowed /data/safe) would incorrectly pass authorization. The upstream fix replaces strings.HasPrefix with filepath.Rel() combined with filepath.IsLocal(), which properly checks whether a path is rooted within the allowed directory tree and respects path boundaries. Affected Go packages are pkg:go/github.com/sylabs/singularity/v4 (versions < 4.4.2) and the legacy pkg:go/github.com/sylabs/singularity module. The flaw only manifests under setuid execution mode; rootless/user-namespace mode has separate documented limitations noted in the admin guide.

RemediationAI

Upgrade SingularityCE to version 4.4.2 or later (release at https://github.com/sylabs/singularity/releases/tag/v4.4.2) and upgrade SingularityPRO to version 4.3.9 or 4.1.14 or later, as confirmed in the vendor advisory at https://github.com/sylabs/singularity/security/advisories/GHSA-wqcr-7rf3-f64m. The upstream code fix is available at https://github.com/sylabs/singularity/commit/c08791793e843d4c9c1f2fc1d9d12abef747378f. For installations that cannot immediately upgrade, the vendor-recommended workaround is to remove the limit container paths directive from singularity.conf entirely - however, this trade-off is significant: it eliminates the path restriction mechanism completely, relying instead on OS-level filesystem permissions and ACLs to prevent users from placing container images in unauthorized directories. Administrators should evaluate whether native filesystem controls alone provide adequate containment before adopting this workaround. Additionally, review the documented limitations for user namespace mode at https://docs.sylabs.io/guides/latest/admin-guide/configfiles.html#limiting-container-execution.