RUSTSEC-2026-0336 (GHSA-XQ78-WVCV-HQVJ)
Vulnerability from osv_rustsec – Published: 2026-10-09 12:00 – Updated: 2026-10-12 08:58 – Source websitemykey implements MIKEY (RFC 3830) for SRTP key exchange. No receive path
verified the MIKEY message authentication code.
crypto::verify_mac existed and was correct, but it was called only from unit
tests — neither MikeyMessage::from_bytes nor MikeyMessage::complete_psk
invoked it.
new_psk_init computed an HMAC-SHA-1-160 over the serialized message and
appended it, so the tag was present on the wire and looked like integrity
protection. It was decorative: a receiver accepted any message regardless of
whether the MAC was correct, wrong, or absent.
Consequences
- An attacker able to inject or modify MIKEY messages in transit faced no integrity check. Modified RAND, SSRC or security-policy payloads were accepted silently. Note that this does not require a man-in-the-middle position: since nothing was checked, a wholly forged PSK-Init was accepted.
- Pre-shared key mode therefore provided no mutual authentication, despite the documentation claiming that it did. Possession of the pre-shared key was never actually proven by either party.
- Replayed init messages were not rejected.
The practical severity was bounded by GHSA-fwjg-cm92-j3hj (cleartext TGK), which already let a passive observer recover the key material outright without needing to forge anything.
The fix
complete_psk now verifies the message MAC before any decryption, so a
message that fails authentication yields no key material at all. A MacAlg::Null
payload, an absent MAC and a truncated MAC are each refused rather than treated
as "no check required".
The authentication key is now derived from the pre-shared key per RFC 3830 §4.1.4 rather than from the TGK — a prerequisite, since verifying against a TGK-derived key would have been circular while the TGK travelled in the message itself. Optional §6.9 verification messages were also added, giving the exchange genuine mutual authentication.
Replay protection is still absent: a captured PSK-Init can be replayed and will be accepted, because the optional COUNTER timestamp is emitted rather than a mandatory NTP type and no record of seen timestamps or RAND values is kept. That gap is tracked at https://github.com/waxspin/mykey/issues/24 and is not covered by this advisory.
Workarounds
Treat parsed MIKEY messages as unauthenticated input: do not rely on pre-shared key mode for peer authentication or message integrity, and carry it over a transport that provides both.
| URL | Type | |
|---|---|---|
{
"affected": [
{
"database_specific": {
"categories": [
"crypto-failure"
],
"cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"informational": null
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "mykey",
"purl": "pkg:cargo/mykey"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-0"
},
{
"fixed": "2.0.0"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [
"GHSA-xq78-wvcv-hqvj"
],
"database_specific": {
"license": "CC0-1.0"
},
"details": "`mykey` implements MIKEY (RFC 3830) for SRTP key exchange. No receive path\nverified the MIKEY message authentication code.\n\n`crypto::verify_mac` existed and was correct, but it was called only from unit\ntests \u2014 neither `MikeyMessage::from_bytes` nor `MikeyMessage::complete_psk`\ninvoked it.\n\n`new_psk_init` computed an HMAC-SHA-1-160 over the serialized message and\nappended it, so the tag was present on the wire and looked like integrity\nprotection. It was decorative: a receiver accepted any message regardless of\nwhether the MAC was correct, wrong, or absent.\n\n## Consequences\n\n- An attacker able to inject or modify MIKEY messages in transit faced no\n integrity check. Modified RAND, SSRC or security-policy payloads were accepted\n silently. Note that this does not require a man-in-the-middle position: since\n nothing was checked, a wholly forged PSK-Init was accepted.\n- Pre-shared key mode therefore provided no mutual authentication, despite the\n documentation claiming that it did. Possession of the pre-shared key was never\n actually proven by either party.\n- Replayed init messages were not rejected.\n\nThe practical severity was bounded by GHSA-fwjg-cm92-j3hj (cleartext TGK), which\nalready let a passive observer recover the key material outright without needing\nto forge anything.\n\n## The fix\n\n`complete_psk` now verifies the message MAC **before** any decryption, so a\nmessage that fails authentication yields no key material at all. A `MacAlg::Null`\npayload, an absent MAC and a truncated MAC are each refused rather than treated\nas \"no check required\".\n\nThe authentication key is now derived from the pre-shared key per RFC 3830 \u00a74.1.4\nrather than from the TGK \u2014 a prerequisite, since verifying against a TGK-derived\nkey would have been circular while the TGK travelled in the message itself.\nOptional \u00a76.9 verification messages were also added, giving the exchange genuine\nmutual authentication.\n\nReplay protection is still absent: a captured PSK-Init can be replayed and will\nbe accepted, because the optional COUNTER timestamp is emitted rather than a\nmandatory NTP type and no record of seen timestamps or RAND values is kept. That\ngap is tracked at \u003chttps://github.com/waxspin/mykey/issues/24\u003e and is not covered\nby this advisory.\n\n## Workarounds\n\nTreat parsed MIKEY messages as unauthenticated input: do not rely on pre-shared\nkey mode for peer authentication or message integrity, and carry it over a\ntransport that provides both.",
"id": "RUSTSEC-2026-0336",
"modified": "2026-10-12T08:58:45Z",
"published": "2026-10-09T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/mykey"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0336.html"
},
{
"type": "WEB",
"url": "https://github.com/waxspin/mykey/pull/25"
}
],
"related": [],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "MIKEY message MAC is never verified on receive, so forged messages are accepted"
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.