Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed UNISTIM UDP port
-
DeliveryRegister as configured phone MAC
-
ExploitSend crafted DIALPAGE request packet
-
ExecutionOverflow phone_number buffer (OOB write)
-
ImpactCrash Asterisk (denial of service)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, write limits
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 | Exploitation is strictly gated by non-default configuration: the chan_unistim channel driver (legacy UNISTIM/Nortel phone support) must be loaded and configured with a valid UNISTIM UDP port that the attacker can reach over the network. Additionally, the attacker must register as a configured phone MAC, or the deployment must expose an equivalent production/autoprovisioning path that lets the client reach the main page. The trigger is a carefully crafted incoming request packet that overflows DIALPAGE digit handling into the phone_number field. Limiting factors: chan_unistim is not enabled in default Asterisk installs and is a deprecated, niche driver, so most deployments are not exposed; the impact is confined to a crash (DoS) with no confidentiality or integrity effect; and the AC:H rating reflects the combined module-loaded, port-reachable, and MAC-registration prerequisites. |
| Impact | This is a denial-of-service vulnerability (availability-only crash, C:N/I:N/A:H) with a vendor CVSS of 5.9 (medium). The CVSS vector reports AV:N/AC:H/PR:N/UI:N: network-reachable and nominally unauthenticated, but AC:H reflects the real-world gating conditions. Several escalating signals that would raise priority are ABSENT: there is no CISA KEV listing, no EPSS score was provided in the input, and the references are limited to the vendor GHSA advisory, fix commits, and release tags - none is a working exploit, so no public exploit is identified. The vuln.today decision label is 'this_month', consistent with a patch-this-cycle item rather than an emergency. The practical priority is moderate and bounded by deployment: exploitation requires the legacy chan_unistim driver to be loaded and configured with a reachable UNISTIM UDP port, plus the attacker registering as a configured phone MAC (or an autoprovisioning path). On systems not running chan_unistim - the common case - real risk is effectively nil. Note the tension between PR:N and the stated precondition that 'the attacker must register as a configured phone MAC'; UNISTIM registration is MAC-based rather than credentialed, which is why PR:N is defensible, but defenders should treat 'unauthenticated' loosely here. No EPSS or KEV data to corroborate exploitation likelihood - absence of those signals, combined with the niche module, suggests low widespread-exploitation probability. |
| Exploit ScenarioDerived | An attacker who can reach the configured UNISTIM UDP port registers as a configured phone MAC (or uses an equivalent production/autoprovisioning path to reach the main page) and sends a carefully crafted incoming request that drives DIALPAGE digit handling past the phone_number buffer, causing an out-of-bounds write that crashes Asterisk. The result is a service outage (telephony denial of service), not code execution or data disclosure. No public exploit code is identified at time of analysis; AC:H reflects the required module, port-reachability, and registration preconditions. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
An out-of-bounds write in the chan_unistim channel driver lets a remote attacker crash Asterisk by sending a crafted request packet that overflows the internal phone_number field during DIALPAGE digit handling; the flaw is contained to a denial of service with no confidentiality or integrity impact (C:N/I:N/A:H). Only deployments that load chan_unistim and configure a reachable UNISTIM UDP port are exposed, and the attacker must also be able to register as a configured phone MAC or reach the main page through an equivalent autoprovisioning path, which keeps the assessed severity at 5.9 with AC:H. The issue is fixed in Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11 and 22.8-cert3; no public exploit code or CISA KEV entry was identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade to Asterisk 20.20.1, 21.12.3, 22.10.1 or 23.4.1, or to Certified Asterisk 20.7-cert11 or 22.8-cert3, available from the project release pages (https://github.com/asterisk/asterisk/releases/tag/20.20.1, 21.12.3, 22.10.1, 23.4.1, certified-20.7-cert11, certified-22.8-cert3) and detailed in the advisory GHSA-3g56-cgrh-95p5; the fix enforces a MAX_PHONE_NUMBER_LENGTH limit in key_dial_page() (commits 430f423c84e4e32a462d907632b66c9793236e96 and related). As a compensating measure where upgrading must wait, unload the chan_unistim module or avoid configuring a UNISTIM UDP port reachable by untrusted networks, and restrict the port to trusted phone subnets, accepting that this removes legacy UNISTIM phone support and autoprovisioning for those devices.
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
Asterisk's chan_unistim module implements legacy UNISTIM (Nortel/Unistim IP phone) support over UDP and keeps per-device session state in a struct unistim_device, which includes a fixed-size phone_number buffer sized from AST_MAX_EXTENSION and a companion size_phone_number counter. The root cause is CWE-787 (out-of-bounds write): key_dial_page() appends characters for DIALPAGE key presses without checking whether the buffer is already full, so a remote packet carrying an oversized digit sequence writes past the end of phone_number and corrupts adjacent memory, crashing the process. The upstream commits add a MAX_PHONE_NUMBER_LENGTH of AST_MAX_EXTENSION minus one and return early once size_phone_number reaches that limit. Because the affected code is only reachable when the module is loaded, bound to a valid UNISTIM UDP port, and the peer is recognized (configured phone MAC registration or an equivalent production/autoprovisioning path to the main page), the assessed vector is AV:N/AC:H/PR:N/UI:N/S:U with availability-only impact.
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
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable UDP port (AV:N); AC:H for the chan_unistim-loaded, reachable-port, and MAC-registration preconditions; UNISTIM MAC registration is not credentialed so PR:N; crash only, so A:H and C:N/I:N.
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 out-of-bounds write in chan_unistim DIALPAGE digit handling can overflow the phone_number field and crash Asterisk when an attacker sends a carefully crafted incoming request packet. The chan_unistim module must be loaded and configured with a valid UNISTIM UDP port that the attacker can reach. The attacker must register as a configured phone MAC, or the deployment must have an equivalent production/autoprovisioning path that allows the client to reach the main page. 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.
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
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
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.
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-111217
NVD
CVE.org
EPSS
GitHub
Exploit-DB