Pre-shared key mode transmits the TGK in cleartext, exposing the SRTP master key

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

9.1 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

EPSS

No dated EPSS signal available.

As published by the source; long descriptions are shortened.

`mykey` implements MIKEY (RFC 3830) for SRTP key exchange. Pre-shared key mode transmitted the TEK Generation Key (TGK) in the clear. `MikeyMessage::new_psk_init` built its KEMAC payload with `EncAlg::Null` and placed the TGK in `enc_data` verbatim. Anyone able to read a PSK-Init message therefore recovers the TGK — and so the SRTP master key — without knowing the pre-shared key. The transmitted value was never even used by the receiver: `complete_psk` re-derived the TGK from the pre-shared key and ignored `enc_data` entirely. The field was write-only; it provided nothing and disclosed everything. A second consequence: the message authentication key was derived from the TGK rather than from the pre-shared key, so an attacker who read the TGK off the wire could also forge a valid message MAC. Integrity was lost along with confidentiality. That aspect is tracked separately as GHSA-xq78-wvcv-hqvj.

Exploitability A MIKEY message is normally distributed as an SDP `a=key-mgmt:mikey`…

Published by the source

9 Oct 2026, 12:00 UTC

Last modified by the source

12 Oct 2026, 09:15 UTC

Source last checked

23 Oct 2026, 22:04 UTC

1. Revision 1 · created · 24 Oct 2026

   Published from osv record RUSTSEC-2026-0335

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: GHSA-fwjg-cm92-j3hj

Advisory: Pre-shared key mode transmits the TGK in cleartext, exposing the SRTP master key
IDs: GHSA-fwjg-cm92-j3hj
Record: https://patchnext.com/advisories/rustsec-2026-0335 (revision 1, source checked 23 Oct 2026, 22:04 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Critical (CVSS 9.1)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: mykey 2.0.0. A vendor fix does not mean a deployment is fixed.

## Affected components
- crates.io mykey: affected >= 0.0.0-0, < 2.0.0; fixed in 2.0.0

## Suggested inspection (read-only)
- crates.io mykey: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on mykey.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/RUSTSEC-2026-0335 (OSV record RUSTSEC-2026-0335 lists affected ranges: crates.io mykey >=0.0.0-0 <2.0.0 (fixed))

Commands are suggestions: review each one before running it.