Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/theupdateframework/go-tuf/v2 < 2.4.1
Fixed in
2.4.1· Vendor fix available
Issue
Security Vulnerability: Path Traversal in TAP 4 Multirepo Client Summary 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. 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. Affected Component | Field | Value | |-------|-------| | File | metadata/multirepo/multirepo.go | | Function | (MultiRepoClient) initTUFClients() error | | Callsite | metadataDir := filepath.Join(client.Config.LocalMetadataDir, repoName) (around line 129 at the pinned commit) | Impact When the TAP 4 map file content is attacker-controlled, this enables arbitrary file write relative to the process permissions (via metadata persistence…
Recommended action: Upgrade to 2.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/theupdateframework/go-tuf/v2 < 2.3.1
Fixed in
2.3.1· Vendor fix available
Issue
Security Disclosure: Improper validation of configured threshold for delegations Summary A compromised or misconfigured TUF repository can have the configured value of signature thresholds set to 0, which effectively disables signature verification. Impact Unathorized modification to TUF metadata files is possible at rest, or during transit as no integrity checks are made. Patches Upgrade to v2.3.1 Workarounds Always make sure that the TUF metadata roles are configured with a threshold of at least 1. Affected code: The metadata.VerifyDelegate did not verify the configured threshold prior to comparison. This means that a misconfigured TUF repository could disable the signature verification by setting the threshold to 0, or a negative value (and so always make the signature threshold computation to pass).
Recommended action: Upgrade to 2.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/theupdateframework/go-tuf/v2 < 2.3.1
Fixed in
2.3.1· Vendor fix available
Issue
Security Disclosure: Client DoS via malformed server response Summary 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 DoS. 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. Impact Client crashes upon receiving and parsing malformed TUF metadata. This can cause long running services to enter an restart/crash loop. Workarounds None currently. Affected code The metadata.checkType function did not properly type assert the (untrusted) input causing it to panic on malformed data.
Recommended action: Upgrade to 2.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/theupdateframework/go-tuf/v2 < 2.0.1
Fixed in
2.0.1· Vendor fix available
Issue
During the ongoing work on the TUF conformance test suite, we have come across a test that reveals what we believe is a bug in go-tuf with security implications. The bug exists in go-tuf delegation tracing and could result in downloading the wrong artifact. We have come across this issue in the test in this PR: https://github.com/theupdateframework/tuf-conformance/pull/115. The test - testgraphtraversal - sets up a repository with a series of delegations, invokes the clients refresh() and then checks the order in which the client traced the delegations. The test shows that the go-tuf client inconsistently traces the delegations in a wrong way. For example, during one CI run, the two-level-delegations test case triggered a wrong order. The delegations in this look as such: Here, targets delegate to "A", and to "B", and "B" delegates to "C". The client should trace the delegations in the order "A" then "B" then "C" but in this particular CI run, go-tuf traced the delegations…
Recommended action: Upgrade to 2.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.