CVE-2026-29068
Stack Buffer Overflow in PJSIP pjmedia-codec Before
Publication date: 2026-03-06
Last updated on: 2026-03-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| pjsip | pjsip | to 2.17 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-121 | A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function). |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-29068 is a stack buffer overflow vulnerability in the pjmedia-codec component of the pjproject library. It occurs when the codec_parse() functions for the Opus, SILK, and Speex audio codecs parse an RTP payload containing more audio frames than the caller-provided frames[] array can hold. Because the code did not properly check that the frames[] array had enough capacity before writing parsed frames into it, the parsing loop could write beyond the end of the stack-allocated buffer, causing a stack buffer overflow.
This overflow can lead to crashes or potentially allow an attacker to execute arbitrary code. The issue was fixed in version 2.17 by adding bounds checking to clamp the number of frames processed to the maximum allowed and by adding parameter sanity checks to ensure critical parameters are valid before processing.
How can this vulnerability impact me? :
This vulnerability can cause a stack buffer overflow when processing RTP payloads with more frames than expected, which may lead to application crashes or potentially allow remote attackers to execute arbitrary code on the affected system.
If you use pjmedia-codec versions 2.16 or earlier with the Opus, Speex, or SILK audio codecs, your applications are at risk until you update to version 2.17 or later where the issue is patched.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability involves a stack buffer overflow in the pjmedia-codec library when parsing RTP payloads with more frames than the caller-provided buffer can hold. Detection would involve monitoring RTP traffic for unusually large or malformed RTP payloads that exceed expected frame counts.'}, {'type': 'paragraph', 'content': 'Since the issue is triggered by RTP packets containing more frames than the buffer can accommodate, network detection could include capturing RTP streams and analyzing frame counts in payloads using packet analysis tools like Wireshark or tshark.'}, {'type': 'paragraph', 'content': 'On the system side, detection might involve monitoring for crashes or abnormal behavior in applications using pjmedia-codec versions prior to 2.17, especially if they process RTP streams with Opus, Speex, or SILK codecs.'}, {'type': 'paragraph', 'content': 'Specific commands are not provided in the available resources, but general approaches include:'}, {'type': 'list_item', 'content': 'Use tshark or Wireshark to capture and filter RTP packets: e.g., `tshark -Y "rtp" -T fields -e rtp.payload`'}, {'type': 'list_item', 'content': 'Analyze RTP payload sizes and frame counts to identify packets with unusually high frame counts.'}, {'type': 'list_item', 'content': 'Monitor application logs and system crash reports for signs of buffer overflow or crashes related to pjmedia-codec.'}] [1, 2]
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade pjmedia-codec and pjproject to version 2.17 or later, where the vulnerability has been patched.
The patch enforces strict bounds checking on frame counts during RTP payload parsing and adds parameter validation to prevent stack buffer overflows.
Until the upgrade can be applied, consider limiting or filtering RTP traffic to prevent packets with excessive frame counts from reaching vulnerable applications.
Additionally, monitor systems for crashes or abnormal behavior that could indicate exploitation attempts.