GHSA-j3rw-fx6g-q46j is a medium-severity (CVSS 4.5) CWE-61 vulnerability in github.com/apptainer/apptainer. A fix is available for github.com/apptainer/apptainer — see the affected versions and patch details below.
Apptainer ineffectively applies selinux and apparmor --security options
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-j3rw-fx6g-q46j.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-j3rw-fx6g-q46j plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/apptainer/apptainerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
In Apptainer versions less than 1.4.5, a container can disable two of the forms of the little used --security option, in particular the forms --security=apparmor:<profile> and --security=selinux:<label> which otherwise put restrictions on operations that containers can do. The --security option has always been mentioned in Apptainer documentation as being a feature for the root user, although these forms do also work for unprivileged users on systems where the corresponding feature is enabled. Apparmor is enabled by default on Debian-based distributions and SElinux is enabled by default on RHEL-based distributions, but on SUSE it depends on the distribution version.
In addition, a bug in the detection of selinux support in Apptainer's suid mode means that --security selinux:<label> flags may not be applied, even in the absence of an attack. In that case a warning message is emitted indicating that selinux is unavailable, but the warning may be may be overlooked, mis-interpreted, or not seen when apptainer is run from a script or other tool. Failure to apply requested restrictions should result in a fatal error rather than just a warning message.
Patches
Ineffective write of selinux process labels is addressed via an update to the containers/selinux dependency in https://github.com/apptainer/apptainer/pull/3226. That update brings in the upstream fix for https://github.com/advisories/GHSA-cgrx-mc8f-2prm which was for a different but related vulnerability.
Ineffective write of apparmor process profiles is addressed in commit 4313b42.
Failure to detect apparmor / selinux support, when --security flags are provided, is made an error rather than a warning in commit 82f1790.
Workarounds
There are no known workarounds, other than to define system-wide apparmor / selinux policy for Apptainer itself. This would apply to all containers, not just those run with the --security flags, and could impact the operation of Apptainer itself.
References
Thanks to Sylabs for finding this issue, fixing it in https://github.com/sylabs/singularity/security/advisories/GHSA-wwrx-w7c9-rf87 which was easy to import into Apptainer, and disclosing it early to the Apptainer project for a coordinated release.
The related upstream runc disclosure which inspired the investigation is https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/apptainer/apptainer | all versions | 1.4.5go get github.com/apptainer/apptainer@v1.4.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/apptainer/apptainer, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/apptainer/apptainer to 1.4.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j3rw-fx6g-q46j is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-j3rw-fx6g-q46j can be triaged on real exposure rather than presence alone.
Tailored to GHSA-j3rw-fx6g-q46j. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-j3rw-fx6g-q46j in your dependencies?
O3 Security finds GHSA-j3rw-fx6g-q46j across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.