CVE-2017-17090: Asterisk chan_skinny driver memory exhaustion denial of service

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 18 September 2026. Confidence: high.

high priorityRemote unauthenticated denial of service with a public exploit and very high EPSS, though no KEV listing or code execution impact.

What it is

The chan_skinny (SCCP) channel driver in Asterisk Open Source and Certified Asterisk fails to properly limit resource use when flooded with certain requests. A remote unauthenticated attacker can drive the asterisk process to consume excessive virtual memory until it stops processing requests of any kind.

Impact

An attacker can cause a full denial of service on the Asterisk service, halting call processing and all other request handling. No confidentiality or integrity impact is described; the effect is availability loss.

Attack surface

Reachable over the network via the SCCP/chan_skinny protocol listener; the CVSS vector indicates no privileges and no user interaction required. Any host able to send requests to the exposed chan_skinny port can trigger it.

Exploitation

Not listed in CISA KEV, but EPSS is very high (0.815, ~99.6th percentile) and a public Exploit-DB entry exists, indicating exploit code is available and exploitation is plausible.

What to do

• Upgrade Asterisk to a release newer than 13.18.2, 14.7.2, 15.1.2, or Certified Asterisk 13.13-cert7 per the vendor advisory AST-2017-013.
• If chan_skinny/SCCP is not required, disable or unload the chan_skinny module.
• Restrict network access to the SCCP listener with firewall rules or ACLs so only trusted phone endpoints can reach it.
• Apply the Debian security updates (DSA-4076) if running the packaged Asterisk.
• Monitor and cap process memory for asterisk to limit the blast radius of a flood.

Detection

• Alert on abnormal virtual memory growth or OOM events for the asterisk process.
• Monitor for high volumes of SCCP/chan_skinny traffic from single sources or unexpected hosts.
• Watch for Asterisk becoming unresponsive to requests and correlate with SCCP connection spikes.
• Review firewall and netflow logs for connections to the SCCP port from untrusted networks.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.