Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to PJSIP over TCP
-
DeliverySend SIP INVITE with SDP
-
ExploitDisconnect before 200 OK
-
ExecutionTrigger heap use-after-free in SDP/transport handling
-
ImpactPotential Asterisk process crash (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory lifecycle management
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated attacker (PR:L) with a valid SIP account and the ability to reach Asterisk over a connection-oriented transport - specifically PJSIP over TCP (not UDP). The concrete trigger is sending a SIP INVITE and then closing the TCP connection before Asterisk sends its 200 OK response, which races the SDP/transport cleanup in res_pjsip. The dominant limiting factor: per the vendor advisory, the crash has only been reproduced when Asterisk is compiled with Address Sanitizer - a development tool with heavy overhead that the maintainer states is never used in production - so a reliable crash against a standard production build is not demonstrated in the available sources, and authentication plus TCP transport are hard prerequisites. |
| Impact | Signals conflict sharply on this one. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the VA:H availability impact suggest an easily reachable, authenticated network denial-of-service, and the vuln.today decision label is 'this_week'. However, the vendor's own GHSA advisory materially discounts that: the heap-use-after-free has so far only been reproduced in builds compiled with Address Sanitizer - a development instrumentation tool the maintainer states is never used in production - so there is no confirmed crash path on a normally-built, production Asterisk. That contradiction (VA:H in the scored vector vs. 'only observed under ASan' in the authoritative source) is the central uncertainty: the real-world availability impact on production deployments is unverified and likely much lower than VA:H implies. There is no CISA KEV listing and no EPSS score in the provided data, and no proof-of-concept or exploit reference is present - only fix commits and release tags. Net: exploitation also requires valid authentication (PR:L) and a connection-oriented (TCP) transport. This is best treated as a patch-in-normal-cadence memory-safety hardening fix, not a high-urgency widely-exploitable DoS; the 7.1/'this_week' rating overstates practical risk given the ASan-only reproduction. |
| Exploit ScenarioDerived | An authenticated SIP peer opens a TCP (connection-oriented) connection to Asterisk's PJSIP stack, sends a SIP INVITE carrying SDP, then tears down the TCP connection before Asterisk emits its 200 OK, racing the SDP/transport teardown against outbound message processing. In an Address-Sanitizer build this triggers a detected heap-use-after-free; the vendor has not reproduced a crash on a normal production build. No public exploit code or PoC reference is provided in the available data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 26, 2026
A heap use-after-free in Asterisk's PJSIP TCP/SDP handling lets an authenticated SIP user crash the process by sending an INVITE over a connection-oriented transport and dropping the TCP connection before Asterisk returns 200 OK, giving availability impact only. Reproduction so far requires an Address Sanitizer build, which the maintainer states is never used in production, so a crash against standard production binaries is not demonstrated in the available sources. Scoring signals conflict sharply - the published CVSS 4.0 score is 7.1 while the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L - and no public exploit code or active exploitation is reported.
RemediationAI
Upgrade to the vendor-released fixed versions: Asterisk 20.20.1, 21.12.3, 22.10.1 or 23.4.1, or Certified Asterisk 20.7-cert11 or 22.8-cert3; release artifacts are published at https://github.com/asterisk/asterisk/releases/tag/20.20.1, /21.12.3, /22.10.1, /23.4.1, /certified-20.7-cert11 and /certified-22.8-cert3, and the advisory is at https://github.com/asterisk/asterisk/security/advisories/GHSA-g8q2-p36q-94f6. The underlying fix is in the res_pjsip message filter, where shallow pj_strassign() calls were replaced with pool-backed pj_strdup() so the transport's local host name is copied before the TCP transport can be freed. No workaround is documented in the advisory, and the vendor notes the fault has only been observed under Address Sanitizer builds, so standard production builds carry a lower demonstrated risk; because the trigger requires an authenticated SIP account over a connection-oriented transport, limiting SIP credentials to trusted endpoints and restricting PJSIP TCP/TLS exposure reduces the attack surface, though neither substitutes for upgrading.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is a use-after-free (CWE-416, also tracked as CWE-664) in res/res_pjsip/pjsip_message_filter.c, specifically in filter_on_tx_message(), which prepares PJSIP transmit data for outgoing SIP responses. The affected code used pj_strassign() to populate the return-address parameter from tdata->tp_info.transport->local_name.host, a shallow assignment that stores a pointer into the transport object rather than copying the string into the tdata pool. When the peer closes a connection-oriented (TCP/TLS) transport after sending an INVITE but before Asterisk emits its 200 OK, the transport is torn down and freed while transmit data still references its local_name.host memory, so the subsequent SDP/tx processing dereferences freed heap. The upstream fix replaces both pj_strassign() call sites with pj_strdup(tdata->pool, ...) so the host name is copied into the transmit-data pool and outlives the transport. CPE data confirms the affected packages as asterisk (all versions to the fixed releases) and certified-asterisk. Observable impact is confined to availability: memory corruption, process abort/DoS, with no confidentiality or integrity effect assessed. The trigger race is only reported to be detected by Address Sanitizer instrumentation, which is a development-only build configuration.
Know when Asterisk gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Authenticated SIP peer over TCP so PR:L/AV:N/AC:L; no confidentiality or integrity impact, and availability is A:L because a crash is only demonstrated under Address Sanitizer, not production builds.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
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.
Technical POC Analysis
CWE-416 (heap use-after-free), with CWE-664 (improper control of a resource through its lifetime) as the associated weakness in the advisory (GHSA-g8q2-p36q-94f6, CVE-2026-57187, CWE-416, CVSS 4.0 7.…
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Asterisk, a widely used open-source telephony platform, contains a heap use-after-free vulnerability that can be triggered by an authenticated SIP user to crash the service. This affects the availability of voice communications for organizations relying on Asterisk, potentially disrupting call handling and contact center operations. Leadership should prioritize remediation due to the high severity rating and the critical role telephony plays in business continuity.
No vendor-released patch identified at time of analysis. Interim mitigations include restricting SIP access to trusted networks, disabling TCP/TLS transports for untrusted endpoints, implementing rate limiting and anomaly detection for SIP traffic, and ensuring only authorized users can authenticate.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Use-after-free vulnerabilities occur when a program continues to access memory through a pointer after that memory has been deallocated.
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
An issue was discovered in chan_skinny.c in Asterisk Open Source 13.18.2 and older, 14.7.2 and older, and 15.1.2 and old
Stack-based buffer overflow in the ast_parse_digest function in main/utils.c in Asterisk 1.8.x before 1.8.10.1 and 10.x
In Asterisk 11.x before 11.25.2, 13.x before 13.17.1, and 14.x before 14.6.1 and Certified Asterisk 11.x before 11.6-cer
In the pjsip channel driver (res_pjsip) in Asterisk 13.x before 13.17.1 and 14.x before 14.6.1, a carefully crafted tel
Double free vulnerability in the WebSocket Server (res_http_websocket module) in Asterisk Open Source 11.x before 11.14.
An issue was discovered in Asterisk 13.18.4 and older, 14.7.4 and older, 15.1.4 and older, and 13.18-cert1 and older. Ra
Remote code execution can occur in Asterisk Open Source 13.x before 13.14.1 and 14.x before 14.3.1 and Certified Asteris
Asterisk Open Source 1.8 before 1.8.32.3, 11.x before 11.17.1, 12.x before 12.8.2, and 13.x before 13.3.2 and Certified
An issue was discovered in Sangoma Asterisk 13.x before 13.38.3, 16.x before 16.19.1, 17.x before 17.9.4, and 18.x befor
Buffer overflow in DNS SRV and NAPTR lookups in Digium Asterisk 15.x before 15.6.2 and 16.x before 16.0.1 allows remote
A Buffer Overflow issue was discovered in Asterisk through 13.19.1, 14.x through 14.7.5, and 15.x through 15.2.1, and Ce
A local privilege escalation vulnerability exists in the safe_asterisk script included with the Asterisk toolkit package
EUVD-2026-110076
NVD
CVE.org
EPSS
GitHub
Exploit-DB