Approved changes feed: RSS · Atom

cpe:2.3:a:digium:asterisk:11.8.0:*:*:*:*:*:*:*

part: a version: 11.8.0 update: *

VendorDigium (05ad29b7-5b41-56d5-935d-a279ab7f14bc)
ProductAsterisk (a75a6886-b0b4-5160-9cfa-f749f3c86956)
Edition*
Language*
Software edition*
Target software*
Target hardware*
Other*
NotesImported from NVD CPE 2.0 feed

PURL mappings

PURLSourceLast updated
pkg:github/asterisk/asterisk purl2cpe 2026-06-01 10:15:41.769996

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
CVE:CVE-2016-9938 vulnerable 2026-06-08 05:08:25.023533 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
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2016-7551 vulnerable 2026-06-08 05:08:13.007851 Details available
chain_sip in Asterisk Open Source 11.x before 11.23.1 and 13.x 13.11.1 and Certified Asterisk 11.6 before 11.6-cert15 and 13.8 before 13.8-cert3 allows remote attackers to cause a denial of service (port exhaustion).
Published: 2017-04-17T16:00:00.000Z
Updated: 2024-08-06T02:04:55.787Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2014-9374 vulnerable 2026-06-08 05:06:11.540646 Details available
Double free vulnerability in the WebSocket Server (res_http_websocket module) in Asterisk Open Source 11.x before 11.14.2, 12.x before 12.7.2, and 13.x before 13.0.2 and Certified Asterisk 11.6 before 11.6-cert9 allows remote attackers to cause a denial of service (crash) by sending a zero length frame after a non-zero length frame.
Published: 2014-12-12T15:00:00.000Z
Updated: 2024-08-06T13:40:25.047Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2014-6610 vulnerable 2026-06-08 05:05:58.047705 Details available
Asterisk Open Source 11.x before 11.12.1 and 12.x before 12.5.1 and Certified Asterisk 11.6 before 11.6-cert6, when using the res_fax_spandsp module, allows remote authenticated users to cause a denial of service (crash) via an out of call message, which is not properly handled in the ReceiveFax dialplan application.
Published: 2014-11-26T15:00:00.000Z
Updated: 2024-08-06T12:24:34.306Z
Reference links
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.