tough

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Impact

The tough library, prior to 0.12.0, does not properly sanitize delegated role names when caching a repository, or when loading a repository from the filesystem. When the repository is cached or loaded, files ending with the .json extension could be overwritten with role metadata anywhere on the system.

AWS would like to thank https://github.com/jku for reporting this issue.

Patches

A fix is available in version 0.12.0.

Workarounds

No workarounds to this issue are known.

References

https://github.com/theupdateframework/python-tuf/security/advisories/GHSA-wjw6-2cqr-j4qr

Impact

The tough library, prior to 0.12.0, does not properly sanitize target names when caching a repository, or when saving specific targets to an output directory. When targets are cached or saved, files could be overwritten with arbitrary content anywhere on the system.

AWS would like to thank https://github.com/jku for reporting this issue.

Patches

A fix is available in version 0.12.0.

Workarounds

No workarounds to this issue are known.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Improper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.

Impact

The tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6966

If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process

Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata.

Impact

The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache.

Impact

If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Summary

When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files.

Impact

tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject.

Impacted versions: < v0.20.0

Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Acknowledgement

These issues were identified by the TUF-Conformance project. We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.

Impact

The tough library, prior to 0.12.0, does not properly sanitize delegated role names when caching a repository, or when loading a repository from the filesystem. When the repository is cached or loaded, files ending with the .json extension could be overwritten with role metadata anywhere on the system.

AWS would like to thank https://github.com/jku for reporting this issue.

Patches

A fix is available in version 0.12.0.

Workarounds

No workarounds to this issue are known.

References

https://github.com/theupdateframework/python-tuf/security/advisories/GHSA-wjw6-2cqr-j4qr

Impact

The tough library, prior to 0.12.0, does not properly sanitize target names when caching a repository, or when saving specific targets to an output directory. When targets are cached or saved, files could be overwritten with arbitrary content anywhere on the system.

AWS would like to thank https://github.com/jku for reporting this issue.

Patches

A fix is available in version 0.12.0.

Workarounds

No workarounds to this issue are known.

Summary

Missing expiration, hash, and length enforcement in delegated metadata validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users with delegated signing authority to bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache, because load_delegations does not apply the same validation checks as the top-level targets metadata path.

Impact

The tough library, prior to 0.22.0, does not properly verify delegated target metadata. It allows someone with write access to the metadata to serve expired or otherwise invalid targets from a TUF repository which tough will then trust rather than reject.

Impacted Versions:

tough 0.9.0 through 0.21.x, tuftool through 0.14.x

Patches

This issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

No workarounds to this issue are known.

References

• CVE-2026-6967 If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Acknowledgement

Amazon Web Services Labs would like to thank Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process.