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
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
DelegatedRole.istargetinpathpattern uses fnmatch.fnmatch to decide whether a given target path is authorized by a delegation's glob pattern. Python's fnmatch.fnmatch calls os.path.normcase() on both arguments before matching. On POSIX hosts normcase is the identity function; on Windows hosts os.path resolves to ntpath, whose normcase lowercases its input and replaces / with \. As a result, python-tuf's delegation path pattern matching is case-sensitive on Linux/macOS but case-INSENSITIVE on Windows. This makes the authorization decision for a target dependent on the host operating system of the client running the updater. The result on Windows is a TUF specification violation in the python-tuf ngclient implementation. Vulnerable code tuf/api/payload.py (HEAD 7ecb67d): fnmatch.fnmatch source (Python 3.12, unchanged in current mainline): Fix Replace fnmatch.fnmatch with fnmatch.fnmatchcase, which is explicitly documented as "not applying case normalization", so it behaves identically…
Recommended action: Upgrade to 7.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The security of both a TUF client and repository implementations depend on the concept of trusted Metadata objects verifying the signatures over other Metadata that it delegates to. This verification process uses Targets.getdelegatedrole(delegatedrole: str) to find the delegation information. tuf.api.metadata.Targets.getdelegatedrole() should ensure that the given delegatedrolename is actually a name of a role that is delegated by that Targets, but in the case of "succinct delegation" this does not happen. tuf.ngclient users are not impacted but direct users of tuf.api.metadata could be impacted. Impact If an attacker can make a Metadata API user run Targets.getdelegatedrole() so that 1. the Targets uses succinct delegation 1. the delegatedrole argument is not actually delegated by the Targets the result will be incorrect. This also means that if an attacker can make a Metadata API user run Targets.verifydelegate() or Targets.getverificationresult() so that 1. the delegating Targets…
Recommended action: Upgrade to 3.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The function verifyrootselfsigned(), introduced in v0.14.0, and which verifies self-signatures in a new root metadata file, counted multiple signatures by any new root key towards the new threshold. That is, any single new root key could theoretically provide enough signatures to meet the threshold for new key self-signatures required during root metadata update. A scenario where this attack could be relevant is amazingly unlikely in practice to the point where labeling this issue as a security advisory is potentially overstating the impact of the issue. Given that new root keys only become trusted by the client after a successful root metadata update, which also requires the quorum of signatures from old trusted root keys, this issue has been evaluated as low in severity. In particular, in order to exploit this vulnerability, an attacker must: 1. Control one new root key. 2. Craft a new root metadata file such that there is a number of signatures by this new root key greater…
Recommended action: Upgrade to 0.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In both clients (tuf/client and tuf/ngclient), there is a path traversal vulnerability that in the worst case can overwrite files ending in .json anywhere on the client system on a call to getonevalidtargetinfo(). It occurs because the rolename is used to form the filename, and may contain path traversal characters (ie ../../name.json). The impact is mitigated by a few facts: It only affects implementations that allow arbitrary rolename selection for delegated targets metadata The attack requires the ability to A) insert new metadata for the path-traversing role and B) get the role delegated by an existing targets metadata The written file content is heavily restricted since it needs to be a valid, signed targets file. The file extension is always .json. Patches A fix is available in version 0.19 or newer. Workarounds None that do not require code changes. Clients can restrict the allowed character set for rolenames, or they can store metadata in files named in a way that is…
Recommended action: Upgrade to 0.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Python TUF reference implementation tuf<0.12 will incorrectly trust a previously downloaded root metadata file which failed verification at download time. This allows an attacker who is able to serve multiple new versions of root metadata (i.e. by a man-in-the-middle attack) culminating in a version which has not been correctly signed to control the trust chain for future updates. While investigating the reported vulnerability, we discovered that the detailed client workflow was not fully implemented. Specifically, for step 1.3 the newly downloaded root metadata was not being verified with a threshold of keys specified in the new root metadata file. This missing step of the client workflow has been implemented in PR #1101, which is included in v0.14.0 of tuf. Patches A fix, is available in version 0.12 and newer. Workarounds No workarounds are known for this issue. References Pull request resolving the invalid root becoming trusted issue PR 885 Pull request implementing…
Recommended action: Upgrade to 0.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker who can gain file access to the repository and modify metadata files may cause a denial of service to clients by creating many invalid signatures on a metadata file. Having a large number of signatures to verify will delay the moment when the client will determine the signature is not valid. This delay may be for at least a few minutes, but possibly could be longer especially if multiple files are impacted. The tuf maintainers would like to thank Erik MacLean of Analog Devices, Inc. for reporting this issue. Patches No fix exists for this issue. Workarounds No workarounds are known for this issue. References CVE-2020-6173 Issue #973
Recommended action: Upgrade to 0.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 0.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.