GHSA-4W7R-3222-8H6V

Vulnerability from github – Published: 2026-03-17 19:42 – Updated: 2026-03-20 21:22
VLAI
Summary
Tillitis TKey Client has an Error in Protocol Implementation
Details

Impact

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.

Patches

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.

Affected 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.

  1. Insert the TKey into the client
  2. Run tkey-ssh-agent -p --uss
  3. When prompted for a User Supplied Secret, enter adl
  4. Note the public key and call it pubkey-with-uss
  5. Remove the TKey from the client
  6. Insert the TKey into the client again
  7. Run tkey-ssh-agent -p
  8. Note the public key and call it pubkey-without-uss

Expected behavior: pubkey-with-uss and pubkey-without-uss should not be equal.

Observed behavior: pubkey-with-uss and pubkey-without-uss are equal.

Workaround

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.

Details

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.

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

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:

  1. Not using a USS and keep their keys.
  2. Keep using their USS and use new generated keys.
  3. Use another USS and thus new keys.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tillitis/tkeyclient"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32953"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T19:42:31Z",
    "nvd_published_at": "2026-03-20T05:16:14Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nSome specific (1 out of 256) User Supplied Secrets (USS) were not used,\nmaking the resulting Compound Device Identifier (CDI) the same as if no\nUSS was provided.\n\nAffected client applications: all client apps using the\n[tkeyclient](https://github.com/tillitis/tkeyclient) Go module.\n\n## Patches\n\nUpgrade to v1.3.0.\n\n**NOTE WELL**: For the affected end users upgrading an app containing\n`tkeyclient` to v1.3.0 means their key material will change. An end\nuser can get their old keys by not entering any USS. Please make sure\nto communicate this to end users.\n\n## Affected users\n\nThe steps required to assess whether your USS is vulnerable may vary\ndepending on the client application. The example below shows how to\nperform the check using `tkey-ssh-agent` and the known vulnerable USS\n`adl`.\n\n1. Insert the TKey into the client\n2. Run `tkey-ssh-agent -p --uss`\n3. When prompted for a User Supplied Secret, enter `adl`\n4. Note the public key and call it `pubkey-with-uss`\n5. Remove the TKey from the client\n6. Insert the TKey into the client again\n7. Run `tkey-ssh-agent -p`\n8. Note the public key and call it `pubkey-without-uss`\n\nExpected behavior:\n`pubkey-with-uss` and `pubkey-without-uss` should not be equal.\n\nObserved behavior:\n`pubkey-with-uss` and `pubkey-without-uss` are equal.\n\n## Workaround\n\nWe recommend everyone using `tkeyclient` to update to v1.3.0 and\nrelease new versions of the client apps using it.\n\nHowever, end users that are unable to upgrade to a new version of a client\napp, the recommendation is to change to an unaffected USS. Include\nspecific instructions for your client app.\n\n## Details\n\nWhen loading the device app an optional 32 bytes USS digest is also\nsent. The intention is to ask the end user to enter a USS of arbitrary\nlength, hash it, and then send a 32 bytes digest to TKey.\n\nHowever, there was a bug when sending the digest from the client. The\nindex in the outgoing buffer is wrong and overwrites the boolean\ndefining if the USS is used or not.\n\nThis means that if the USS digest begins with a 0, the rest of the\ndigest is not used at all. If it begins with something else, setting\nthe boolean to true, the USS is used.\n\nThe exported `LoadApp()` function calls an internal helper function\n`loadApp()` which contains this code:\n\n```go\n  if len(secretPhrase) == 0 {\n    tx[6] = 0\n  } else {\n    tx[6] = 1 // Note the 6 here\n    // Hash user\u0027s phrase as USS\n    uss := blake2s.Sum256(secretPhrase)\n    copy(tx[6:], uss[:]) // Note that 6 is used again\n  }\n```\n\nA side effect of this behavior is that only 31 bytes of the USS are\nused. This is not considered a security issue, but an option has been\nadded to enforce use of the full USS. See the release notes for\ndetails. To avoid forcing all users to roll their keys, this option is\ndisabled by default and must be explicitly enabled.\n\n### The fix\n\nThe fix focuses on solving the vulnerability only by: 1) use correct\nindex, 2) always use the last 31 bytes of the USS:\n\n```go\n  if len(secretPhrase) == 0 {\n    tx[6] = 0\n  } else {\n    tx[6] = 1\n    // Hash user\u0027s phrase as USS\n    uss := blake2s.Sum256(secretPhrase)\n    copy(tx[7:], uss[1:])\n  }\n```\n\nThis change means the key material of affected end users will change\ncompared to earlier versions of `tkeyclient`. They have the choice of:\n\n1. Not using a USS and keep their keys.\n2. Keep using their USS and use new generated keys.\n3. Use another USS and thus new keys.",
  "id": "GHSA-4w7r-3222-8h6v",
  "modified": "2026-03-20T21:22:09Z",
  "published": "2026-03-17T19:42:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tillitis/tkeyclient/security/advisories/GHSA-4w7r-3222-8h6v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32953"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tillitis/tkeyclient/commit/4954dccf0287657edf8d405057e134cdff9c59e8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tillitis/tkeyclient"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tillitis/tkeyclient/releases/tag/v1.3.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Tillitis TKey Client has an Error in Protocol Implementation"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…