{"id":"CVE-2016-9938","aliases":["DEBIAN-CVE-2016-9938","EUVD-2016-10725","GHSA-4h4c-qgxg-p3qv","UBUNTU-CVE-2016-9938"],"status":"published","title":"An issue was discovered in Asterisk Open Source 11.x before 11.25.1, 13.x before 13.13.1, and 14...","description":"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.","severity":{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"primary","from":"nvd"},"epss":{"day":"2026-11-07","score":0.03429,"percentile":0.89008,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-285"],"published":"2016-12-12T21:00:00Z","modified":"2026-10-24T10:30:20Z","fixes":[{"ecosystem":"Debian:14","package":"asterisk","fixed_in":["1:13.13.1~dfsg-1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Debian:14","package":"asterisk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:13.13.1~dfsg-1"}]}],"versions":["0.1.11-3","0.1.11-3woody1","1:1.0.5-2","1:1.0.5-4","1:1.0.6-1","1:1.0.6-2","1:1.0.7-1","1:1.0.7.dfsg.1-1","1:1.0.7.dfsg.1-2","1:1.0.7.dfsg.1-2sarge1","1:1.0.7.dfsg.1-2sarge2","1:1.0.7.dfsg.1-2sarge3","1:1.0.7.dfsg.1-2sarge4","1:1.0.7.dfsg.1-2sarge5","1:1.0.7.dfsg.1-2sarge6","1:1.0.9.dfsg-1","1:1.0.9.dfsg-3","1:1.0.9.dfsg-4","1:1.0.9.dfsg-5","1:1.0.9.dfsg-6","1:1.2.0-beta1.dfsg-1","1:1.2.0-beta2.dfsg-1","1:1.2.0-beta2.dfsg-2","1:1.2.0-beta2.dfsg-3","1:1.2.0-rc1.dfsg-1","1:1.2.0-rc2.dfsg-1","1:1.2.0.dfsg-1","1:1.2.0.dfsg-2","1:1.2.0.dfsg-3","1:1.2.0.dfsg-4","1:1.2.0.dfsg-5","1:1.2.0.dfsg-6","1:1.2.1.dfsg-1","1:1.2.1.dfsg-2","1:1.2.1.dfsg-3","1:1.2.10.dfsg-1","1:1.2.10.dfsg-1bpo1","1:1.2.10.dfsg-2","1:1.2.10.dfsg-3","1:1.2.11.dfsg-1","1:1.2.12.1.dfsg-1","1:1.2.13~dfsg-1","1:1.2.13~dfsg-2","1:1.2.13~dfsg-2etch1","1:1.2.13~dfsg-2etch2","1:1.2.13~dfsg-2etch3","1:1.2.13~dfsg-2etch4","1:1.2.14~dfsg-1","1:1.2.14~dfsg-2","1:1.2.14~dfsg-3","1:1.2.14~dfsg-4","1:1.2.15~dfsg-1","1:1.2.16~dfsg-1","1:1.2.17~dfsg-1","1:1.2.4.dfsg-1","1:1.2.4.dfsg-2","1:1.2.4.dfsg-3","1:1.2.4.dfsg-4","1:1.2.4.dfsg-5","1:1.2.4.dfsg-6","1:1.2.4.dfsg-6+b1","1:1.2.4.dfsg-7","1:1.2.7.1.dfsg-1","1:1.2.7.1.dfsg-2","1:1.2.7.1.dfsg-3","1:1.2.9.1.dfsg-1","1:1.4.10~dfsg-1","1:1.4.11~dfsg-1","1:1.4.11~dfsg-2","1:1.4.11~dfsg-3","1:1.4.11~dfsg-4","1:1.4.13~dfsg-1","1:1.4.15~dfsg-1","1:1.4.16.2~dfsg-1","1:1.4.16.2~dfsg-2","1:1.4.17~dfsg-1","1:1.4.17~dfsg-2","1:1.4.18.1~dfsg-1","1:1.4.18~dfsg-1","1:1.4.19.1~dfsg-1","1:1.4.20~dfsg-1","1:1.4.21.1~dfsg-1","1:1.4.21.2~dfsg-1","1:1.4.21.2~dfsg-2","1:1.4.21.2~dfsg-3","1:1.4.21.2~dfsg-3+lenny1","1:1.4.21.2~dfsg-3+lenny2","1:1.4.21.2~dfsg-3+lenny2.1","1:1.4.21.2~dfsg-3+lenny3","1:1.4.21.2~dfsg-3+lenny5","1:1.4.21.2~dfsg-3+lenny6","1:1.4.21.2~dfsg-3.1","1:1.4.2~dfsg-1","1:1.4.2~dfsg-2","1:1.4.2~dfsg-3","1:1.4.2~dfsg-4","1:1.4.2~dfsg-5","1:1.4.3~dfsg-1","1:1.4.4~dfsg-1","1:1.4.4~dfsg-2","1:1.4.4~dfsg-3","1:1.4.5~dfsg-1","1:1.4.6~dfsg-1","1:1.4.8~dfsg-1","1:1.4.8~dfsg-2","1:1.4.9~dfsg-1","1:1.6.1.0~dfsg-1","1:1.6.1.0~dfsg~rc3-1","1:1.6.2.0-1","1:1.6.2.0~dfsg~beta3-1","1:1.6.2.0~dfsg~rc1-1","1:1.6.2.0~rc3-1","1:1.6.2.0~rc3-2","1:1.6.2.0~rc6-1","1:1.6.2.0~rc7-1","1:1.6.2.2-1","1:1.6.2.6-1","1:1.6.2.7-1","1:1.6.2.9-1","1:1.6.2.9-1~bpo50+1","1:1.6.2.9-1~bpo50+2","1:1.6.2.9-1~bpo50+3","1:1.6.2.9-2","1:1.6.2.9-2+squeeze1","1:1.6.2.9-2+squeeze10","1:1.6.2.9-2+squeeze11","1:1.6.2.9-2+squeeze12","1:1.6.2.9-2+squeeze2","1:1.6.2.9-2+squeeze3","1:1.6.2.9-2+squeeze4","1:1.6.2.9-2+squeeze5","1:1.6.2.9-2+squeeze6","1:1.6.2.9-2+squeeze7","1:1.6.2.9-2+squeeze8","1:1.6.2.9-2+squeeze9","1:1.8.10.0~dfsg-1","1:1.8.10.1~dfsg-1","1:1.8.11.1~dfsg-1","1:1.8.13.0~dfsg-1","1:1.8.13.0~dfsg-1~bpo60+1","1:1.8.13.1~dfsg-1","1:1.8.13.1~dfsg-1+powerpcspe1","1:1.8.13.1~dfsg-1~bpo60+1","1:1.8.13.1~dfsg-2","1:1.8.13.1~dfsg-3","1:1.8.3.3-1","1:1.8.4-1","1:1.8.4.2-1","1:1.8.4.3-1","1:1.8.4.4~dfsg-1","1:1.8.4.4~dfsg-2","1:1.8.7.1~dfsg-1","1:1.8.7.1~dfsg-2","1:1.8.7.1~dfsg-3","1:1.8.8.0~dfsg-1","1:1.8.8.2~dfsg-1","1:11.10.0~dfsg-1","1:11.10.0~dfsg-1~bpo70+1","1:11.10.2~dfsg-1","1:11.10.2~dfsg-1~bpo70+1","1:11.11.0~dfsg-1","1:11.11.0~dfsg-1~bpo70+1","1:11.11.0~dfsg-2","1:11.12.0~dfsg-1","1:11.12.0~dfsg-1~bpo70+1","1:11.12.1~dfsg-1","1:11.13.0~dfsg-1","1:11.13.0~dfsg-1~bpo70+1","1:11.13.1~dfsg-1","1:11.13.1~dfsg-2","1:11.13.1~dfsg-2~bpo70+1","1:11.5.1~dfsg-1","1:11.5.1~dfsg-2","1:11.5.1~dfsg1-1","1:11.5.1~dfsg1-1~bpo70+1","1:11.6.0~dfsg-1","1:11.6.0~dfsg-2","1:11.6.0~dfsg-3","1:11.7.0~dfsg-1","1:11.7.0~dfsg-1+e1","1:11.7.0~dfsg-1~bpo70+1","1:11.8.0~dfsg-1","1:11.8.0~dfsg-2","1:11.8.1~dfsg-1","1:11.8.1~dfsg-1~bpo70+1","1:11.9.0~dfsg-1","1:11.9.0~dfsg-2","1:11.9.0~dfsg-2~bpo70+1","1:13.0.0~dfsg-1","1:13.0.0~dfsg-2","1:13.1.0~dfsg-1","1:13.1.0~dfsg-1.1","1:13.10.0~dfsg-1","1:13.11.2~dfsg-1","1:13.12.1~dfsg-1","1:13.12.2~dfsg-1","1:13.12.2~dfsg-2","1:13.7.2~dfsg-1","1:13.8.0~dfsg-1","1:13.8.2~dfsg-1","1:13.9.1~dfsg-1","1:13.9.1~dfsg-2"]},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"asterisk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1:13.1.0~dfsg-1.1ubuntu3","1:13.1.0~dfsg-1.1ubuntu4","1:13.1.0~dfsg-1.1ubuntu4.1","1:13.1.0~dfsg-1.1ubuntu4.1+esm1"]}],"products":[{"vendor":"digium","product":"asterisk"},{"vendor":"digium","product":"certified_asterisk"}],"references":[{"url":"http://downloads.asterisk.org/pub/security/AST-2016-009.html","tags":["x_refsource_CONFIRM","x_transferred","Mitigation","Vendor Advisory","advisory","report"]},{"url":"http://www.securityfocus.com/bid/94789","tags":["vdb-entry","x_refsource_BID","x_transferred","Third Party Advisory","VDB Entry","advisory"]},{"url":"http://www.securitytracker.com/id/1037408","tags":["vdb-entry","x_refsource_SECTRACK","x_transferred","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2016-9938"},{"url":"https://github.com/advisories/GHSA-4h4c-qgxg-p3qv"},{"url":"https://security-tracker.debian.org/tracker/CVE-2016-9938","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2016-9938","tags":["report"]},{"url":"https://issues.asterisk.org/jira/browse/ASTERISK-26433","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2016-9938","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2016-9938","description":"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.","status":"published","published":"2016-12-12T21:00:00Z","modified":"2024-08-06T03:07:31.471Z","updated_at":"2026-11-02T14:33:31.764001Z"}],"euvd":[{"id":"EUVD-2016-10725","description":"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.","status":"published","published":"2016-12-12T21:00:00Z","modified":"2024-08-06T03:07:31Z","updated_at":"2026-11-03T02:22:25.833438Z"}],"ghsa":[{"id":"GHSA-4h4c-qgxg-p3qv","title":"An issue was discovered in Asterisk Open Source 11.x before 11.25.1, 13.x before 13.13.1, and 14...","description":"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.","status":"published","published":"2022-05-17T02:24:51Z","modified":"2023-01-27T05:04:26Z","cvss":[{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-285"],"updated_at":"2026-11-02T14:42:27.785329Z"}],"nvd":[{"id":"CVE-2016-9938","description":"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.","status":"published","published":"2016-12-12T21:59:01.617Z","modified":"2026-06-17T00:56:48.68Z","cvss":[{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"primary"},{"version":"2.0","score":5,"vector":"AV:N/AC:L/Au:N/C:N/I:P/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-285"],"updated_at":"2026-11-02T14:03:32.79141Z"}],"osv":[{"id":"CVE-2016-9938","description":"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.","status":"published","published":"2016-12-12T21:59:01.617Z","modified":"2026-10-24T10:30:20.123304936Z","cvss":[{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T15:44:03.472693Z"},{"id":"DEBIAN-CVE-2016-9938","description":"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.","status":"published","published":"2016-12-12T21:59:01.617Z","modified":"2026-09-22T07:02:50.688989073Z","cvss":[{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T15:45:28.207321Z"},{"id":"UBUNTU-CVE-2016-9938","description":"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.","status":"published","published":"2016-12-12T21:59:00Z","modified":"2026-04-22T11:08:00.508002Z","cvss":[{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T15:54:13.356796Z"}]}}