Which versions of PJSIP are affected by CVE-2026-42225?

PJSIP versions before 2.17 contain a certificate validation bypass in TLS connections when using GnuTLS, allowing remote attackers to intercept and manipulate SIP signaling through man-in-the-middle…. A patch is available.

How to fix or mitigate CVE-2026-42225?

Within 24 hours: Inventory all PJSIP deployments and identify versions prior to 2.17, particularly those using GnuTLS for TLS transport. Within 7 days: Upgrade PJSIP to version 2.17 or later (apply GitHub commit ef684252 if building from source). Verify certificate verification flags (verify_server/verify_client) are explicitly enabled in all SIP TLS transport configurations post-upgrade. Within 30 days: Conduct network traffic analysis to identify any unauthorized TLS certificate usage on SIP signaling connections during the vulnerability window.

PJSIP CVE-2026-42225

Q: What is the CVSS score of CVE-2026-42225?

CVE-2026-42225 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-28428 HIGH

Improper Certificate Validation (CWE-295)

2026-05-07 GitHub_M

Information Disclosure Pjproject

8.2

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.2 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

May 07, 2026 - 22:00 vuln.today

Analysis Generated

May 07, 2026 - 22:00 vuln.today

Patch available

May 07, 2026 - 21:02 EUVD

CVSS changed

May 07, 2026 - 20:22 NVD

8.2 (HIGH)

CVE Published

May 07, 2026 - 18:47 nvd

UNKNOWN (no severity yet)

CVE Published

May 07, 2026 - 18:47 nvd

HIGH 8.2

DescriptionGitHub Advisory

PJSIP is a free and open source multimedia communication library written in C. Prior to version 2.17, on GnuTLS builds, the SIP TLS transport (sip_transport_tls) can accept connections with invalid or untrusted certificates even when the application explicitly enables certificate verification via verify_server = PJ_TRUE or verify_client = PJ_TRUE. This issue has been patched in version 2.17.

AnalysisAI

Certificate validation bypass in PJSIP versions before 2.17 allows remote attackers to perform man-in-the-middle attacks against TLS connections when built with GnuTLS. Despite applications explicitly enabling certificate verification through verify_server or verify_client flags, the SIP TLS transport accepts connections with invalid or untrusted certificates, exposing SIP signaling to interception and manipulation. Vendor-released patch available in version 2.17 with GitHub commit ef684252. No public exploit identified at time of analysis, though the vulnerability is straightforward to exploit given the network attack vector and low complexity (CVSS:4.0 AV:N/AC:L/PR:N).

Technical ContextAI

PJSIP (pjproject) is a widely-used open-source SIP/VoIP stack written in C, commonly integrated into telephony applications, VoIP servers, and unified communications platforms. The vulnerability exists in the GnuTLS-specific TLS implementation (pjlib/src/pj/ssl_sock_gtls.c) where the tls_cert_verify_cb callback function fails to enforce certificate verification policy correctly. The root cause (CWE-295: Improper Certificate Validation) stems from conditional logic that allows TLS handshakes to complete successfully even when certificate chain-trust validation fails and the application has set verify_peer flags. The GnuTLS backend incorrectly returns success from the verification callback rather than GNUTLS_E_CERTIFICATE_ERROR when invalid certificates are presented. This affects the sip_transport_tls component which relies on the lower SSL socket layer to enforce certificate policies. The patch restructures the callback to always populate the verification status and only abort handshakes when verify_peer is set at the SSL-socket level, allowing upper-layer SIP transport code to inspect and enforce its own certificate policies correctly.

RemediationAI

Upgrade PJSIP pjproject to version 2.17 or later, available at https://github.com/pjsip/pjproject/releases/tag/2.17, which includes commit ef684252bb62b0716675b6e99ad7fe4c90e28920 that restructures the GnuTLS certificate verification callback to correctly enforce verify_peer flags. For applications unable to upgrade immediately, switch to OpenSSL TLS backend by recompiling PJSIP with OpenSSL instead of GnuTLS (configure with --disable-libgnutls --enable-libssl), though this requires build environment changes and testing for compatibility. As a temporary workaround, implement application-layer certificate pinning or manual certificate validation by inspecting the peer certificate chain after connection establishment, though this adds complexity and may not prevent all attack scenarios since the TLS handshake still completes with invalid certificates. Network-level compensating controls include restricting SIP TLS endpoints to known trusted IP ranges via firewall rules and deploying TLS-terminating reverse proxies with proper certificate validation in front of vulnerable PJSIP services, though this introduces additional infrastructure and may break direct peer-to-peer SIP features. No workaround fully mitigates risk - upgrade to 2.17 is the recommended remediation path.