Product:

Asterisk

(Digium)
Repositories

Unknown:

This might be proprietary software.

#Vulnerabilities 114
Date Id Summary Products Score Patch Annotated
2021-02-19 CVE-2021-26713 A stack-based buffer overflow in res_rtp_asterisk.c in Sangoma Asterisk before 16.16.1, 17.x before 17.9.2, and 18.x before 18.2.1 and Certified Asterisk before 16.8-cert6 allows an authenticated WebRTC client to cause an Asterisk crash by sending multiple hold/unhold requests in quick succession. This is caused by a signedness comparison mismatch. Asterisk, Certified_asterisk 6.5
2021-02-18 CVE-2021-26906 An issue was discovered in res_pjsip_session.c in Digium Asterisk through 13.38.1; 14.x, 15.x, and 16.x through 16.16.0; 17.x through 17.9.1; and 18.x through 18.2.0, and Certified Asterisk through 16.8-cert5. An SDP negotiation vulnerability in PJSIP allows a remote server to potentially crash Asterisk by sending specific SIP responses that cause an SDP negotiation failure. Asterisk, Certified_asterisk 5.9
2021-02-18 CVE-2021-26712 Incorrect access controls in res_srtp.c in Sangoma Asterisk 13.38.1, 16.16.0, 17.9.1, and 18.2.0 and Certified Asterisk 16.8-cert5 allow a remote unauthenticated attacker to prematurely terminate secure calls by replaying SRTP packets. Asterisk, Certified_asterisk 7.5
2021-02-18 CVE-2021-26717 An issue was discovered in Sangoma Asterisk 16.x before 16.16.1, 17.x before 17.9.2, and 18.x before 18.2.1 and Certified Asterisk before 16.8-cert6. When re-negotiating for T.38, if the initial remote response was delayed just enough, Asterisk would send both audio and T.38 in the SDP. If this happened, and the remote responded with a declined T.38 stream, then Asterisk would crash. Asterisk, Certified_asterisk 7.5
2021-02-18 CVE-2020-35776 A buffer overflow in res_pjsip_diversion.c in Sangoma Asterisk versions 13.38.1, 16.15.1, 17.9.1, and 18.1.1 allows remote attacker to crash Asterisk by deliberately misusing SIP 181 responses. Asterisk 6.5
2021-01-29 CVE-2020-35652 An issue was discovered in res_pjsip_diversion.c in Sangoma Asterisk before 13.38.0, 14.x through 16.x before 16.15.0, 17.x before 17.9.0, and 18.x before 18.1.0. A crash can occur when a SIP message is received with a History-Info header that contains a tel-uri, or when a SIP 181 response is received that contains a tel-uri in the Diversion header. Asterisk 6.5
2012-09-18 CVE-2012-1183 Stack-based buffer overflow in the milliwatt_generate function in the Miliwatt application in Asterisk 1.4.x before 1.4.44, 1.6.x before 1.6.2.23, 1.8.x before 1.8.10.1, and 10.x before 10.2.1, when the o option is used and the internal_timing option is off, allows remote attackers to cause a denial of service (application crash) via a large number of samples in an audio packet. Debian_linux, Asterisk N/A
2011-01-20 CVE-2011-0495 Stack-based buffer overflow in the ast_uri_encode function in main/utils.c in Asterisk Open Source before 1.4.38.1, 1.4.39.1, 1.6.1.21, 1.6.2.15.1, 1.6.2.16.1, 1.8.1.2, 1.8.2.; and Business Edition before C.3.6.2; when running in pedantic mode allows remote authenticated users to execute arbitrary code via crafted caller ID data in vectors involving the (1) SIP channel driver, (2) URIENCODE dialplan function, or (3) AGI dialplan function. Debian_linux, Asterisk, Asterisknow, S800i_firmware, Fedora N/A
2017-12-02 CVE-2017-17090 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 older, and Certified Asterisk 13.13-cert7 and older. If the chan_skinny (aka SCCP protocol) channel driver is flooded with certain requests, it can cause the asterisk process to use excessive amounts of virtual memory, eventually causing asterisk to stop processing requests of any kind. Asterisk, Certified_asterisk 7.5
2017-11-09 CVE-2017-16672 An issue was discovered in Asterisk Open Source 13 before 13.18.1, 14 before 14.7.1, and 15 before 15.1.1 and Certified Asterisk 13.13 before 13.13-cert7. A memory leak occurs when an Asterisk pjsip session object is created and that call gets rejected before the session itself is fully established. When this happens the session object never gets destroyed. Eventually Asterisk can run out of memory and crash. Asterisk, Certified_asterisk 5.9