{
    "CVE_data_meta": {
        "ASSIGNER": "cve@mitre.org",
        "ID": "CVE-2016-9938",
        "STATE": "PUBLIC"
    },
    "affects": {
        "vendor": {
            "vendor_data": [
                {
                    "product": {
                        "product_data": [
                            {
                                "product_name": "n/a",
                                "version": {
                                    "version_data": [
                                        {
                                            "version_value": "n/a"
                                        }
                                    ]
                                }
                            }
                        ]
                    },
                    "vendor_name": "n/a"
                }
            ]
        }
    },
    "data_format": "MITRE",
    "data_type": "CVE",
    "data_version": "4.0",
    "description": {
        "description_data": [
            {
                "lang": "eng",
                "value": "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."
            }
        ]
    },
    "problemtype": {
        "problemtype_data": [
            {
                "description": [
                    {
                        "lang": "eng",
                        "value": "n/a"
                    }
                ]
            }
        ]
    },
    "references": {
        "reference_data": [
            {
                "name": "http://downloads.asterisk.org/pub/security/AST-2016-009.html",
                "refsource": "CONFIRM",
                "url": "http://downloads.asterisk.org/pub/security/AST-2016-009.html"
            },
            {
                "name": "94789",
                "refsource": "BID",
                "url": "http://www.securityfocus.com/bid/94789"
            },
            {
                "name": "1037408",
                "refsource": "SECTRACK",
                "url": "http://www.securitytracker.com/id/1037408"
            }
        ]
    }
}