Repository navigation
Conversation
mykey is a MIKEY (RFC 3830) implementation for SRTP key exchange. Two vulnerabilities affecting all published versions up to and including 1.0.0, both fixed in 2.0.0, filed by the crate author: - Pre-shared key mode transmitted the TGK in the clear in the KEMAC payload, so anyone able to read a PSK-Init message recovered the SRTP master key without knowing the pre-shared key (GHSA-fwjg-cm92-j3hj). - No receive path verified the MIKEY message MAC, so forged or modified messages were accepted (GHSA-xq78-wvcv-hqvj). Each advisory carries its published GitHub Security Advisory in `aliases`, so the nightly OSV sync can attach CVE identifiers once GitHub issues them. Verified with `rustsec-admin lint` built from the revision pinned by this repository's install-rustsec-admin action.
djc
reviewed
Oct 9, 2026
| id = "RUSTSEC-0000-0000" | ||
| package = "mykey" | ||
| date = "2026-10-09" | ||
| url = "https://github.com/waxspin/mykey/security/advisories/GHSA-xq78-wvcv-hqvj" |
Member
There was a problem hiding this comment.
Use an issue, PR or commit in the url, aliases already links to the GHSA.
| (cleartext TGK), which already let a passive observer recover the key material | ||
| outright without needing to forge anything. | ||
|
|
||
| ## Affected versions |
Member
There was a problem hiding this comment.
Don't repeat metadata in the contents.
| guarantee security", and warns to use it with caution. An SDP file or a SAP | ||
| announcement is not such a channel. | ||
|
|
||
| ## Affected versions |
| id = "RUSTSEC-0000-0000" | ||
| package = "mykey" | ||
| date = "2026-10-09" | ||
| url = "https://github.com/waxspin/mykey/security/advisories/GHSA-fwjg-cm92-j3hj" |
- `url` now points at the pull request that fixed both issues (waxspin/mykey#25) instead of the GitHub advisory, which `aliases` already links. - Removed the "Affected versions" and "Patched versions" sections, which restated the `[versions]` table and the absence of an `unaffected` range. The technical description of what changed is kept under "The fix", and the "Workarounds" sections no longer open by restating the patched version. - Dropped the "in versions up to and including 1.0.0" phrasing from the opening paragraphs for the same reason — the version range is metadata.
Author
|
Both addressed in a5c60e4.
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two advisories for
mykey, a MIKEY (RFC 3830) implementation used for SRTP key exchange. Both affect all published versions up to and including 1.0.0 and are fixed in 2.0.0, which is already on crates.io.Filed by the crate author, so per CONTRIBUTING the upstream-report and coordinated-disclosure prerequisites are satisfied. Both have published GitHub Security Advisories, linked via
aliases.RUSTSEC-0000-0000.mdRUSTSEC-0000-0000.1.mdThe cleartext TGK (critical)
MikeyMessage::new_psk_initbuilt its KEMAC withEncAlg::Nulland placed the TEK Generation Key inenc_dataverbatim. Anyone able to read a PSK-Init message therefore recovered the TGK — and so the SRTP master key — without knowing the pre-shared key.The transmitted value was never even used: the receiver re-derived the TGK from the pre-shared key and ignored
enc_data. The field was write-only.MIKEY messages are normally distributed as an SDP
a=key-mgmt:mikeyattribute, which in AES67 / ST 2110 deployments is typically announced over SAP multicast — so a passive listener recovers the session key with no active attack. RFC 3830 §4.2.3 permits NULL encryption only where "the underlying protocols can guarantee security".The unverified MAC (high)
No receive path called
verify_mac. The sender computed and appended an HMAC-SHA-1-160, so a tag was present and looked like integrity protection, but a receiver accepted any message regardless of whether the MAC was correct, wrong, or absent. Note this does not require a MITM position — since nothing is checked, a wholly forged PSK-Init is accepted, henceAC:L.Fixes in 2.0.0
PSK mode now follows RFC 3830 §3.1 as key transport: a random TGK framed as a §6.13 Key data sub-payload and encrypted with AES-CM per §4.2.3, under keys derived from the pre-shared key per §4.1.4. The MAC is keyed from the pre-shared key and verified before anything is decrypted.
Notes for reviewers
patched = [">= 2.0.0"]with nounaffectedrange.RUSTSEC-0000-0000.1.mdsuffix. I verifiedrustsec-admin assign-idhandles this — it assigns two sequential IDs and renames both files, updating eachidfield.rustsec-admin lintpasses, built from the revision pinned by this repo'sinstall-rustsec-adminaction (note that older released versions ofrustsec-adminreject the.1filename).aliasesentries should let the nightly OSV sync attach the CVE IDs once issued.