CVE-2026-57161

Executive Summary

CVE-2026-57161 is a stack buffer overflow vulnerability in PJSIP, a free and open-source multimedia communication library written in C. The flaw resides in the PJSUA module's handling of Service-Route headers within registration (REGISTER) responses, specifically in the update_service_route() function located in pjsua_acc.c. Affected applications are those using the PJSUA/PJSUA2 account API for registration — the default registration path. A malicious or compromised registrar returning an excessive number of Service-Route headers in a 2xx REGISTER response can trigger out-of-bounds writes to a fixed-size stack array, leading to unexpected application termination (denial of service) or, in worst cases, memory corruption. The vulnerability is patched via commit acc03b5, though no CVE-mapped version range or vendor advisory has been published, and patch confidence remains at 0/4 from tracked intelligence sources.

Technical Analysis

The vulnerability exists in PJSIP's registration subsystem. When a SIP user agent registers with a registrar using the PJSUA account API, it sends a REGISTER request and awaits a 2xx class response. Per SIP protocol semantics (RFC 3608), the registrar may include one or more Service-Route headers in the response. These headers inform the user agent of the proxy path to use for subsequent requests, such as routing non-REGISTER requests through intermediate proxies.

The vulnerable code path is update_service_route() inside pjsua_acc.c. This function processes the incoming Service-Route headers and copies the URI pointers into a fixed-size array allocated on the stack. The NVD description states that the Service-Route URIs are "stored into a fixed-size array without bounding the number of headers." This indicates an absence of a count check or upper-bound validation before inserting each parsed URI into the stack-resident array.

The memory-safety issue arises as a classic CWE-121 (Stack-based Buffer Overflow) condition: the attacker — in this case, a rogue registrar or on-path SIP server — controls the number of Service-Route headers included in the 2xx REGISTER response. When the count of headers exceeds the dimension of the destination array, the overwrite continues past the array boundary, corrupting adjacent stack memory that holds other local variables, saved frame pointers, or return addresses.

It is important to note the nature of the written data. The values placed into the out-of-bounds region are internal pointers derived from the parsed message — not arbitrary attacker-controlled byte sequences. This constrains, but does not eliminate, the exploitation potential. Arbitrary code execution via direct return-address overwrite with attacker-supplied shellcode is unlikely, because the attacker cannot directly write chosen byte values; however, corrupting stack-resident pointers and state structures can lead to subsequent dereference of invalid addresses, which may result in a crash or unpredictable control flow. The NVD description notes "unexpected application termination (denial of service)" as the most likely impact, while cautioning that "memory corruption cannot be excluded."

The attack surface is network-facing: the vulnerable processing occurs on receipt of the REGISTER response. For a legitimate deployment, the registrar is the expected remote party. Compromise of the registrar, or interception on unsecured transports (e.g., SIP over UDP without TLS and without mutual authentication), allows a spoofed 2xx REGISTER response to trigger the overflow.

Exploitation Scenarios

There is no public PoC or exploit code available for CVE-2026-57161, and the CNA has not issued a CISA KEV listing. The following attack chain is inferred from the vulnerability class and the NVD description.

Step 1 — Reconnaissance / Target identification. An attacker first identifies SIP endpoints running PJSIP-based applications using the PJSUA or PJSUA2 account registration API. This may involve SIP OPTIONS or REGISTER probing of target IP ranges to fingerprint the user agent software. Alternatively, the attacker may target the SIP registrar infrastructure itself to compromise the registrar and control its responses. In a less sophisticated model, the attacker acts as a man-on-the-side on an unprotected network segment where SIP traffic traverses in cleartext.

Step 2 — Triggering the flaw. The attacker must cause the vulnerable client to receive a fabricated 2xx REGISTER response containing an abnormally large number of Service-Route headers. If the attacker controls or has compromised the registrar, the response is delivered during the legitimate registration flow. For unencrypted transports, an on-path attacker can intercept the client's REGISTER request and race the legitimate registrar to respond with a malicious 2xx message first. The client will accept the first valid 2xx response it receives.

Step 3 — Payload / execution mechanism. The attacker constructs a SIP 2xx REGISTER response with a valid transaction matching the client's REGISTER request. The response includes Service-Route headers numbering greater than the storage array's capacity. Upon response processing, PJSIP parses the headers and invokes update_service_route(), which iterates over each Service-Route header and writes each parsed URI pointer into the stack array. When the iteration count exceeds the array bounds, the function writes pointers beyond the array's end, corrupting adjacent stack memory. A minimal requirement is that the SIP response still passes PJSIP's SIP message parsing — the headers must be syntactically valid SIP URIs in Service-Route header fields, but their number is the key malicious parameter.

Step 4 — Post-exploitation impact. The immediate consequence is corruption of the call stack. The most probable outcome is a segmentation fault or assertion failure, resulting in application termination — a denial-of-service condition on the VoIP client. Repeated triggering can incapacitate an endpoint permanently until the application is restarted. Depending on the adjacent stack contents, the corruption may alter control flow indirectly (e.g., by corrupting a function pointer or a state variable that later affects branch decisions), but no public analysis demonstrates code execution, and the NVD description assesses arbitrary data control as unlikely.

If the affected application runs an always-on registration agent in a high-availability telecommunications infrastructure (e.g., a softswitch, gateway, or media server), a registrar compromise can cause cascading endpoint failures — many clients registering to the same rogue registrar will crash, degrading or eliminating telephony services across the infrastructure.

Impact Assessment

Business impact. CVE-2026-57161 allows a remote attacker — acting as a rogue registrar, a compromised legitimate registrar, or a network interceptor on unsecured transports — to crash SIP user agents built on PJSIP. For organizations using PJSIP for embedded VoIP devices, softphones, or telephony middleware, a single malicious registration response can cause a denial of service. In deployments where registration is mandatory and continuous (e.g., SIP trunk gateways, PBX endpoints, conference bridges), this translates directly to loss of telephony availability. No CVSS score has been assigned by the CNA, so a numerical severity cannot be cited; however, the flaw is reachable pre-authentication to the SIP identity (the attack occurs during the registration handshake), renderingsome mitigations that rely on authenticated sessions ineffective where the transport is not secured.

Affected systems. Applications using PJSUA or the PJSUA2 account API as the default registration path on PJSIP versions prior to the fix commit acc03b5. This includes the common use of pjsua_acc_add() for account registration. Embedded and desktop VoIP endpoints, telephony libraries, and server-side SIP stacks using PJSIP's high-level API are in scope. Low-level pjsip library users who do not register via the PJSUA account API are not affected by this specific code path.

Blast radius. The attack requires a craftable malicious response path. If SIP traffic uses TLS with certificate validation and only a trusted registrar is used, the attack surface narrows to registrar compromise. Unencrypted UDP/TCP SIP deployments expose a wide man-on-the-side attack surface where an attacker who can observe or guess the client's REGISTER transactions can spoof responses.

Detection Guidance

The following detections are generic and use the vulnerability class as the signal basis. They are provided as starting points, not as validated correlation rules, because no signatures or IOCs tied to exploits of CVE-2026-57161 are publicly available.

Sigma Rule

title: PJSIP Excessive Service-Route Headers in REGISTER Response
id: 3f0b84e1-5a2a-4d6c-b986-1f6f89483c47
status: experimental
description: >
  Detects SIP responses to REGISTER requests containing an abnormally
  high number of Service-Route headers, indicative of an attempt to
  trigger CVE-2026-57161 (stack-based buffer overflow in PJSUA
  update_service_route).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-57161
author: valtersit.com Threat Intelligence
date: 2026/04/01
logsource:
  category: application
  product: sip_parser
detection:
  selection:
    event: sip_response
    request_method: REGISTER
    response_code:
      - 200
      - 201
      - 202
  condition:
    selection
  threshold:  # Holds only if a threshold rule is used
    field: service_route_count
    value: 10
falsepositives:
  - Multi-homed proxies configured by the network operator to send many
    service-route entries (uncommon, usually <= 3)
level: high

YARA Rule

rule SIP_ServiceRoute_Overflow_Traffic
{
    meta:
        author = "valtersit.com Threat Intelligence"
        date = "2026-04-01"
        description = "Detects SIP REGISTER response payloads containing an excess of Service-Route headers, potential CVE-2026-57161 trigger"
        severity = "high"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-57161"
    strings:
        // SIP response status line indicating response to REGISTER
        $reg_method = "REGISTER" ascii nocase
        $sip_200 = "SIP/2.0 200" ascii
        $svc_route = "Service-Route:" ascii nocase
        $svc_route_uri = "<sip:" ascii nocase
    condition:
        // Must be a SIP message and show a response code
        $sip_200 at 0
        and #svc_route >= 10
        and #sip_method > 0
        and any of them
}

Suricata IDS Rule

alert sip any any -> any any (msg:"ET PJSIP CVE-2026-57161 Excessive Service-Route Headers in REGISTER Response"; sid:2026040101; rev:1; metadata:created_at 2026_04_01, updated_at 2026_04_01; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-57161; content:"REGISTER"; offset:0; depth:30; sid:2026040101; pcre:"/Service-Route\s*:/i"; pcre:"/(?:Service-Route\s*:.*){10,}/is"; classtype:attempted-dos;)

Elastic Detection

// Detection for Sysmon or Zeek-like logs containing parsed SIP fields
// Adjust to your event source schema.
any where
  // response code in 2xx range for a REGISTER method
  sip.response_code >= 200 and
  sip.response_code < 300 and
  sip.method == "REGISTER" and
  // the number of Record-Route / Service-Route entries is anomalously high
  sip.service_route_count > 10

Splunk SPL Query

index=siplogs sourcetype=sip*
| where method="REGISTER" AND status_code >= 200 AND status_code < 300
| eval route_count=mvcount(service_route)
| where route_count > 10
| table _time, src_ip, dst_ip, method, status_code, route_count, user_agent
| sort - _time

Wazuh OSSEC Rule

<group name="sip_pjsip,">
  <rule id="995555" level="12">
    <if_sid>1007000</if_sid>
    <match>REGISTER</match>
    <match>Service-Route</match>
    <regex>Service-Route\s*:\s*<sip:</regex>
    <description>Excessive Service-Route headers in SIP REGISTER response - potential CVE-2026-57161 buffer overflow attempt</description>
    <group>pjsip,cve_2026_57161,attack.dos,</group>
  </rule>
</group>

Note: The Wazuh rule presumes a prior parent rule (if_sid) for SIP traffic and an operator-supplied field extraction or log format that allows regex matching of repeated headers. Adjust the parent rule ID to your environment.

Mitigation & Patch Guidance

Patch status. Patch confidence is 0/4 — no patch evidence from any tracked source, and no CVE-mapped version has been released. However, the NVD description indicates that commit acc03b5 in the PJSIP source repository addresses the flaw. Because the description explicitly names this commit as the fix, the primary remediation is to upgrade PJSIP to a build that includes commit acc03b5 or a tagged release containing it. The absence of third-party patch confirmation means the recommendation should be validated against PJSIP release notes.

Immediate mitigations (until patched):

1. Secure the signaling transport. Because a spoofed response over an unprotected transport can trigger the overflow, enforce TLS (SIPS) for SIP signaling between user agents and registrars, with certificate validation on both ends. Replace UDP transport for registration with TLS or DTLS where supported. Disable cleartext UDP/TCP listeners on PSTN-facing or untrusted network segments.
2. Restrict registration peer sources. At the network layer, limit which IP addresses may send SIP responses to the PJSIP endpoint's registration attempts. Use network access control lists to permit only known registrar IPs.
3. Registrar integrity controls. Apply mutual authentication (client and server certificates) or shared-secret-based mechanisms so that spoofed responses are rejected before SIP message processing reaches update_service_route().

Patch/upgrade steps.

1. Monitor the PJSIP project (https://www.pjsip.org) for a new release that includes commit acc03b5. Upgrade to that release or apply the commit as a patch to your source tree.
2. If you build PJSIP from source, git pull the repository and ensure your build's HEAD includes or is a descendant of acc03b5. Recompile and retest your application against a test registrar that sends 15–20 Service-Route headers to confirm the fix.
3. For binary distributions, request a patched build from your vendor or distributions maintainer.

Long-term hardening.

1. Adopt signed or authenticated SIP registrations (e.g., digest authentication plus TLS) so that even a compromised network cannot inject fabricated responses.
2. Fuzz your SIP parser with response-corner-cases — oversized header counts, malformed URI lists, extremely long header values — as part of CI/CD to catch future parsing flaws early.
3. Sanitize registrars and upstream proxies as security-critical infrastructure; apply hardening and monitoring equal to that of the most sensitive tier of your network.

References

1. NVD Entry — CVE-2026-57161: https://nvd.nist.gov/vuln/detail/CVE-2026-57161
2. PJSIP Project — https://www.pjsip.org/ (source repository and release announcements; fix commit acc03b5)
3. CWE-121 — Stack-based Buffer Overflow: https://cwe.mitre.org/data/definitions/121.html
4. RFC 3608 — Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration: https://tools.ietf.org/html/rfc3608
5. CISA Known Exploited Vulnerabilities catalog — (No entry for CVE-2026-57161 at this time; check https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

No threat-actor campaigns, exploit-in-the-wild evidence, or proof-of-concept code references were known at the time of writing. The absence of public exploit material, combined with the constrained nature of stack values written (internal pointers), reduces — but does not eliminate — the probability of weaponized exploitation beyond denial of service.