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.
2021-02-18T20:15:12.667
2024-11-21T05:56:44.287
Modified
CVSSv3.1: 7.5 (HIGH)
AV:N/AC:L/Au:N/C:N/I:N/A:P
10.0
2.9
Type | Vendor | Product | Version/Range | Vulnerable? |
---|---|---|---|---|
Application | digium | asterisk | < 16.16.1 | Yes |
Application | digium | asterisk | < 17.9.2 | Yes |
Application | digium | asterisk | < 18.2.1 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |
Application | digium | certified_asterisk | 16.8 | Yes |