GHSA-pwqf-9h7j-7mv8 CVE-2020-6174 PYSEC-2020-147
Incorrect threshold signature computation in TUF
- Severity
- 0.0 / 10
- Critical · CVSS 4.0
- Exploit chance (EPSS)
- 0.99%
- Chance of exploitation in the next 30 days. Higher than 62.46% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-347 Improper Verification of Cryptographic Signature
- Fix
0.12.2- Upgrade tuf to this version or later
Description
Impact
Metadadata signature verification, as used in tuf.client.updater, counted each of multiple signatures with identical authorized keyids separately towards the threshold. Therefore, an attacker with access to a valid signing key could create multiple valid signatures in order to meet the minimum threshold of keys before the metadata was considered valid.
The tuf maintainers would like to thank Erik MacLean of Analog Devices, Inc. for reporting this issue.
Patches
A fix is available in version 0.12.2 or newer.
Workarounds
No workarounds are known for this issue.
References
- CVE-2020-6174
- Pull request resolving the issue PR 974
Affected versions
PyPI
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.
tuf PyPI → 0.12.2
- pip
pip install --upgrade "tuf>=0.12.2"- poetry
poetry add "tuf>=0.12.2"- uv
uv add "tuf>=0.12.2"
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-347: Improper Verification of Cryptographic Signature
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
References
Advisories
Packages
Other links
- github.com/theupdateframework/tuf/security/advisories/GHSA-pwqf-9h7j-7mv8
- github.com/theupdateframework/tuf/pull/974
- github.com/theupdateframework/python-tuf/commit/2977188139d065ff3356c3cb4aec60c…
- github.com/pypa/advisory-database/tree/main/vulns/tuf/PYSEC-2020-147.yaml
- github.com/theupdateframework/tuf/releases/tag/v0.12.2
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| EEF-CVE-2026-65632 ECDSA signature length is not validated in jose, allowing signature malleability | Not rated yet | Same weakness, CWE-347 |
| GHSA-pxh4-856f-4h89 PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery | High | Same weakness, CWE-347 |
| GHSA-j7h2-66j4-ghjf A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in the request | Low | Same weakness, CWE-347 |
| GHSA-w2cx-738m-mc7w PyJWT accepts public JWK containers as HMAC secrets | High | Same weakness, CWE-347 |
| GHSA-r6x4-923q-g947 PyJWT BOM Bypass | High | Same weakness, CWE-347 |
| GHSA-p4g4-x82p-q773 PyJWT: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard | High | Same weakness, CWE-347 |
| GHSA-ffc3-869f-jxw9 PyJWT: Asymmetric-PEM detection bypass: whitespace/line-ending-mutated public keys skip the HS/asymmetric confusion guard | Critical | Same weakness, CWE-347 |
| GHSA-9j54-fg26-wv3r PyJWT: PyJWK accepts empty HMAC keys, bypassing PyJWT's empty-key validation | Critical | Same weakness, CWE-347 |
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