https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-10-04T00:52:29.292301+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/fkie_cve-2026-48785 fkie_cve-2026-48785 2026-10-04T00:52:29.358879+00:00

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.

 https://vulnerability.circl.lu/vuln/ghsa-cr2j-534f-mf3g GHSA-cr2j-534f-mf3g — Apptainer has incorrect path matching for 'limit container paths' directive 2026-10-04T00:52:29.359002+00:00

Affected: Go: github.com/apptainer/apptainer

### 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

 https://vulnerability.circl.lu/vuln/opensuse-su-2026:10993-1 openSUSE-SU-2026:10993-1 — apptainer-1.5.1-1.1 on GA media 2026-10-04T00:52:29.359088+00:00

apptainer-1.5.1-1.1 on GA media

 https://vulnerability.circl.lu/vuln/suse-su-2026:2609-1 SUSE-SU-2026:2609-1 — Security update for apptainer 2026-10-04T00:52:29.359122+00:00

Security update for apptainer

 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-48785 UBUNTU-CVE-2026-48785 2026-10-04T00:52:29.359158+00:00

Affected: Ubuntu:25.10: apptainer, Ubuntu:26.04:LTS: apptainer

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.