Deploy autonomous AI agents that reason, exploit, and validate complex vulnerability chains — not another scanner, an agentic system that thinks like a senior pentester.
CVE-2026-32953 is a low severity vulnerability with a CVSS score of 0.0. No known exploits currently, and patches are available.
Very low probability of exploitation
EPSS predicts the probability of exploitation in the next 30 days based on real-world threat data, complementing CVSS severity scores with actual risk assessment.
Some specific (1 out of 256) User Supplied Secrets (USS) were not used, making the resulting Compound Device Identifier (CDI) the same as if no USS was provided.
Affected client applications: all client apps using the tkeyclient Go module.
Upgrade to v1.3.0.
NOTE WELL: For the affected end users upgrading an app containing
tkeyclient to v1.3.0 means their key material will change. An end
user can get their old keys by not entering any USS. Please make sure
to communicate this to end users.
The steps required to assess whether your USS is vulnerable may vary
depending on the client application. The example below shows how to
perform the check using tkey-ssh-agent and the known vulnerable USS
adl.
tkey-ssh-agent -p --ussadlpubkey-with-usstkey-ssh-agent -ppubkey-without-ussExpected behavior:
pubkey-with-uss and pubkey-without-uss should not be equal.
Observed behavior:
pubkey-with-uss and pubkey-without-uss are equal.
We recommend everyone using tkeyclient to update to v1.3.0 and
release new versions of the client apps using it.
However, end users that are unable to upgrade to a new version of a client app, the recommendation is to change to an unaffected USS. Include specific instructions for your client app.
When loading the device app an optional 32 bytes USS digest is also sent. The intention is to ask the end user to enter a USS of arbitrary length, hash it, and then send a 32 bytes digest to TKey.
Please cite this page when referencing data from Strobes VI. Proper attribution helps support our vulnerability intelligence research.
However, there was a bug when sending the digest from the client. The index in the outgoing buffer is wrong and overwrites the boolean defining if the USS is used or not.
This means that if the USS digest begins with a 0, the rest of the digest is not used at all. If it begins with something else, setting the boolean to true, the USS is used.
The exported LoadApp() function calls an internal helper function
loadApp() which contains this code:
if len(secretPhrase) == 0 {
tx[6] = 0
} else {
tx[6] = 1 // Note the 6 here
// Hash user's phrase as USS
uss := blake2s.Sum256(secretPhrase)
copy(tx[6:], uss[:]) // Note that 6 is used again
}
A side effect of this behavior is that only 31 bytes of the USS are used. This is not considered a security issue, but an option has been added to enforce use of the full USS. See the release notes for details. To avoid forcing all users to roll their keys, this option is disabled by default and must be explicitly enabled.
The fix focuses on solving the vulnerability only by: 1) use correct index, 2) always use the last 31 bytes of the USS:
if len(secretPhrase) == 0 {
tx[6] = 0
} else {
tx[6] = 1
// Hash user's phrase as USS
uss := blake2s.Sum256(secretPhrase)
copy(tx[7:], uss[1:])
}
This change means the key material of affected end users will change
compared to earlier versions of tkeyclient. They have the choice of: