CVE-2026-24785 is a critical (CVSS 9.1) cryptographic flaw in Clatter, a Rust implementation of the Noise protocol framework. Some post-quantum handshake patterns broke the Noise PSK validity rule. Versions before 2.2.0 are affected. Upgrade to 2.2.0 and review which patterns you use.
What's affected
The GitHub advisory lists Clatter versions before 2.2.0 as affected, with 2.2.0 patched. The affected default patterns are noise_pqkk_psk0, noise_pqkn_psk0, noise_pqnk_psk0 and noise_pqnn_psk0, along with some hybrid variants. Users of those patterns may have been running handshakes that did not meet the intended security properties.
The library allowed handshake patterns that violated the PSK validity rule in section 9.3 of the Noise Protocol Framework. The fixed release adds runtime checks that detect offending patterns. The workaround is to avoid the affected psk0 variants of the post-quantum patterns, and to review any custom patterns carefully.
How to check if you're exposed
Find Clatter in your Rust dependency tree:
cargo tree -i clatter
Then search your code for the handshake pattern names:
grep -rn "psk0" src/
If you use only non-psk0 patterns, you are not using the flagged ones, though upgrading is still sensible.
For a quick look at your own dependencies, Safeguard's free in-browser dependency scan at https://gold.safeguard.sh/scan checks them against known CVEs in your browser.
What to do now
- Upgrade Clatter to 2.2.0 or later, and run cargo update for it.
- Check which handshake patterns you use, and move away from the affected psk0 post-quantum variants.
- Review any custom handshake patterns against the Noise PSK validity rule.
- Treat sessions that used affected patterns as having weaker guarantees than intended, and consider rekeying.
- Rebuild and redeploy everything that links the crate.
Why it matters
The weakness is CWE-327, use of a broken or risky cryptographic algorithm, here a protocol construction that breaks a rule in the spec. In Noise, a pre-shared key used in the first message needs fresh randomness from the sender to protect against reuse. When a pattern skips that rule, a key derived from the PSK can be used to encrypt without that protection, which the advisory says could allow catastrophic key reuse.
This is a protocol compliance bug, not a coding slip, and a scanner that reads only versions will not tell you whether your pattern is affected. Reading your configuration will. The CVE is not in CISA's Known Exploited Vulnerabilities catalog.
What it means to break a protocol rule
Most vulnerabilities are coding mistakes. This one is a modeling mistake: the library accepted handshake patterns that the Noise specification forbids. The specification's validity rules exist because some combinations of tokens look fine and then fail in subtle ways under analysis.
The rule in question concerns pre-shared keys. When a PSK is mixed in at the start of a handshake, the sender must also contribute fresh randomness, otherwise keys derived from the PSK can be used in ways that lose the protection that randomness provides. The advisory calls the worst case catastrophic key reuse. You do not need the cryptographic details to act on it. You need to know whether your pattern names are on the list.
How to check quickly
Search your code and configuration for the pattern names in the advisory. If you build patterns from custom token strings, read them against section 9.3 of the Noise Protocol Framework, which the advisory links as the validity rule. If you take pattern names from a config file or a peer, check what values are possible.
Plan for rekeying
An upgrade stops new bad handshakes, since 2.2.0 adds runtime checks. It does not repair sessions that already ran on an affected pattern. If those sessions protected data that is still sensitive, plan to move to a valid pattern and renew long lived keys and PSKs.
Make dependency checks smarter
Version checks catch this crate. They do not catch your own wrapper that picked a bad pattern. Keep an inventory of cryptographic dependencies with the protocols and parameters they are configured to use, so that an advisory like this one can be answered with a lookup. Safeguard's dependency inventory is built for that kind of question.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I use Clatter?
Only if you use the affected post-quantum psk0 patterns or similar custom patterns. Check your pattern names.
What does 2.2.0 change?
It adds runtime checks that detect handshake patterns that violate the PSK validity rule.
Sources
Last reviewed: 19 October 2026.
