GHSA-5vmp-m5v2-hx47 CVE-2025-2885
tough root metadata version is not checked for sequential versioning
- Severity
- 0.0 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- 0.33%
- Chance of exploitation in the next 30 days. Higher than 26.49% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-1288 Improper Validation of Consistency within Input
- Fix
0.20.0- Upgrade tough to this version or later
Description
Summary
When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.
Impact
The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.
Impacted versions: < v0.20.0
Patches
A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.
Workarounds
There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.
References
If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting
Acknowledgement
These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.
Affected versions
crates.io
| Package | Vulnerable | Fixed in |
|---|---|---|
| tough | < 0.20.0 |
0.20.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
tough crates.io → 0.20.0
- cargo
cargo update -p tough --precise 0.20.0
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- High
- Attack requirements
- None
- Privileges required
- High
- User interaction
- Passive
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 4.2
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:H/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- High
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- None
Weakness
CWE-1288: Improper Validation of Consistency within Input
The product receives a complex input with multiple elements or fields that must be consistent with each other, but it does not validate or incorrectly validates that the input is actually consistent.
How to prevent it
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-4v58-8p28-2rq3 awslabs/tough is Missing Delegated Metadata Validation | Medium | Also affects tough |
| GHSA-8m7c-8m39-rv4x awslabs/tough Delegated Roles have a Signature Threshold Bypass | Medium | Also affects tough |
| GHSA-j8x2-777p-23fc tough cyclic delegation graphs are not detected | Low | Also affects tough |
| GHSA-76g3-38jv-wxh4 tough timestamp metadata is cached when it fails snapshot rollback check | Medium | Also affects tough |
| GHSA-q6r9-r9pw-4cf7 tough failure to detect delegated target rollback | Medium | Also affects tough |
| GHSA-v4wr-j3w6-mxqc tough terminating targets role delegations are not respected | Medium | Also affects tough |
| GHSA-r56q-vv3c-6g9c Improper sanitization of delegated role names | High | Also affects tough |
| GHSA-x3r5-q6mj-m485 Improper sanitization of target names | High | Also affects tough |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor