Read the docs
TI-2024-38513 Aliases GHSA-77hh-43cm-v8j6

tuf's Metadata API: Targets.get_delegated_role() is missing input validation

Priority LOW 38Published · Updated

Key facts

Attack vector
—
Privileges required
—
User interaction
—
Attack complexity
—
Impact type
—
Confidentiality · integrity · availability
—
Fix status
Fixed

No CVSS vector from any source. Fix status from GitHub.

Summary

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. ### Impact If an attacker can make a Metadata API user run `Targets.get_delegated_role()` so that 1. the `Targets` uses succinct delegation 1. 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 1. the `delegated_role` argument is the name of some unrelated Metadata 1. 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. ### Patches A fix is available in python-tuf 3.1.1 as commit 77cb66bc and in later releases as commit eb4834d9._ ### 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.

Why it matters now

Fix Fixed tuf (PyPI): 3.1.1

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
—tuf (PyPI)2.0.0 to before 3.1.13.1.1Patch availableGHSA-77hh-43cm-v8j6
  • tuf (PyPI) Vendor— Affected 2.0.0 to before 3.1.1 Fixed in 3.1.1 Patch available GHSA-77hh-43cm-v8j6

Remediation

  • Fix · GHSA-77hh-43cm-v8j6 tuf (PyPI) Fixed in 3.1.1 Advisory →

Timeline

  1. 2026-10-03 Threatist record created from GHSA-77hh-43cm-v8j6

References

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences