CVE-2025-53399: Sipwise rtpengine RCE Vulnerability

CVE-2025-53399 Overview

CVE-2025-53399 is an origin-validation error [CWE-346] in the endpoint-learning logic of the Sipwise rtpengine media-relay core. Versions prior to 13.4.1.1 allow remote attackers to inject or intercept RTP and SRTP media streams by sending crafted RTP packets. The flaw affects deployments except those configured with strict source enforcement and endpoint learning disabled. rtpengine is widely deployed as a media proxy for Kamailio, OpenSIPS, and other SIP-based Voice over IP (VoIP) infrastructure. Version 13.4.1.1 addresses the issue by limiting heuristic learning to the first five packets and introducing a recrypt flag that fully prevents SRTP-based attacks when both mitigations are enabled.

Critical Impact
Remote unauthenticated attackers can inject or intercept live RTP/SRTP media streams, enabling call eavesdropping and audio injection against VoIP infrastructure.

Affected Products

Sipwise rtpengine versions prior to 13.4.1.1
Debian LTS packaged distributions of rtpengine
SIP/VoIP deployments using rtpengine as a media relay (Kamailio, OpenSIPS front-ends)

Discovery Timeline

2025-08-01 - CVE-2025-53399 published to the National Vulnerability Database
2025-07-31 - Coordinated disclosure via the OpenWall oss-security mailing list and Full Disclosure list
2026-07-21 - Last updated in NVD database

Technical Details for CVE-2025-53399

Vulnerability Analysis

The rtpengine media relay uses endpoint-learning heuristics to determine where to forward RTP media once a SIP session is established. When a packet arrives, the relay may accept its source address as the authoritative endpoint for the stream. This behavior is required in Network Address Translation (NAT) traversal scenarios where the signaled address does not match the true media source.

The learning logic does not adequately validate the origin of incoming packets. A remote attacker who can send packets to the relay can therefore cause the relay to rebind a stream to an attacker-controlled address. Once rebinding occurs, the attacker receives outbound media intended for the legitimate peer and can inject packets that the relay forwards to the other party. For SRTP-protected streams, the attack succeeds because the relay does not re-encrypt media across the learning boundary, allowing bleed and injection despite cryptographic protection at the endpoints.

Root Cause

The root cause is insufficient origin validation [CWE-346] in the endpoint-learning path of the media-relay core. The heuristic accepts unsolicited packets from arbitrary sources for longer than necessary and applies the learned source to subsequent forwarding decisions without cryptographic verification.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker sends RTP packets toward the relay's media ports. If the relay's endpoint learning is active and the strict-source option is not enforced, the relay treats the attacker as the new stream endpoint. The attacker then reads or injects media on that stream. Deployments configured with strict-source and learning disabled are not exploitable through this path.

Detection Methods for CVE-2025-53399

Indicators of Compromise

Unexpected RTP packets arriving at rtpengine media ports from addresses not associated with any signaled SIP endpoint
Sudden source-address changes on active RTP streams shortly after call setup
Elevated volumes of small RTP packets from single external hosts targeting the media port range
SRTP decryption anomalies or packet-loss spikes reported by endpoints during otherwise stable sessions

Detection Strategies

Monitor rtpengine logs for endpoint rebinding events and correlate them against known peer address ranges
Deploy network flow analysis on media-port ranges to identify packet sources that do not match SIP-signaled endpoints
Alert on RTP streams whose remote endpoint changes mid-call without a corresponding SIP re-INVITE or UPDATE
Baseline expected media source geolocation and flag deviations against the baseline

Monitoring Recommendations

Enable verbose logging in rtpengine for learning events and forward logs to a centralized log platform
Continuously inventory rtpengine versions across VoIP infrastructure to identify hosts running versions prior to 13.4.1.1
Track EPSS scoring for this CVE, currently at approximately 4.9% probability, and reassess exposure as the score changes

How to Mitigate CVE-2025-53399

Immediate Actions Required

Upgrade all rtpengine instances to version 13.4.1.1 or later as documented in the GitHub Release Notes v13.4.1.1
Enable the new recrypt flag on SRTP-carrying deployments to fully block SRTP injection and interception
Review perimeter access to rtpengine media ports and restrict inbound traffic to trusted signaling and endpoint ranges
Apply the Debian LTS package update announced in the Debian LTS Announcement where applicable

Patch Information

Sipwise released rtpengine13.4.1.1 with two mitigations. First, the heuristic endpoint-learning mode is now limited to the first five packets of a stream, reducing the window in which an attacker can rebind the endpoint. Second, a new recrypt flag re-encrypts SRTP across the relay boundary, which prevents an attacker who successfully rebinds a stream from decrypting or injecting valid SRTP. Full technical detail is available in the GitHub Security Advisory and the GitHub Security Commits.

Workarounds

Configure rtpengine with strict-source enabled and endpoint learning disabled, which prevents exploitation entirely at the cost of NAT traversal flexibility
Restrict inbound UDP to the relay's media port range using firewall rules that only permit known SIP peer address blocks
Terminate SRTP at trusted session border controllers and re-originate media where feasible, minimizing exposure of the relay to untrusted networks

bash

# Example rtpengine configuration hardening (rtpengine.conf)
# Enforce strict source validation and disable learning where NAT is not required
strict-source = yes
no-redis-required = no
# When SRTP is in use, enable the recrypt behavior introduced in 13.4.1.1
recrypt = yes