GHSA-77HH-43CM-V8J6

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.get_delegated_role(delegated_role: str) to find the delegation information.

tuf.api.metadata.Targets.get_delegated_role() should ensure that the given delegated_rolename 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.

Workarounds

tuf.api.metadata users should only call Targets.get_delegated_role(), Targets.verify_delegate() or Targets.get_verification_result() with delegated_role argument that is known to be delegated by the Targets in question.

If an attacker can make a Metadata API user run Targets.get_delegated_role() so that

1. the Targets uses succinct delegation
2. the delegated_role 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.verify_delegate() or Targets.get_verification_result() so that

1. the delegating Targets uses a succinct delegation
2. the delegated_role argument is the name of some unrelated Metadata
3. that other Metadata is correctly signed by the keys defined in the succinct delegation

the result would be a successful verification even though the Targets in question does not actually delegate to delegated_role.

The impact is estimated to be low for following reasons:

• This cannot impact a TUF client that implements the client workflow as specified since the delegated role name is not an input but is collected from the (trusted) delegating Targets itself
• Actual signature verification is not bypassed: The verified metadata must still be correctly signed by the keys specified in the delegating role.
• The described situations are somewhat hypothetical: there does not seem to be any reason for a python-tuf user (whether client or a repository) to use tuf.api.metadata in this way.

All users of tuf.ngclient are specifically not impacted. Users of tuf.api.metadata could be impacted if they use succinct delegations in a way described above.

Kodem intelligence

A fix is available in python-tuf 3.1.1 as commit 77cb66bc and in later releases as commit eb4834d9._

1. What is GHSA-77HH-43CM-V8J6? GHSA-77HH-43CM-V8J6 is a low-severity security vulnerability in tuf (pip), affecting versions >= 2.0.0, < 3.1.1. It is fixed in 3.1.1.
2. Which versions of tuf are affected by GHSA-77HH-43CM-V8J6? tuf (pip) versions >= 2.0.0, < 3.1.1 is affected.
3. Is there a fix for GHSA-77HH-43CM-V8J6? Yes. GHSA-77HH-43CM-V8J6 is fixed in 3.1.1. Upgrade to this version or later.
4. Is GHSA-77HH-43CM-V8J6 exploitable, and should I be worried? Whether GHSA-77HH-43CM-V8J6 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-77HH-43CM-V8J6 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-77HH-43CM-V8J6? Upgrade tuf to 3.1.1 or later.

Other vulnerabilities in tuf