# RUSTSEC-2026-0336: MIKEY message MAC is never verified on receive, so forged messages are accepted > Attackers can forge MIKEY messages because the library fails to verify MACs, bypassing integrity checks and authentication in SRTP key exchange. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 9 Oct 2026 - **Also known as:** GHSA-xq78-wvcv-hqvj ## What is RUSTSEC-2026-0336? RUSTSEC-2026-0336 is a vulnerability in mykey, published on 9 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. ### Official description `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 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. ## Which versions are affected by RUSTSEC-2026-0336? 1 open source package ship an affected version, including mykey. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `mykey` | crates.io | From 0.0.0-0 | 2.0.0 | ## How do I fix RUSTSEC-2026-0336? Upgrade mykey to 2.0.0 or later. ## Is RUSTSEC-2026-0336 being exploited? There is no known exploitation of RUSTSEC-2026-0336 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for RUSTSEC-2026-0336 and fix it if it is affected. What it is: RUSTSEC-2026-0336 is a vulnerability in mykey, published on 9 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. Exploitation: There is no known exploitation of RUSTSEC-2026-0336 in the wild and no public exploit code. Affected packages and fixed versions: - mykey (crates.io): affected from 0.0.0-0; fixed in 2.0.0 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/RUSTSEC-2026-0336/ (Markdown: https://insights.sbomify.com/RUSTSEC-2026-0336/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/RUSTSEC-2026-0336 --- From sbomify Insights: https://insights.sbomify.com/RUSTSEC-2026-0336/ Summaries are generated and may contain mistakes; the official description above is the record.