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, process_rtcp_report() used an RTPFB NACK packet's declared RTCP header length as its feedback-entry loop bound instead of the datagram length already validated by the caller. A short packet with an oversized declaration could drive reads far beyond the fixed 16 KiB receive buffer. Any peer able to send RTCP to an active video call can reach the flaw, including calls where remote SDP enables video RTCP even though the SIP profile has no explicit RTCP interval configured. The out-of-bounds read can crash FreeSWITCH and terminate every active call, but supplies no write primitive and does not echo the read values to the sender. This issue is fixed in version 1.11.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-11-05T20:17:45.560Z",
  "pubdate": "2026-11-05T20:17:45.560Z",
  "executiveSummary": "FreeSWITCH versions prior to 1.11.2 are vulnerable to an out-of-bounds (OOB) read vulnerability located within the RTCP report processing logic. The vulnerability originates from improper input validation regarding the length of RTPFB NACK packets.\nBy supplying a crafted RTCP header containing a declared length value that exceeds the actual datagram size, an unauthenticated remote attacker can force the application to perform memory read operations beyond the allocated 16 KiB receive buffer. This flaw is reachable during active video calls, even in configurations where RTCP intervals are not explicitly defined in the SIP profile, provided that remote SDP enables video RTCP.\nThe primary impact of this vulnerability is a denial-of-service (DoS) condition; the out-of-bounds access triggers memory protection faults, leading to the crash of the FreeSWITCH process and the immediate termination of all active voice and video sessions. While the vulnerability does not provide a write primitive or information disclosure (as values are not echoed back to the sender), the service instability presents a significant risk to telecom infrastructure availability. Exploitation does not require authentication, making any peer capable of sending RTCP traffic to an active call a potential threat actor.",
  "technicalDetails": "The vulnerability resides in the process_rtcp_report() function within the FreeSWITCH Software Defined Telecom Stack. The root cause is a trust-boundary violation where the function relies on the length field specified within the RTCP header of an incoming RTPFB NACK packet to define the bounds of a feedback-entry processing loop, rather than validating these bounds against the length of the datagram already verified by the caller.\nThe attack flow begins when a malicious peer initiates or is involved in an active video call with a vulnerable FreeSWITCH instance. The attacker sends a malformed RTCP packet containing a feedback-entry loop bound value that is significantly larger than the actual received datagram. Because the process_rtcp_report() function utilizes this untrusted header length to govern its internal read loops, it attempts to iterate over memory addresses located after the 16 KiB receive buffer.\nThis behavior results in an out-of-bounds read, potentially accessing memory segments that have not been initialized or are outside the process's allocated memory space. In most environments, this unauthorized memory access will result in a segmentation fault, forcing the FreeSWITCH process to terminate abruptly to prevent further instability. This action results in a service-wide disruption, clearing all concurrent calls managed by the instance.\nThe vulnerability is accessible due to the permissive nature of video RTCP handling. If the remote SDP enables video RTCP, the stack is susceptible to processing these malicious packets, regardless of whether a specific RTCP interval has been configured in the SIP profile. The vulnerability does not support arbitrary code execution or data exfiltration as the memory contents retrieved during the out-of-bounds read are not reflected back to the source; the exploitation is strictly limited to a crash-based denial-of-service. The lack of authentication requirements and the ability to trigger this remotely over the network makes it a high-impact reliability issue for production telecom deployments."
}