PJSIP CVE-2026-84975

Exploitation requires ALL of: (1) the PJSIP TLS/SIPS transport with server verification enabled via --tls-verify-server (default-off verification path); (2) the OpenSSL or GnuTLS backend specifically - the mbedTLS backend is NOT affected because it preserves explicit string length; (3) the attacker possessing a certificate issued by a trusted CA whose DNS SubjectAltName contains the target hostname prefix, an embedded NUL byte, and an attacker-controlled suffix (a significant barrier, since compliant public CAs reject embedded-NUL SANs, implying a mis-issuing, private, or compromised issuer); and (4) a man-in-the-middle/on-path interception position on the SIP TLS connection. These conditions - the crafted trusted cert and the MITM position - are what raise attack complexity and prevent mass, opportunistic exploitation despite the network, unauthenticated vector.

This is a genuine but conditionally-gated TLS certificate-validation flaw (CWE-295), not a high-CVSS-but-hollow issue, though several friction factors keep it out of the top-priority tier. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, 7.4) is internally consistent with the description: network vector, unauthenticated, but high attack complexity because the attacker must both possess a certificate from a trusted issuer containing an embedded-NUL DNS SubjectAltName AND hold a man-in-the-middle interception position. No EPSS score, KEV entry, or standalone POC is provided; per the precision rule this is 'no public exploit identified at time of analysis,' although a vendor security advisory (GHSA-382p-87mh-r3q8) and the fixing commit diff are published, so the technical mechanism is fully disclosed and reproducible by a skilled attacker. No SSVC data is supplied. The hardest real-world barrier is obtaining a CA-signed cert whose SAN contains a NUL byte - modern public CAs reject embedded NULs, so practical exploitation likely depends on a mis-issuing/private CA or a compromised issuer, which is why AC:H is appropriate and why this is a MITM/impersonation risk rather than a mass-exploitable one. Note the input tag 'Information Disclosure' understates the impact: the flaw enables active server impersonation and session hijack (I:H), not merely passive disclosure.

An attacker who can intercept a PJSIP softphone's TLS/SIPS connection (e.g., on-path on a hostile network) presents a trusted-issuer certificate whose DNS SAN is 'sip.target.example\0.attacker.example'. Because the OpenSSL/GnuTLS backends copy the SAN with length-recalculating string functions, the value is truncated at the NUL and accepted as valid for 'sip.target.example', letting the attacker impersonate the real server, complete the SIP session, and harvest the client's REGISTER credentials. No public exploit is identified, but the vendor advisory and fix commit fully describe the mechanism.