Client configured with permissive trust policies susceptible to rollback attack in Notary Project
Description
The Notary Project is a set of specifications and tools intended to provide a cross-industry standard for securing software supply chains by using authentic container images and other OCI artifacts. An external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as permissive instead of strict) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain. In Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a strict or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as permissive, audit and skip to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms. Additionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
github.com/notaryproject/notationGo | <= 1.0.0 | — |
Affected products
1- Range: <= 1.0.1
Patches
1cdabdd1042deUpdate threat model to include rollback attack (#285)
1 file changed · +1 −0
threatmodels/notation-threatmodel.md+1 −0 modified@@ -87,3 +87,4 @@ The certificates trusted by the verifier are stored in Notation trust store in t | Malicious signature faking to be signed by a signing authority | Tampering | Mitigated | High | Notation | Unlike notary.x509 signing scheme, trusted timestamps are not checked against RFC#3161 TSA servers for notary.x509.signingAuthority signing scheme. An attacker can use this and bypass trusted timestamp checks by crafting a signature that uses notary.x509 keys but with signingAuthority as the signing scheme. | To prevent this threat, notary.x509.signingAuthority signing scheme requires trusted roots to be present in a trust store type called signingAuthority as opposed to CA trust store type for notary.x509 signing scheme | | Inaccessible OCSP Responder | Denial of Service | Not Mitigated | High | OCSP Responder | OCSP Responder is not able to service incoming requests or perform up to spec, thus users are unable to validate certificate revocation status | It cannot be mitigated, since revocation status should be retrieved from OCSP responder, which requires network access. Notation verification should fail if revocation check is configured as `enforced` and OCSP responder is inaccessible. Users can configure trust policy to log or skip revocation check if OCSP responder is not reliable. | | Compromised Notation dependencies | Tampering | Mitigated | High | Notation | The dependencies that built into Notation binary was compromised, this may lead to arbitrary code being executed | Notation keeps dependencies up-to-date and adds new dependency after careful consideration and only if it's absolutely required. Always use static build instead of dynamic linking | +| Rollback Attack | Tampering | Mitigated | High | Notation | Attacker can exploit a compromised repository to return outdated vulnerable artifacts | Signer can employ short signature expiration periods (and periodically re-sign artifacts) or revoke outdated vulnerable artifacts | \ No newline at end of file
Vulnerability mechanics
Generated by null/stub on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4- github.com/advisories/GHSA-57wx-m636-g3g8ghsaADVISORY
- nvd.nist.gov/vuln/detail/CVE-2024-23332ghsaADVISORY
- github.com/notaryproject/specifications/commit/cdabdd1042de2999c685fa5d422a785ded9c983aghsax_refsource_MISCWEB
- github.com/notaryproject/specifications/security/advisories/GHSA-57wx-m636-g3g8ghsax_refsource_CONFIRMWEB
News mentions
0No linked articles in our index yet.