EUVD-2026-111401Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessPlace/trigger call to Asterisk
-
DeliveryInject SQL payload into caller-controlled field
-
ExploitDialplan passes it to CELGenUserEvent eventtype
-
ExecutionBackend builds unescaped INSERT statement
-
ImpactArbitrary SQL executes on CEL database
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Parameterized queries, prepared statements
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Persistence The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires all of the following non-default conditions stated in the advisory: (1) the cel_pgsql or cel_tds CEL backend module must be loaded and configured against a PostgreSQL or TDS/MSSQL database; (2) the administrator must call the CELGenUserEvent dialplan application; and (3) the administrator must pass untrusted/caller-influenced data into it without validating that only valid data reaches the application. The specifically injectable sink is the CEL eventtype column. The strong limiting factor is that none of these are default - an Asterisk install without these CEL backends, or one whose dialplan never feeds unsanitized caller data to CELGenUserEvent, is not exposed. Updating to the fixed releases is the complete fix, as the patch adds output escaping in both backends. |
| Impact | This is a CWE-89 SQL injection (CVSS 4.0 base 7.0, High) in Asterisk's CEL database backends cel_pgsql and cel_tds, confirmed via the vendor GHSA advisory and fixing commits. The signals are mixed and lean toward a conditional, administrator-dependent risk rather than a drop-everything emergency: the vuln.today decision label is 'this_week' (not act_now/emergency), no EPSS score was supplied, the CVE is not in CISA KEV, and no public exploit or PoC reference is present in the input. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) shows an unauthenticated network-reachable path, but AT:P (attack requirements present) and the description's explicit preconditions make clear this is not a default-configuration flaw - it fires only where the pgsql/tds CEL backend is loaded and the administrator calls CELGenUserEvent with unsanitized data. Technical impact is real but bounded: the CVSS maps impact to the subsequent system (the CEL database) as SC:H/SI:L/SA:L, with the Asterisk process itself rated VC:N/VI:N/VA:L, i.e. arbitrary SQL against the logging database rather than direct telephony-host compromise. Net: a genuine, patchable priority for operators running these specific CEL backends with caller-influenced CELGenUserEvent input, but low real-world risk for the majority of Asterisk deployments that do not meet all three preconditions. |
| Exploit ScenarioDerived | An Asterisk administrator loads cel_pgsql (PostgreSQL) or cel_tds (TDS/MSSQL) and calls CELGenUserEvent in the dialplan using a value derived from untrusted caller input without validating it. A remote caller supplies a crafted value that lands in the CEL eventtype column; because the backend built the INSERT without escaping that field, the attacker's input is executed as arbitrary SQL against the CEL database. No public exploit or PoC reference is present in the input. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
SQL injection in Asterisk's Channel Event Log database backends cel_pgsql and cel_tds allows attacker-influenced data placed in the CEL eventtype column to be executed as arbitrary SQL against the connected PostgreSQL or TDS/MSSQL database. Exposure is limited to deployments that load and configure one of those CEL backends, invoke the CELGenUserEvent dialplan application, and pass it unvalidated data that a caller or other untrusted source can influence; default installations without these backends and dialplans are not affected. Fixed releases are Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11 / 22.8-cert3; no public exploit 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; the release tags are linked from the GHSA advisory (https://github.com/asterisk/asterisk/security/advisories/GHSA-ph27-3m5q-mj5m) and the fixes are in the referenced commits (for example 046a8b0b50623d80926c1adc2eca1c9c17e258ed for cel_pgsql and the accompanying cel_tds commit). Updating is the complete fix because escaping is now applied in both backends. Where upgrading cannot be done immediately, reduce exposure by not loading cel_pgsql/cel_tds (noload in modules.conf) on systems that do not need CEL database logging, by removing or restricting CELGenUserEvent calls so that only static, validated values are passed to it, and by granting the CEL database account only the INSERT privileges it needs on the CEL table so injected statements have minimal effect. Each of these trades away functionality or logging fidelity and does not substitute for the patched releases.
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 Channel Event Log (CEL) subsystem records call events to a database through pluggable backends, two of which are cel_pgsql (libpq/PostgreSQL) and cel_tds (FreeTDS/TDS, typically Microsoft SQL Server). The CELGenUserEvent dialplan application emits an AST_CEL_USER_DEFINED event whose user-defined name is written into the CEL eventtype column. In the vulnerable code, cel_pgsql appended the raw event name into the INSERT statement via ast_str_append, and cel_tds passed record.user_defined_name directly into its query, so a value containing SQL metacharacters could break out of the literal and alter the statement. This is CWE-89: SQL command construction from unescaped external input rather than parameterized statements or connection-aware escaping. The upstream fix adds PQescapeStringConn-based escaping with a dynamically sized escape buffer in cel_pgsql and applies anti_injection() to the eventtype value in cel_tds, so injected characters are neutralized before the query is built. Per the CVSS 4.0 vector (PR:N) and the assessed CVSS 3.1 vector (PR:N), no authentication is required; exploitation nonetheless depends entirely on the non-default preconditions that the backend is loaded and that the dialplan feeds untrusted data to CELGenUserEvent.
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:N/UI:N/VC:N/VI:N/VA:L/SC:H/SI:L/SA:L
A remote unauthenticated caller can reach the sink (AV:N/PR:N), but the backend/dialplan preconditions make it AC:H; injected SQL crosses into the CEL database (S:C) giving high DB confidentiality with limited integrity/availability impact.
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, the PostgreSQL and TDS/MSSQL Channel Event Log backends cel_pgsql and cel_tds may permit arbitrary SQL execution when untrusted data is set in the CEL eventtype column by the CELGenUserEvent dialplan application. The cel_pgsql or cel_tds backend must be loaded and configured, and the administrator must call CELGenUserEvent in the dialplan without ensuring that only valid data is passed to the application. 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-89 (Improper Neutralization of Special Elements used in an SQL Command).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A high-severity SQL injection vulnerability has been identified in certain configurations of Asterisk, the open-source communications framework. Organizations using the Channel Event Log with PostgreSQL or MSSQL backends and the CELGenUserEvent dialplan application could be exposed to database compromise via untrusted caller input. While no public exploit exists, the potential for data breach or service disruption warrants immediate remediation.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
VulDB
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
SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.
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