Focus on theupdateframework vulnerabilities and metrics.
Last updated: 08 Mar 2026, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with theupdateframework. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total theupdateframework CVEs: 4
Earliest CVE date: 05 May 2022, 23:15 UTC
Latest CVE date: 27 Jan 2026, 01:16 UTC
Latest CVE reference: CVE-2026-24686
30-day Count (Rolling): 0
365-day Count (Rolling): 3
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): -100.0%
Year Variation (Calendar): 0%
Month Growth Rate (30-day Rolling): -100.0%
Year Growth Rate (365-day Rolling): 0.0%
Average CVSS: 1.07
Max CVSS: 4.3
Critical CVEs (≥9): 0
| Range | Count |
|---|---|
| 0.0-3.9 | 3 |
| 4.0-6.9 | 1 |
| 7.0-8.9 | 0 |
| 9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for theupdateframework, sorted by severity first and recency.
go-tuf is a Go implementation of The Update Framework (TUF). go-tuf's TAP 4 Multirepo Client uses the map file repository name string (`repoName`) as a filesystem path component when selecting the local metadata cache directory. Starting in version 2.0.0 and prior to version 2.4.1, if an application accepts a map file from an untrusted source, an attacker can supply a `repoName` containing traversal (e.g., `../escaped-repo`) and cause go-tuf to create directories and write the root metadata file outside the intended `LocalMetadataDir` cache base, within the running process's filesystem permissions. Version 2.4.1 contains a patch.
go-tuf is a Go implementation of The Update Framework (TUF). Starting in version 2.0.0 and prior to version 2.3.1, a compromised or misconfigured TUF repository can have the configured value of signature thresholds set to 0, which effectively disables signature verification. This can lead to unauthorized modification to TUF metadata files is possible at rest, or during transit as no integrity checks are made. Version 2.3.1 fixes the issue. As a workaround, always make sure that the TUF metadata roles are configured with a threshold of at least 1.
go-tuf is a Go implementation of The Update Framework (TUF). Starting in version 2.0.0 and prior to version 2.3.1, if the TUF repository (or any of its mirrors) returns invalid TUF metadata JSON (valid JSON but not well formed TUF metadata), the client will panic during parsing, causing a denial of service. The panic happens before any signature is validated. This means that a compromised repository/mirror/cache can DoS clients without having access to any signing key. Version 2.3.1 fixes the issue. No known workarounds are available.
go-tuf is a Go implementation of The Update Framework (TUF). go-tuf does not correctly implement the client workflow for updating the metadata files for roles other than the root role. Specifically, checks for rollback attacks are not implemented correctly meaning an attacker can cause clients to install software that is older than the software which the client previously knew to be available, and may include software with known vulnerabilities. In more detail, the client code of go-tuf has several issues in regards to preventing rollback attacks: 1. It does not take into account the content of any previously trusted metadata, if available, before proceeding with updating roles other than the root role (i.e., steps 5.4.3.1 and 5.5.5 of the detailed client workflow). This means that any form of version verification done on the newly-downloaded metadata is made using the default value of zero, which always passes. 2. For both timestamp and snapshot roles, go-tuf saves these metadata files as trusted before verifying if the version of the metafiles they refer to is correct (i.e., steps 5.5.4 and 5.6.4 of the detailed client workflow). A fix is available in version 0.3.0 or newer. No workarounds are known for this issue apart from upgrading.