Description

FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to 1.11.2, dtls_state_setup() compared a peer certificate with the SDP a=fingerprint only when FreeSWITCH was the DTLS client, not when it held the DTLS server role. An unauthenticated peer able to reach the negotiated media port could complete the DTLS-SRTP handshake with an unrelated certificate, obtain the leg's SRTP keys, decrypt and inject media, and displace the legitimate endpoint; on ICE-enabled legs the peer also needs the connectivity-check credentials from SDP, which generally requires signaling visibility or a position on its path. WebRTC and SIP DTLS-SRTP legs are affected whenever the peer selects the active role, while FreeSWITCH client-role handshakes already perform fingerprint validation. Version 1.11.2 introduces the remediation, which requires rtp_dtls_client_cert_verify_mode=fingerprint.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-11-05T20:17:46.397Z",
  "pubdate": "2026-11-05T20:17:46.397Z",
  "executiveSummary": "FreeSWITCH versions prior to 1.11.2 contain a security vulnerability in the dtls_state_setup() function where the DTLS-SRTP peer certificate is not validated against the SDP a=fingerprint attribute when the system operates in the DTLS server role.\nThis flaw allows an unauthenticated remote attacker to perform a man-in-the-middle or impersonation attack by completing the DTLS-SRTP handshake using an arbitrary certificate. By successfully negotiating the handshake, the attacker can obtain SRTP keys required to decrypt, inject, or manipulate media streams within the communication leg.\nThe vulnerability affects WebRTC and SIP DTLS-SRTP legs where the peer assumes the active role. While exploitation typically requires network access to the negotiated media port, ICE-enabled legs may additionally necessitate visibility into signaling traffic to retrieve connectivity-check credentials.\nThe risk is significant as it compromises the confidentiality and integrity of real-time voice and video communication, allowing unauthorized entities to displace legitimate endpoints or intercept sensitive media traffic.",
  "technicalDetails": "The vulnerability resides within the dtls_state_setup() function of the FreeSWITCH Software Defined Telecom Stack. The root cause is an asymmetric validation logic where the system strictly verifies the peer's certificate against the SDP a=fingerprint attribute only when FreeSWITCH acts as the DTLS client. When FreeSWITCH acts as the DTLS server, this critical verification step is omitted.\nIn a standard DTLS-SRTP handshake, the a=fingerprint attribute in the SDP offer/answer exchange is intended to provide a cryptographic hash of the expected certificate. This mechanism ensures that the entity establishing the encrypted media path is the same entity that signaled the call. By failing to enforce this check in the server role, the implementation accepts any certificate presented by the peer during the DTLS handshake.\nThe attack flow proceeds as follows: First, the attacker identifies a target FreeSWITCH instance utilizing DTLS-SRTP. The attacker initiates a call or targets an existing session where the peer is expected to act as the DTLS client. When the target FreeSWITCH instance assumes the role of the DTLS server, the attacker connects to the negotiated media port. Since the server does not validate the fingerprint, the attacker provides an arbitrary, attacker-controlled certificate to complete the handshake.\nOnce the handshake is completed, the attacker and the FreeSWITCH server derive the SRTP master keys. With these keys, the attacker can successfully decrypt incoming media packets or encrypt malicious packets for injection into the stream. In scenarios involving ICE, the attacker may also need to acquire the connectivity-check credentials found within the SDP, which typically requires signaling layer access or an intercept position on the network path.\nThe impact of this vulnerability is the complete compromise of the media plane for the affected session. The attacker can displace the legitimate endpoint, record private audio/video, or inject malicious content. The vulnerability affects all versions of FreeSWITCH prior to 1.11.2 that support DTLS-SRTP, particularly affecting WebRTC and SIP deployments where the peer selects the active role."
}