CVE-2026-55663: unauthenticated state cookie forgery in mediasoup SCTP stack

Stream Control Transmission Protocol (SCTP) is a core transport protocol used within WebRTC implementations to establish and manage data channels. In mediasoup, an open-source WebRTC SFU (Selective Forwarding Unit), SCTP is integrated into the worker processes to allow client-side and server-side data channel communication. The NPM package and Rust crate implementations of mediasoup expose this protocol through transports like WebRtcTransport, PlainTransport, and PipeTransport.

While WebRtcTransport encapsulates SCTP traffic within an encrypted DTLS layer, PlainTransport and PipeTransport allow raw SCTP packets to run directly over unencrypted IP/UDP networks. This unencrypted transport configuration exposes a direct network attack surface if an attacker occupies an on-path network position. When security mechanisms rely entirely on the integrity of protocol-level handshakes, the lack of cryptographic authentication within those handshakes becomes critical.

CVE-2026-55663 describes an architectural flaw in mediasoup's SCTP implementation where the handshake process fails to authenticate State Cookies. Under RFC 9260 specifications, the state cookie returned by a client in a COOKIE-ECHO chunk must be authenticated using a cryptographically secure message authentication code (MAC). In affected versions of mediasoup, this check was absent, rendering the system vulnerable to connection hijacking and arbitrary data injection.

To prevent resource exhaustion attacks and connection spoofing, RFC 9260 Section 5.1.3 mandates that SCTP implementations employ state cookies. During a normal four-way handshake, the server receives an INIT chunk, generates a State Cookie containing session variables, and transmits it within an INIT-ACK chunk. The server does not allocate memory for a Transmission Control Block (TCB) at this stage. It remains stateless until the client returns the identical cookie in a COOKIE-ECHO chunk.

The integrity of this stateless model depends on the server's ability to verify that the returned cookie was indeed generated by the server itself. This verification prevents an attacker from forging cookies with arbitrary parameters. RFC 9260 specifies that the server must sign the cookie with a local secret key using a cryptographically secure hash function. If a cookie returns without a valid signature, the handshake must immediately fail to prevent unauthorized connection establishment.

In affected versions of mediasoup (versions 3.20.0 through 3.20.5 for NPM, and 0.22.0 through 0.22.4 for the Rust crate), the validation algorithm within StateCookie.cpp did not implement any cryptographic verification. The validation code only performed structural integrity checks and validated static byte values. Specifically, the function checked if the cookie length was 44 bytes, verified a static 8-byte magic sequence (0x6D73776F726B6572 or "msworker"), and verified a static 16-bit capabilities magic value (0xAD81). Because these magic values were hardcoded into the source code, they did not provide any security boundaries against an attacker.

The vulnerability is localized to the StateCookie::IsMediasoupStateCookie method in worker/src/RTC/SCTP/association/StateCookie.cpp. The implementation relies purely on static offsets and magic numbers to determine the authenticity of a state cookie. Below is the vulnerable code structure that validates incoming cookies:

bool StateCookie::IsMediasoupStateCookie(const uint8_t* buffer, size_t bufferLength)
{
    MS_TRACE();
 
    if (bufferLength != StateCookie::StateCookieLength) // StateCookieLength is 44 bytes
    {
        return false;
    }
 
    // Verify the static magic value 1 ("msworker")
    if (Utils::Byte::Get8Bytes(buffer, 0) != StateCookie::Magic1)
    {
        return false;
    }
 
    auto* negotiatedCapabilitiesField = reinterpret_cast<NegotiatedCapabilitiesField*>(
      const_cast<uint8_t*>(buffer) + StateCookie::NegotiatedCapabilitiesOffset);
 
    // Verify the static magic value 2 (0xAD81)
    if (ntohs(negotiatedCapabilitiesField->magic2) != StateCookie::Magic2)
    {
        return false;
    }
 
    return true;
}

The patched version replaces this static validation check by introducing a cryptographically signed cookie structure. In the updated implementation, when cookie authentication is required, a unique 32-byte secret is generated for the association. The state cookie structure is expanded to 72 bytes, which includes an 8-byte creation timestamp to prevent replay attacks, followed by a 20-byte HMAC-SHA1 signature computed over the cookie contents using the association secret.

bool StateCookie::VerifyMac(
  const uint8_t* buffer, size_t bufferLength, const uint8_t* macKey, size_t macKeyLength)
{
    MS_TRACE();
 
    if (bufferLength != StateCookie::AuthenticatedStateCookieLength) // 72 bytes
    {
        return false;
    }
 
    // Recalculate HMAC-SHA1 over the first 52 bytes of the cookie
    const uint8_t* expectedMac = Utils::Crypto::GetHmacSha1(
      reinterpret_cast<const char*>(macKey), macKeyLength, buffer, StateCookie::MacOffset);
 
    // Check if calculated MAC matches the MAC appended to the cookie
    return std::memcmp(buffer + StateCookie::MacOffset, expectedMac, StateCookie::MacLength) == 0;
}

In addition to verifying the HMAC, the patched validation code checks the creation timestamp against the current system time. If the elapsed time exceeds 60 seconds (defined by ValidCookieLifeMs), the cookie is rejected as stale. This prevents replay attacks, ensuring that even a sniffed legitimate cookie cannot be reused indefinitely to hijack or establish an association.

Exploitation of CVE-2026-55663 requires an attacker to be in a position to send packets to the target mediasoup UDP port hosting the PlainTransport or PipeTransport. Because these transports transmit SCTP directly over raw UDP without DTLS encapsulation, an on-path attacker can easily inject packets. In systems where these ports are exposed to the public internet, a blind attacker could potentially guess or predict active UDP port numbers and IP addresses.

To conduct the attack, the adversary does not need to complete the full 4-way SCTP handshake. Instead of sending an initial INIT chunk, the attacker constructs a fake COOKIE-ECHO chunk directly. The payload of this chunk contains a forged 44-byte State Cookie. To satisfy the vulnerable validation logic, the attacker writes the static magic sequence 'msworker' into the first 8 bytes and the static magic value 0xAD81 into the negotiated capabilities field offset.

Below is a sequence diagram illustrating the differences between a normal handshake and the forged handshake:

Once the forged COOKIE-ECHO packet is received, the mediasoup server validates the static magic bytes and immediately transitions the association state to CONNECTED. The server then issues a COOKIE-ACK to the attacker. At this point, the attacker has established a valid SCTP association and can transmit SCTP DATA chunks containing arbitrary payloads, effectively injecting unauthorized messages into the mediasoup DataChannel stream as if they were a trusted participant.

The security impact of CVE-2026-55663 is classified as Medium, receiving a CVSS v3.1 score of 5.6 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L). The attack complexity is rated as high because the attacker must have an on-path network position or the capability to accurately predict the UDP ports and active association states of the vulnerable transports. This vulnerability does not impact WebRtcTransport instances since they are encapsulated within DTLS, which enforces end-to-end encryption and cryptographic integrity.

For systems utilizing unencrypted PlainTransport or PipeTransport connections, the consequences are significant. By establishing an unauthorized SCTP association, an attacker can bypass all application-layer authorization checks. This allows the injection of malicious DataChannel messages into active video conferencing sessions. Depending on the application logic, injected messages can manipulate session state, spoof chat messages, or trigger administrative actions within the conference.

In addition to data injection, an attacker can read or intercept SCTP stream traffic if they occupy an active on-path position. This compromises the confidentiality of data channel communication. Furthermore, the ability to arbitrarily establish associations and trigger connection state transitions can be leveraged to disrupt active media streams, leading to localized denial-of-service (DoS) conditions on vulnerable mediasoup worker instances.

The primary remediation path is to upgrade mediasoup to the patched versions. For Node.js-based applications, update the NPM dependency to version 3.20.6 or higher. For Rust-based applications, update the crate dependency to version 0.22.5 or higher. These versions introduce the requireAuthenticatedCookie option, which is enabled by default for PlainTransport and PipeTransport to enforce cryptographic validation.

If immediate upgrading is not feasible, several defensive workarounds must be applied to mitigate the risk:

• Enforce DTLS on Transports: Configure PlainTransport or PipeTransport to utilize DTLS encryption. This ensures that all SCTP packets are encapsulated inside a secure, cryptographically authenticated channel.
• Network-Level Access Control: Restrict access to the UDP port ranges used by PlainTransport and PipeTransport. Implement strict firewall rules (iptables/security groups) to only permit traffic from trusted IP addresses, such as internal application backend servers.
• IPsec or VPN Tunneling: If traffic must cross untrusted networks, wrap the raw UDP packets within a secure tunnel, such as IPsec or WireGuard, to prevent on-path injection and sniffing.

To detect potential exploitation attempts in legacy environments, network security teams can deploy Intrusion Detection System (IDS) rules. These rules should monitor for incoming SCTP COOKIE-ECHO packets targeting the media port range that are not preceded by an INIT chunk from the same source IP. Additionally, security teams can perform static analysis of network captures to identify 44-byte state cookies containing the ASCII sequence 'msworker', which is indicative of the unauthenticated handshake format used in the vulnerable version.