CVE-2026-84975: PJSIP: TLS server identity (hostname) verification bypass via embedded NUL in certificate SubjectAltName (OpenSSL and GnuTLS backends)
PJSIP is a free and open source multimedia communication library written in C. In 2.17 and earlier, the OpenSSL and GnuTLS backends in pjlib/src/pj/sslsockossl.c and pjlib/src/pj/sslsockgtls.c copy DNS SubjectAltName values with string functions that recalculate their length and truncate an embedded NUL byte. With server verification enabled through --tls-verify-server for the PJSIP TLS/SIPS transport, a certificate containing a DNS SubjectAltName formed from the target hostname prefix followed by an embedded NUL and an attacker-controlled suffix can therefore be accepted for the prefix hostname. An attacker who possesses such a certificate from a trusted issuer and can intercept the connection can impersonate the target server, complete the SIP session, and receive REGISTER credentials. The mbedTLS backend is not affected because it preserves the explicit string length. No fixed version is available as of this review.
Affected Software
Event History
Frequently Asked Questions
Which deployments are affected?
PJSIP 2.17 and earlier are affected when using the OpenSSL or GnuTLS TLS backend for a TLS/SIPS transport with server verification enabled through --tls-verify-server. The mbedTLS backend is not affected.
What must an attacker be able to do to exploit this issue?
The attacker needs a certificate from a trusted issuer whose DNS SubjectAltName contains the target hostname prefix followed by an embedded NUL and attacker-controlled suffix. They must also be able to intercept the victim's connection to impersonate the target server.
What is the practical impact of successful exploitation?
An attacker can impersonate the target SIP server, complete the SIP session, and receive REGISTER credentials.
How can I determine whether my deployment is exposed?
Check whether the installation is PJSIP 2.17 or earlier, whether its TLS/SIPS transport uses the OpenSSL or GnuTLS backend, and whether --tls-verify-server is enabled. Deployments using mbedTLS are not affected by this specific flaw.
What can be done if no fixed version is available?
No fixed version was available as of the review. The available data identifies the mbedTLS backend as unaffected, so deployments should assess whether they can use that backend rather than OpenSSL or GnuTLS.