Public mode

No access to your tenant or devices. Every item links to its source. What this means

Some sources, documents or advisories need attention: 275/275 feeds/APIs · 469/469 docs · 8/9 advisories · checked 10:31 UTC Customize Public modeDiscuss ChangeIntel on Discord

MIKEY message MAC is never verified on receive, so forged messages are accepted

Exact source revision recorded 24 Oct 2026 13:19:54 UTC. It does not establish the source's current position. Latest evidence.

osv · RUSTSEC-2026-0336

Published

`mykey` 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.

Source published
9 Oct 2026 12:00:00 UTC
Source modified
12 Oct 2026 09:15:02 UTC
Observed here
24 Oct 2026 13:19:54 UTC
Source terms
OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.

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

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 10 Nov 10:31 UTC · 275 of 275 readable · 273 fully read · documentation 469/469 current