Three delegated-metadata flaws patched in tough and tuftool
TL;DR - Three bugs in tough and tuftool let an attacker bypass delegated-role signature thresholds, skip integrity checks on delegated targets metadata, and write files outside the intended output directory. Upgrade to tough 0.22.0 and tuftool 0.15.0. No workarounds exist.
What happened
tough is a Rust library for generating and consuming TUF (The Update Framework) repositories. tuftool is its companion CLI for managing those repositories. AWS published security bulletin 2026-019-AWS on April 24, 2026 covering three CVEs - all fixed in the same release cycle.
All three bugs live in the delegated-metadata path, which is exactly where TUF's trust model needs to be strictest. Delegations are how TUF distributes signing authority across roles; get the validation wrong here and the whole chain of trust becomes negotiable.
| CVE | What breaks | What an attacker can do |
|---|---|---|
CVE-2026-6966 | Delegated role signature threshold enforcement | Duplicate a valid signature to satisfy the threshold check and push forged delegated role metadata to clients. |
CVE-2026-6967 | Expiration, hash, and length checks on delegated targets metadata | Bypass integrity validation entirely and poison the local metadata cache with attacker-controlled content. |
CVE-2026-6968 | Output path containment in copy_target, link_target, save_target, SignedRole::write | Write files outside intended output directories via absolute target names or symlink pivots. |
TUF exists to prevent artifact poisoning and rollback attacks in software distribution pipelines. When the tooling that generates or validates TUF metadata is lax around delegations and filesystem writes, the blast radius is your update pipeline - and any automation that treats a TUF repository as a trusted source of truth.
Who is impacted
- Anyone using
toughversions0.1.0through0.21.xinclusive. - Anyone using
tuftoolversions0.1.0through0.14.xinclusive. - Highest-risk environments:
- TUF repositories using delegated roles with multiple signers or distributed signing authority.
- CI runners, release tooling, and artifact mirroring jobs that call
tuftoolortoughand write targets or metadata to disk in paths assumed to be safe.
What to do now
- Upgrade immediately. AWS is unambiguous:
"These issues have been addressed in the following versions:
tough 0.22.0 or later...tuftool 0.15.0 or later" "We recommend upgrading immediately to tough version 0.22.0+ and tuftool version 0.15.0+. Additionally, review and update any forked or derivative code to incorporate the security fixes." - There are no workarounds. AWS confirms:
"There are no known workarounds for these issues. Upgrading to the patched versions is required."
- Treat this as both a dependency update and a repo-integrity review:
- Inventory every place
toughandtuftoolappear: developer tooling, CI images, release automation, internal CLIs. - Rebuild and redeploy any artifacts that embed the old versions - containers, hermetic build images, anything that shipped
toughortuftoolas a bundled binary.
- Inventory every place
- If you operate a TUF repository with delegated roles, do a post-upgrade safety pass:
- Confirm delegated metadata is being regenerated and re-signed as expected under the patched library.
- Review any jobs calling
copy_target,link_target, orsave_targetand verify that output directories cannot be escaped via symlink pivots.
Related
Training
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.