CVE-2026-32953: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-32953 is a protocol implementation error in the Tillitis TKey Client Go module (github.com/tillitis/tkeyclient) that causes 1 out of every 256 User Supplied Secrets (USS) to be silently discarded, producing the same Compound Device Identifier (CDI) and key material as if no USS was provided. It affects all versions of the tkeyclient Go module prior to 1.3.0, impacting all client applications built on this module. The vulnerability was disclosed on March 16, 2026, and published to the GitHub Advisory Database on March 17, 2026. It carries a CVSS v3.1 base score of 4.6 (Medium) and a CVSS v4.0 base score of 4.7 (Medium), with physical access required (GitHub Advisory, Tillitis Advisory).

The root cause is a buffer index error (CWE-303: Incorrect Implementation of Authentication Algorithm) in the internal loadApp() function. When loading a device app, the code sets tx[6] = 1 to indicate USS is in use, then immediately calls copy(tx[6:], uss[:]), which overwrites that boolean flag with the first byte of the BLAKE2s USS digest. If the digest's first byte is 0x00 (statistically 1 in 256 cases), the USS-enabled flag is set to zero, causing the firmware to treat the request as if no USS was provided and generate default key material. The fix in v1.3.0 corrects the index to tx[7] and copies uss[1:], ensuring the boolean is not overwritten (GitHub Advisory, Fix Commit):

// Vulnerable code
tx[6] = 1
copy(tx[6:], uss[:])  // overwrites the boolean

// Fixed code
tx[6] = 1
copy(tx[7:], uss[1:])  // correct index

The primary impact is an integrity failure: affected users who supply a USS whose BLAKE2s hash begins with 0x00 unknowingly generate the same CDI and cryptographic key material as an unauthenticated (no-USS) session, effectively nullifying the additional security layer the USS is intended to provide. This means derived keys, SSH credentials, or other secrets generated via the TKey are weaker than expected and could be reproduced by any party who simply does not supply a USS. Additionally, upgrading to v1.3.0 changes key material for affected users, requiring key rotation and potentially disrupting access to systems protected by the previously derived keys (GitHub Advisory, Tillitis Advisory).

A proof-of-concept verification procedure is publicly documented in the official security advisory, demonstrating the bug by comparing SSH public keys generated with and without a USS using tkey-ssh-agent and the known-vulnerable USS adl (Tillitis Advisory). There is no evidence of active in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.016% (1st percentile), reflecting very low probability of near-term exploitation (GitHub Advisory). Physical access to the TKey device is required, significantly limiting the attacker pool.

1. Identify a vulnerable USS: Determine whether the target user's USS produces a BLAKE2s hash beginning with 0x00. This can be done by hashing candidate secrets: blake2s.Sum256([]byte("candidate")) and checking if the first byte is zero.
2. Insert TKey and run with USS: Insert the TKey device into the client machine and run the client application (e.g., tkey-ssh-agent -p --uss), entering the target USS when prompted. Note the resulting public key (pubkey-with-uss).
3. Re-run without USS: Remove and reinsert the TKey, then run the client application without providing any USS (e.g., tkey-ssh-agent -p). Note the resulting public key (pubkey-without-uss).
4. Confirm vulnerability: If pubkey-with-uss equals pubkey-without-uss, the USS is silently discarded and the device is generating default key material.
5. Exploit: An attacker with physical access to the TKey (or knowledge that the victim uses a vulnerable USS) can generate the same key material without knowing the USS, simply by not providing one — effectively bypassing the USS-based authentication layer (Tillitis Advisory).

• Behavioral: SSH public keys generated with a USS match those generated without any USS for the same TKey device — this is the primary observable indicator of a vulnerable USS being in use.
• Logs: Application logs from tkey-ssh-agent or other tkeyclient-based tools showing key generation events without USS differentiation; absence of expected key diversity across sessions with and without USS.
• File System: Presence of tkeyclient Go module versions prior to 1.3.0 in application dependency files (go.sum, go.mod) — check for github.com/tillitis/tkeyclient versions < 1.3.0 (GitHub Advisory).

The primary remediation is to upgrade the tkeyclient Go module to version 1.3.0 or later, which corrects the buffer index error (v1.3.0 Release). Important: Upgrading will change key material for affected users; end users should be informed that they can recover their old keys by not entering any USS after upgrading. As a temporary workaround for users unable to upgrade, switch to a USS whose BLAKE2s hash does not begin with a 0x00 byte. Developers maintaining applications that depend on tkeyclient should release updated versions of their apps incorporating v1.3.0 of the module (Tillitis Advisory).

The vulnerability was disclosed directly by Tillitis maintainer dehanj via the GitHub Security Advisory system on March 16, 2026, with clear technical documentation and remediation guidance (Tillitis Advisory). The advisory received coverage from automated CVE tracking services and security feeds, but no significant independent researcher commentary or broad media coverage has been identified, consistent with the niche, physical-access-only nature of the vulnerability.