https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 15:48:53 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-292979 EUVD-2026-292979 https://cve.radiocsirt.org/vuln/euvd-2026-292979 https://cve.radiocsirt.org/vuln/fkie_cve-2026-6966 <p>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.</p> <p>We recommend you upgrade to tough-v0.22.0 / tuftool-v0.15.0.</p> <p>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.</p> <p>We recommend you upgrade to tough-v0.22.0 / tuftool-v0.15.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-6966 https://cve.radiocsirt.org/vuln/ghsa-8m7c-8m39-rv4x <p><strong>Affected:</strong> crates.io: tough, crates.io: tuftool</p> <p>### 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.</p> <p>### 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.</p> <p>### 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.</p> <p>### Workarounds No workarounds to this issue are known.</p> <p>### References * CVE-2026-6966</p> <p>If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.</p> <p>### Acknowledgement</p> <p>Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this i…</p> <p><strong>Affected:</strong> crates.io: tough, crates.io: tuftool</p> <p>### 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.</p> <p>### 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.</p> <p>### 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.</p> <p>### Workarounds No workarounds to this issue are known.</p> <p>### References * CVE-2026-6966</p> <p>If there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.</p> <p>### Acknowledgement</p> <p>Amazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this i…</p> https://cve.radiocsirt.org/vuln/ghsa-8m7c-8m39-rv4x