CVE-2026-77396 is a high severity (CVSS 7.1) heap out-of-bounds write in the PJSIP AVI parser, affecting version 2.17 and earlier. A crafted AVI file can write past a buffer when an application plays it. The advisory said a fix was in progress, so check the project for the patched release.
What's affected
PJSIP (the pjproject multimedia library) version 2.17 and all earlier versions. The vulnerable code is in pjmedia/src/pjmedia/avi_player.c.
Severity and fix conflict: the record rates this high at 7.1, while the GitHub advisory labels it medium. The advisory also said no patched version was published yet and that a fix was in progress on the master branch, while the record references a commit. We could not confirm a fixed release number, so check the advisory and the project's releases before you decide you are covered.
How to check if you're exposed
PJSIP is usually compiled into other software, often as a bundled copy, so start with your inventory. For a system package, ask the package manager.
dpkg -l | grep -i pjproject
rpm -qa | grep -i pjsip
For a vendored copy, look for the version string in the source tree or the build output. Then ask a narrower question: does your application ever open AVI files through the pjmedia AVI player, and where do those files come from? If the answer is never, the vulnerable code is not on your path.
What to do now
- Find every product or build that bundles PJSIP 2.17 or earlier, including softphones, VoIP gateways and media tools.
- Stop feeding AVI files from untrusted sources to the AVI player. This is the workaround the advisory gives.
- Check the PJSIP advisory and releases for the patched version and apply it as soon as one is confirmed. If you build from source, review the referenced commit.
- If you can, build with assertions enabled as an interim measure. The advisory says that turns the overflow into a controlled abort, at the cost of a crash instead of memory corruption.
Why it matters
This is CWE-122, a heap-based buffer overflow, and CWE-787, an out-of-bounds write. The parser trusted the chunk length written in the file and copied that many bytes into a buffer sized from the declared video dimensions. The two numbers come from the same untrusted file and nothing forced them to agree.
There was a size check, but the advisory says it is an assertion that is compiled out of release builds. That is a classic trap: the guard exists in testing and vanishes in production. For local playback the likely outcome is a crash. Where an application accepts AVI files from outsiders, the advisory says the memory corruption exposure is stronger. No exploitation is reported and the KEV flag is false.
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see whether the affected component appears in your project, and reachability analysis helps separate code paths you actually call from ones you only ship.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this matter if I only use PJSIP for SIP calls?
Only if the AVI player is used. SIP signalling alone does not parse AVI files, but check whether any feature plays video from files.
Why does a debug build help?
The size check is an assertion, so it only runs when assertions are on. With it on, bad input stops the process instead of corrupting memory.
Sources
Last reviewed: 18 October 2026.
