Trudg

**Name of the Vulnerable Software and Affected Versions** scs-library-client versions prior to 1.3.4 and 1.4.2 **Description** The HTTP Authorization header sent by the scs-library-client to the library service may be incorrectly leaked to an S3 backing storage provider when pulling a container image with authentication. This occurs in a specific flow where the library service redirects the client to a backing S3 storage server for a multi-part concurrent download. An attacker with access to the S3 service may be able to extract user credentials, allowing them to impersonate the user. The vulnerable flow is only used when communicating with a Singularity Enterprise 1.x installation or a third-party server implementing this flow. **Recommendations** Update to scs-library-client version 1.3.4 or 1.4.2 to fix the security issue. For users interacting with a Singularity Enterprise 1.x installation using a 3rd party S3 storage service, revoke and recreate authentication tokens within Singularity Enterprise. As a temporary measure, consider avoiding the use of the multi-part concurrent download flow with redirect to S3 until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Sylabs Singularity versions 3.5.0 through 3.5.3 **Description** The issue arises when the `--all / -a` option is used with `singularity verify`, as it returns a success message even if some objects in a SIF container are not signed or cannot be verified. These unverified objects are reported in `WARNING` log messages, but the command still returns an exit code of `0` and a `Container Verified` message. This can lead to workflows running SIF containers with unsigned or modified objects, potentially introducing malicious behavior. **Recommendations** For Sylabs Singularity versions 3.5.0 through 3.5.3, upgrade to version 3.6.0 to resolve the issue. Note that version 3.6.0 uses a new signature format incompatible with earlier versions. If upgrading to 3.6.0 is not possible, do not rely on the return code of `singularity verify --all / -a` as an indicator of trust in a container. Additionally, be aware that other issues in the sign/verify implementation in Singularity versions prior to 3.6.0 may allow for introducing malicious behavior to a signed container.