CVE-2026-35203 Overview
CVE-2026-35203 is a heap-buffer-overflow vulnerability affecting ZLMediaKit, a popular streaming media service framework. The vulnerability exists in the VP9 RTP payload parser located in ext-codec/VP9Rtp.cpp, where multiple fields are read from the RTP payload based on flag bits in the first byte without verifying that sufficient data exists in the buffer. An attacker can exploit this flaw by sending a crafted VP9 RTP packet with a 1-byte payload (0xFF, with all flags set), causing the parser to read past the end of the allocated buffer.
Critical Impact
Network-based attackers can trigger a heap-buffer-overflow by sending malformed VP9 RTP packets, potentially causing service disruption or denial of service conditions in streaming media applications using ZLMediaKit.
Affected Products
- ZLMediaKit streaming media service framework (versions prior to commit 435dcbcbbf700fd63b2ca9eac6cef3b5ea75169d)
Discovery Timeline
- April 6, 2026 - CVE-2026-35203 published to NVD
- April 7, 2026 - Last updated in NVD database
Technical Details for CVE-2026-35203
Vulnerability Analysis
This vulnerability is classified as CWE-125 (Out-of-Bounds Read). The VP9 RTP decoder in ZLMediaKit parses RTP payload descriptors by reading flag bits from the first byte and then conditionally reading subsequent fields based on those flags. The critical flaw lies in the absence of bounds checking before accessing payload data beyond the first byte.
When the parser encounters an RTP packet where the first byte has all flag bits set (value 0xFF), it attempts to read picture IDs, layer indices, and other optional fields that may not actually exist in the payload. This leads to heap memory being read beyond the allocated buffer boundaries, which can crash the application or potentially leak sensitive memory contents.
The vulnerability is exploitable over the network without authentication or user interaction, making it particularly concerning for internet-facing streaming services.
Root Cause
The root cause is missing input validation in the RTPPayloadVP9::parse() function. The parser reads flag bits from the first byte and proceeds to access subsequent bytes based on those flags, without first verifying that the payload buffer contains sufficient data. This violates secure coding practices that require boundary checking before memory access operations.
Attack Vector
The attack is network-based and requires no privileges or user interaction. An attacker can send specially crafted VP9 RTP packets to a ZLMediaKit server or client parsing VP9 streams. By constructing a minimal payload with all flag bits set (0xFF) but only a single byte of actual data, the attacker forces the parser to read beyond the allocated heap buffer, triggering the overflow condition.
#define kVBit 0x02
int RTPPayloadVP9::parse(unsigned char *data, int dataLength) {
const unsigned char* dataPtr = data;
+ const unsigned char* dataEnd = data + dataLength;
+
+#define VP9_CHECK_BOUNDS(n) do { if (dataPtr + (n) > dataEnd) return -1; } while (0)
+
// Parse mandatory first byte of payload descriptor
+ VP9_CHECK_BOUNDS(1);
this->hasPictureID = (*dataPtr & kIBit); // I bit
this->interPicturePrediction = (*dataPtr & kPBit); // P bit
this->hasLayerIndices = (*dataPtr & kLBit); // L bit
Source: GitHub Commit
The patch introduces a VP9_CHECK_BOUNDS macro that validates the remaining buffer length before each read operation. If insufficient data remains, the function returns -1 to safely reject the malformed packet.
Detection Methods for CVE-2026-35203
Indicators of Compromise
- Unexpected crashes or segmentation faults in ZLMediaKit streaming services
- Memory access violations reported in application logs related to VP9 RTP parsing
- Abnormal VP9 RTP packets with minimal payloads (1 byte) but maximum flag bits set (0xFF)
- Core dumps showing heap corruption in ext-codec/VP9Rtp.cpp functions
Detection Strategies
- Monitor network traffic for anomalous VP9 RTP packets with unusually small payloads
- Implement intrusion detection rules to flag RTP packets with VP9 payloads containing 0xFF as the first byte with minimal total length
- Deploy application-level monitoring for heap-buffer-overflow exceptions in media streaming components
- Use memory sanitizers (AddressSanitizer) in development and testing environments to detect out-of-bounds reads
Monitoring Recommendations
- Enable detailed logging for RTP packet processing errors and parsing failures
- Set up alerts for service crashes or unexpected restarts of ZLMediaKit processes
- Monitor system logs for memory corruption indicators such as SIGABRT or SIGSEGV signals
- Implement network traffic analysis to identify patterns of malformed RTP packets targeting streaming endpoints
How to Mitigate CVE-2026-35203
Immediate Actions Required
- Update ZLMediaKit to a version containing commit 435dcbcbbf700fd63b2ca9eac6cef3b5ea75169d or later
- Review network exposure of streaming services and restrict access where possible
- Implement network-level filtering to drop suspicious RTP packets with abnormally small payloads
- Enable crash monitoring and automatic service recovery for affected streaming applications
Patch Information
ZLMediaKit has released a security fix in commit 435dcbcbbf700fd63b2ca9eac6cef3b5ea75169d. The patch adds proper bounds checking through the VP9_CHECK_BOUNDS macro, which validates that sufficient data exists in the buffer before each read operation. Users should update to a version containing this fix. For more details, refer to the GitHub Security Advisory and the commit details.
Workarounds
- Restrict network access to ZLMediaKit services using firewall rules to limit exposure to trusted sources only
- Deploy a reverse proxy or application firewall capable of inspecting and filtering malformed RTP packets
- Consider disabling VP9 codec support temporarily if not required for operations
- Implement rate limiting on RTP packet processing to reduce potential impact of exploitation attempts
# Example: Restrict ZLMediaKit service access using iptables
# Allow only trusted IP ranges to access the streaming port
iptables -A INPUT -p udp --dport 10000:10100 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 10000:10100 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


