CVE-2026-57187 in Asterisk
Summary
by MITRE • 10/26/2026
Asterisk is an open source private branch exchange and telephony toolkit. Prior to Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3, an authenticated attacker may cause a heap-use-after-free in `PJSIP TCP/SDP` handling by sending a `SIP INVITE` over a connection-oriented transport and disconnecting before Asterisk responds with the `200 OK`. So far, the crash has only been reproduced when Asterisk is built with `Address Sanitizer`, which detects the issue. `Address Sanitizer` is a development tool with significant performance overhead and, according to the maintainer, is not used in production systems. This issue is fixed in Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
Asterisk serves as a foundational open-source private branch exchange and telephony toolkit widely deployed in enterprise communication infrastructures to manage voice over IP traffic. The vulnerability described involves a critical memory management flaw within the PJSIP TCP/SDP handling subsystem, specifically affecting versions prior to Asterisk 20.20.1, 21.12.3, 22.10.1, and 23.4.1, as well as specific Certified Asterisk releases such as 20.7-cert11 and 22.8-cert3. This flaw is classified as a heap-use-after-free condition, which represents a severe category of memory corruption where software continues to use a pointer after the memory it references has been reallocated or freed. In this specific context, an authenticated attacker can trigger the vulnerability by initiating a SIP INVITE request over a connection-oriented transport and subsequently terminating the TCP connection before Asterisk processes the final response, typically the 200 OK message. This race condition causes the application to access memory that is no longer validly allocated for that session object, leading to undefined behavior within the telephony engine.
The operational impact of this vulnerability centers on service availability and potential code execution risks, although practical exploitation has been constrained by current detection methods. The crash associated with this heap-use-after-free issue has primarily been reproduced in environments where Asterisk is compiled with Address Sanitizer, a powerful debugging tool designed to detect memory errors such as buffer overflows and use-after-free conditions during development. Because Address Sanitizer introduces significant performance overhead due to its extensive runtime checks and instrumentation, it is not utilized in production deployments of Asterisk. Consequently, while the underlying code defect exists in standard production builds, the immediate manifestation of a crash may be less predictable or observable without such debugging tools enabled. However, memory corruption vulnerabilities like this remain high-risk because they can potentially lead to remote code execution if an attacker can precisely control the contents of the freed memory region and manipulate subsequent allocations to place malicious payloads there, thereby hijacking the instruction pointer during the use-after-free access.
From a threat modeling perspective, this vulnerability aligns with CWE-416, which defines Use After Free errors, indicating that the software incorrectly assumes an object is still valid after its lifetime has ended. The attack vector requires authentication, placing it within the scope of authenticated attacks rather than unauthenticated remote exploitation, which slightly reduces the immediate threat surface for publicly exposed instances without proper access controls. However, in internal networks or environments where SIP endpoints are trusted but not strictly monitored, an insider threat or a compromised endpoint could leverage this flaw to disrupt telephony services. The ATT&CK framework categorizes such memory corruption techniques under T1203, which covers Exploitation for Defense Evasion, although the primary intent here is likely denial of service through application crashes rather than stealthy persistence.
Mitigation strategies must prioritize immediate software updates and architectural hardening. Administrators should upgrade Asterisk to version 20.20.1 or later, including all subsequent point releases in the 21.x, 22.x, and 23.x branches, as well as upgrading Certified Asterisk installations to versions 20.7-cert11 and 22.8-cert3 respectively. These updates contain patches that properly manage the lifecycle of SIP session objects during connection teardowns, ensuring that memory is not accessed after it has been released by the TCP stack or internal state machines. In addition to patching, organizations should enforce strict authentication policies for all SIP endpoints to prevent unauthorized entities from initiating INVITE transactions. Network segmentation can also limit exposure by restricting direct access to Asterisk servers from untrusted networks. Regular vulnerability scanning and monitoring of application logs for abnormal termination patterns will help detect any potential exploitation attempts or instability caused by similar edge cases in the telephony stack.