PJSIP is a widely used free and open-source multimedia communication library written in C. It’s the backbone for many real-time communication applications, powering everything from softphones to embedded VoIP. Being secure is critical — especially when audio and video need privacy.

In this exclusive deep-dive, we’ll look closely at CVE-2022-39269, an important vulnerability affecting all PJSIP users relying on SRTP (Secure Real-Time Transport Protocol). We’ll cover how it happens, see snippets of code referencing the flaw and patch, detail how attackers could exploit it, and explain how to stay safe — all in simple language.

What is CVE-2022-39269?

CVE-2022-39269 exposes a situation where PJSIP, under certain conditions, may accidentally switch from using secure SRTP back to plain, insecure RTP when a SRTP session is restarted. When this happens, your voice or video traffic that should be encrypted for privacy gets sent in the clear — open for anyone intercepting packets on the network.

*Anyone* using PJSIP with SRTP is exposed, which covers

- Voice/video calling apps

How Does the Bug Happen?

When a call is established with SRTP, your media (audio/video) is encrypted. But if, during the call, the SRTP session is restarted (a renegotiation event), PJSIP’s older media transport code could revert back to sending/receiving basic RTP. This means new packets would no longer get encrypted.

A call starts and is secured using SRTP.

2. For some reason (network change, renegotiation, hold/resume), SRTP is restarted.

Here’s a conceptual snippet summarizing the buggy logic — simplified for clarity

if (srtp_active && srtp_restart_requested) {
    // ... SRTP cleanup/reset code ...
    // Bug: forgot to re-enable SRTP
    use_rtp = true; // This should NOT happen!
}

// Later code sends packets, using RTP if 'use_rtp' is true...

Following this path, media packets that *should* be protected suddenly aren’t.

Exploit Scenario

An attacker watching the network (for example, on public Wi-Fi or a compromised router) sees a stream of encrypted SRTP packets from your app. But after an SRTP renegotiation (like when you put a call on hold and resume), media falls back to plaintext RTP. From then on, anyone can listen or capture the content of your call.

Is There a Workaround?

No. There are no known workarounds for this vulnerability. All users and vendors must apply the official patch or upgrade as soon as possible.

The Solution: Patch or Update

The PJSIP maintainers have fixed the flaw with commit d2acb9a on their master branch, and the fix will be in PJSIP version 2.13.

Here’s a snippet showing the key fix from the commit

if (srtp_active && srtp_restart_requested) {
    // Instead of disabling SRTP, reinitialize it properly
    status = pjmedia_transport_srtp_start(...);

    if (status != PJ_SUCCESS) {
        // fail securely: stop media, do not fall back to RTP
    }
    use_rtp = false; // Ensure SRTP remains enabled
}

Upgrade to PJSIP 2.13 when released.

2. If you build from source, apply commit d2acb9a manually.

Rebuild and redeploy your applications.

*Don’t delay: if your stack relies on SRTP and still uses an affected version, your users are at direct risk.*

References

- PJSIP Official Advisory and Commit d2acb9a
- CVE-2022-39269 on OSS-Security Mailing List
- SRTP RFC 3711 - Secure Real-Time Transport Protocol

Conclusion

CVE-2022-39269 is a critical flaw for *any* PJSIP deployment using SRTP. It can cause your encrypted calls to become public without warning. There’s no workaround — you must patch or update.

Don’t let your privacy—or your users’—fall through the cracks of a simple protocol bug.

Feel free to share this post with your team or community to keep everyone secure.

Timeline

Published on: 10/06/2022 18:16:00 UTC
Last modified on: 10/11/2022 05:15:00 UTC