{"id":"CVE-2016-9938","url":"https://www.cyber-defence.io/tools/cve/CVE-2016-9938","generatedAt":"2026-10-28T20:46:55.576Z","title":"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.","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.","published":"2016-12-12T21:59:02.000Z","lastModified":"2026-06-17T00:56:49.000Z","status":"Modified","sourceIdentifier":"cve@mitre.org","cvss":{"version":"3.0","score":5.3,"severity":"MEDIUM","vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"},"cwe":["CWE-285"],"affected":["digium/asterisk","digium/certified asterisk"],"epss":{"score":0.03429,"percentile":0.88868,"date":"2026-10-27","history":[]},"kev":{"listed":false},"exploits":{"count":0,"verified":false,"firstPublished":null,"source":"Exploit-DB (https://gitlab.com/exploit-database/exploitdb)","entries":[]},"verdict":{"level":"low","text":"Lower severity and a low EPSS score (3.43%). Track it; it rarely justifies an emergency change on its own."},"changes":[],"references":[{"url":"http://downloads.asterisk.org/pub/security/AST-2016-009.html","tags":["Mitigation","Vendor Advisory"],"source":"cve@mitre.org"},{"url":"http://www.securityfocus.com/bid/94789","tags":["Third Party Advisory","VDB Entry"],"source":"cve@mitre.org"},{"url":"http://www.securitytracker.com/id/1037408","source":"cve@mitre.org"},{"url":"http://downloads.asterisk.org/pub/security/AST-2016-009.html","tags":["Mitigation","Vendor Advisory"],"source":"af854a3a-2127-422b-91ae-364da2661108"},{"url":"http://www.securityfocus.com/bid/94789","tags":["Third Party Advisory","VDB Entry"],"source":"af854a3a-2127-422b-91ae-364da2661108"},{"url":"http://www.securitytracker.com/id/1037408","source":"af854a3a-2127-422b-91ae-364da2661108"}],"sources":{"nvd":"https://nvd.nist.gov/vuln/detail/CVE-2016-9938","epss":"https://www.first.org/epss/","kev":"https://www.cisa.gov/known-exploited-vulnerabilities-catalog","exploitdb":"https://www.exploit-db.com/"},"licence":"CC BY 4.0 — link back to the CVE Explorer if you publish the results; upstream data remains subject to its own terms."}