# GHSA-77hh-43cm-v8j6: tuf's Metadata API: Targets.get_delegated_role() is missing input validation

> Attackers can bypass delegation verification in TUF metadata if succinct delegation is used, potentially accepting unauthorized metadata signatures.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 16 Feb 2024

## What is GHSA-77hh-43cm-v8j6?

GHSA-77hh-43cm-v8j6 is a vulnerability in tuf, published on 16 Feb 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

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.

## Which versions are affected by GHSA-77hh-43cm-v8j6?

2 open source packages ship an affected version, including tuf.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `tuf` | PyPI | From 2.0.0 | 3.1.1 |
| `tuf` | PyPI | From 2.0.0 | 3.1.1 |

## How do I fix GHSA-77hh-43cm-v8j6?

Upgrade tuf to 3.1.1 or later.

## Is GHSA-77hh-43cm-v8j6 being exploited?

There is no known exploitation of GHSA-77hh-43cm-v8j6 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-77hh-43cm-v8j6 and fix it if it is affected.

What it is: GHSA-77hh-43cm-v8j6 is a vulnerability in tuf, published on 16 Feb 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-77hh-43cm-v8j6 in the wild and no public exploit code.

Affected packages and fixed versions:
- tuf (PyPI): affected from 2.0.0; fixed in 3.1.1
- tuf (PyPI): affected from 2.0.0; fixed in 3.1.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-77hh-43cm-v8j6/ (Markdown: https://insights.sbomify.com/GHSA-77hh-43cm-v8j6/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-77hh-43cm-v8j6

---
From sbomify Insights: https://insights.sbomify.com/GHSA-77hh-43cm-v8j6/
Summaries are generated and may contain mistakes; the official description above is the record.