Summary
Execution Control List (ECL) Is Insecure in Singularity
Workarounds
This issue affects any installation of Singularity configured to use the Execution Control List (ECL) functionality. There is no workaround if ECL is required.
For more information
General questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:
Any sensitive security concerns should be directed to: [email protected]
See our Security Policy here: https://sylabs.io/security-policy
Impact
The Singularity Execution Control List (ECL) allows system administrators to set up a policy that defines rules about what signature(s) must be (or must not be) present on a SIF container image for it to be permitted to run.
In Singularity 3.x versions below 3.6.0, the following issues allow the ECL to be bypassed by a malicious user:
- Image integrity is not validated when an ECL policy is enforced.
- The fingerprint required by the ECL is compared against the signature object descriptor(s) in the SIF file, rather than to a cryptographically validated signature. Thus, it is trivial to craft an arbitrary payload which will be permitted to run, even if the attacker does not have access to the private key associated with the fingerprint(s) configured in the ECL.
CVE-2020-13845 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.6.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
These issues are addressed in Singularity 3.6.0.
All users are advised to upgrade to 3.6.0. Note that Singularity 3.6.0 uses a new signature format that is necessarily incompatible with Singularity < 3.6.0 - e.g. Singularity 3.5.3 cannot verify containers signed by 3.6.0.
Version 3.6.0 includes a legacyinsecure option that can be set to legacyinsecure = true in ecl.toml to allow the ECL to perform verification of the older, and insecure, legacy signatures for compatibility with existing containers. This does not guarantee that containers have not been modified since signing, due to other issues in the legacy signature format. The option should be used only to temporarily ease the transition to containers signed with the new 3.6.0 signature format.
Frequently Asked Questions
- What is CVE-2020-13845? CVE-2020-13845 is a high-severity security vulnerability in github.com/sylabs/singularity (go), affecting versions >= 3.0.0, < 3.6.0. It is fixed in 3.6.0.
- How severe is CVE-2020-13845? CVE-2020-13845 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/sylabs/singularity are affected by CVE-2020-13845? github.com/sylabs/singularity (go) versions >= 3.0.0, < 3.6.0 is affected.
- Is there a fix for CVE-2020-13845? Yes. CVE-2020-13845 is fixed in 3.6.0. Upgrade to this version or later.
- Is CVE-2020-13845 exploitable, and should I be worried? Whether CVE-2020-13845 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2020-13845 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2020-13845? Upgrade
github.com/sylabs/singularityto 3.6.0 or later.