Digium Certified Asterisk 11.0.0
Approved changes feed: RSS · Atom
cpe:2.3:a:digium:certified_asterisk:11.0.0:*:*:*:*:*:*:*
part: a version: 11.0.0 update: *
| Vendor | Digium (05ad29b7-5b41-56d5-935d-a279ab7f14bc) |
|---|---|
| Product | Certified Asterisk (28acf01c-dbb1-5902-9616-b4c28682b220) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from NVD CPE 2.0 feed |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
pkg:asterisk/telephony/certified-asterisk |
purl2cpe | 2026-06-01 10:15:41.939656 |
pkg:github/asterisk/asterisk |
purl2cpe | 2026-06-01 10:15:41.939658 |
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2019-13161 |
vulnerable | 2026-06-08 05:12:41.079197 |
Details available
An issue was discovered in Asterisk Open Source through 13.27.0, 14.x and 15.x through 15.7.2, and 16.x through 16.4.0, and Certified Asterisk through 13.21-cert3. A pointer dereference in chan_sip while handling SDP negotiation allows an attacker to crash Asterisk when handling an SDP answer to an outgoing T.38 re-invite. To exploit this vulnerability an attacker must cause the chan_sip module to send a T.38 re-invite request to them. Upon receipt, the attacker must send an SDP answer containing both a T.38 UDPTL stream and another media stream containing only a codec (which is not permitted according to the chan_sip configuration).
Published: 2019-07-12T19:24:37.000Z
Updated: 2024-08-04T23:41:10.494Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2016-9938 |
vulnerable | 2026-06-08 05:08:25.061561 |
Details available
An issue was discovered in Asterisk Open Source 11.x before 11.25.1, 13.x before 13.13.1, and 14.x before 14.2.1 and Certified Asterisk 11.x before 11.6-cert16 and 13.x before 13.8-cert4. The chan_sip channel driver has a liberal definition for whitespace when attempting to strip the content between a SIP header name and a colon character. Rather than following RFC 3261 and stripping only spaces and horizontal tabs, Asterisk treats any non-printable ASCII character as if it were whitespace. This means that headers such as Contact\x01: will be seen as a valid Contact header. This mostly does not pose a problem until Asterisk is placed in tandem with an authenticating SIP proxy. In such a case, a crafty combination of valid and invalid To headers can cause a proxy to allow an INVITE request into Asterisk without authentication since it believes the request is an in-dialog request. However, because of the bug described above, the request will look like an out-of-dialog request to Asterisk. Asterisk will then process the request as a new call. The result is that Asterisk can process calls from unvetted sources without any authentication. If you do not use a proxy for authentication, then this issue does not affect you. If your proxy is dialog-aware (meaning that the proxy keeps track of what dialogs are currently valid), then this issue does not affect you. If you use chan_pjsip instead of chan_sip, then this issue does not affect you.
Published: 2016-12-12T21:00:00.000Z
Updated: 2024-08-06T03:07:31.471Z |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.