EUVD-2026-111107Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to Asterisk with SIP credentials
-
ExploitSend crafted oversized T.140 RED text packets
-
ExecutionOverflow heap buffer in RED payload generation
-
ImpactCrash service or potentially execute code
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Heap buffer bounds checking
MITRE ATT&CK
1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a deployment running the legacy chan_sip channel driver that is both installed and configured, with its textsupport option explicitly set to enabled (it defaults to 'no'), and an attacker who is already authenticated (PR:L). Because chan_sip was deprecated in Asterisk 20 and completely removed in all later versions, only Asterisk 20.x and the Certified branches still carrying that driver are realistically affected. Key limiting factors: valid authentication is needed, the required textsupport setting is non-default, and the vulnerable driver is deprecated/absent in current releases - together these sharply narrow the exploitable population below what AV:N alone implies. |
| Impact | This is a low-priority issue despite the CWE-122 heap overflow and theoretical RCE. The input CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L) scores only 2.3: network-reachable but requiring an authenticated attacker (PR:L) and specific attack requirements (AT:P), with only low confidentiality/integrity/availability impact. No EPSS score, no CISA KEV listing, and no public exploit were provided; the vuln.today Decision label is 'monitor'. The references are the vendor GHSA advisory and fix commits - not a working proof-of-concept. One signal conflicts: the advisory describes 'potential remote code execution,' which would normally imply high impact, yet the vendor-assigned vulnerable-system impacts are all Low (VC:L/VI:L/VA:L) and the patch merely truncates oversized payloads to 255 bytes, suggesting the realistic outcome is a crash/limited corruption rather than reliable code execution - treat the RCE claim as unverified. The practical risk is further gated because exploitation needs the deprecated chan_sip driver with a non-default option enabled. Net: a real but low-urgency bug suitable for scheduled patching, not emergency response. |
| Exploit ScenarioDerived | An authenticated SIP user on an Asterisk server that still runs the deprecated chan_sip driver with the non-default textsupport option enabled sends carefully crafted T.140 RED text packets whose payload exceeds the 255-byte RED length field, overflowing the heap buffer and crashing Asterisk or, per the vendor, potentially achieving remote code execution. No public exploit code was identified; only the advisory and fix commits exist. Attack complexity is low once the prerequisite authentication and non-default configuration are present. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Heap buffer overflow in Asterisk's T.140 RED handling (res_rtp_asterisk.c) lets an authenticated attacker crash the PBX or potentially execute code, but only in deployments where the legacy chan_sip channel driver is installed and configured with its non-default textsupport option enabled. Exposure is sharply narrow because chan_sip was deprecated in Asterisk 20 and removed from all later release tracks, so only Asterisk 20.x and the Certified 20.7 and 22.8 branches are realistically exploitable; the trigger requires a valid authenticated session (PR:L) plus a non-default configuration. No public exploit code or CISA KEV entry is associated with this issue at time of analysis, and the reported CVSS 4.0 score is 2.3 with a 'monitor' priority label, consistent with a low-priority defect rather than an actively exploited one.
RemediationAI
Vendor-released patches fix the overflow in Asterisk 20.20.1, 21.12.3, 22.10.1 and 23.4.1, and in Certified Asterisk 20.7-cert11 and 22.8-cert3; upgrade to the fix for your branch (the commit diffs referenced in GHSA-vfhr-r9x9-c687 show the added UCHAR_MAX bounds checks in res_rtp_asterisk.c). Because the advisory states the flaw only triggers when the chan_sip channel driver is installed and configured with textsupport enabled, deployments that cannot upgrade immediately can eliminate the exposure by ensuring textsupport stays at its default 'no' or by unloading/not configuring chan_sip and migrating endpoints to chan_pjsip; the trade-off is that disabling textsupport removes T.140 real-time text over that channel, which impacts text-telephony accessibility users, and chan_sip itself is deprecated with no future fixes. Restricting who can establish authenticated SIP sessions on chan_sip-facing interfaces further reduces reachability, at the cost of tightening legitimate client access.
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 classic heap-based buffer overflow (CWE-122) inside res_rtp_asterisk.c, the RTP engine used for real-time text (T.140 over RTP with RFC 2198 RED redundancy). Asterisk buffers outgoing T.140 text frames until a command is encountered, accumulating them in red->t140; the per-block length array red->len is an array of unsigned chars, which implicitly caps a RED generation payload at 255 bytes (UCHAR_MAX). When a crafted stream pushes the accumulated primary payload past that ceiling, the write overruns the heap allocation, giving memory corruption that can be turned into a crash or, with more effort, code execution. The upstream fix (commits referenced from the GHSA) adds a UCHAR_MAX check in red_t140_to_red() that truncates oversized frames with a warning, and in rtp_red_buffer() computes space_available, flushes the saved frame via ast_rtp_write() before attempting to append an oversized frame, and discards the frame if it still will not fit. The attack surface is bounded by the deprecated chan_sip channel driver: the SIP channel must exist and be configured, and textsupport (default 'no') must be explicitly enabled, which is why the assigned CVSS 4.0 vector carries AT:P and PR:L (score 2.3) and our independent assessment maps it to AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L.
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:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Authenticated SIP user (PR:L) over the network; AC:H reflects the required non-default chan_sip textsupport configuration; low impact mirrors the bounded, truncated overflow with unproven RCE.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
Asterisk is an open source private branch exchange and telephony toolkit. In affected deployments, an authenticated attacker may cause a T.140 RED heap buffer overflow using carefully crafted packets, potentially allowing remote code execution or causing Asterisk to crash. The chan_sip channel driver must be installed and configured, and its textsupport option must be enabled; textsupport defaults to no. The chan_sip driver was deprecated in Asterisk 20 and completely removed in all later versions. Repository comparisons verify patch containment in Asterisk 20.20.1, 21.12.3, 22.10.1 and 23.4.1, and Certified Asterisk 20.7-cert11 and 22.8-cert3. The affected release-track scope remains unresolved: structured metadata includes later release tracks even though the advisory says the required chan_sip driver was removed there.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
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.
A heap overflow occurs when a program writes data beyond the bounds of a buffer allocated in the heap memory region.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
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
Exploit-DB