Skip to main content
No exploitation reportedFix available

CVE-2017-14099

No exploitation reported by the sources we read.

  • Published2017-09-02
  • WeaknessCWE-200

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

Description

In res/res_rtp_asterisk.c in Asterisk 11.x before 11.25.2, 13.x before 13.17.1, and 14.x before 14.6.1 and Certified Asterisk 11.x before 11.6-cert17 and 13.x before 13.13-cert5, unauthorized data disclosure (media takeover in the RTP stack) is possible with careful timing by an attacker. The "strictrtp" option in rtp.conf enables a feature of the RTP stack that learns the source address of media for a session and drops any packets that do not originate from the expected address. This option is enabled by default in Asterisk 11 and above. The "nat" and "rtp_symmetric" options (for chan_sip and chan_pjsip, respectively) enable symmetric RTP support in the RTP stack. This uses the source address of incoming media as the target address of any sent media. This option is not enabled by default, but is commonly enabled to handle devices behind NAT. A change was made to the strict RTP support in the RTP stack to better tolerate late media when a reinvite occurs. When combined with the symmetric RTP support, this introduced an avenue where media could be hijacked. Instead of only learning a new address when expected, the new code allowed a new source address to be learned at all times. If a flood of RTP traffic was received, the strict RTP support would allow the new address to provide media, and (with symmetric RTP enabled) outgoing traffic would be sent to this new address, allowing the media to be hijacked. Provided the attacker continued to send traffic, they would continue to receive traffic as well.

Timeline

dates in UTC
  1. 2017-09-0216:29CVE publishedNVD

Observed activity

isMalicious corpus · updated 2026-10-23 21:37 UTC
Indicators tagged with this CVE, per day0 indicators over 7 days
Block these indicators
  • Firewall list (EDL, text): https://api.ismalicious.com/edl/cve/CVE-2017-14099?format=txt
  • CSV export: https://api.ismalicious.com/edl/cve/CVE-2017-14099?format=csv
  • TAXII collection of exploited CVEs
  • The EDL and CSV take an API key on the Pro plan.

Versions per branch

NVD
Digium asterisk
BranchAffectedFixed in
13.0= 13.0.0no fix published
13.0= 13.0.1no fix published
13.0= 13.0.2no fix published
13.1= 13.1.0no fix published
13.1= 13.1.1no fix published
13.2= 13.2.0no fix published
13.2= 13.2.1no fix published
13.3= 13.3.0no fix published
13.3= 13.3.2no fix published
13.4= 13.4.0no fix published
13.5= 13.5.0no fix published
13.6= 13.6.0no fix published
Digium certified asterisk
BranchAffectedFixed in
11.6= 11.6no fix published
13.13= 13.13no fix published

as publishedRanges as NVD and OSV publish them; a distribution’s build can be fixed under an older number.

Fix

Advisories and patches

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof-of-concept repositories
none listed
PoC-in-GitHub

Sources

  • NVDCVSS 3.07.5read 2026-10-23
  • NVDCVSS 2.05read 2026-10-23
  • NVDweakness (CWE)CWE-200read 2026-10-23
  • FIRST EPSSEPSS score4.3 %2026-10-22

Technical details

CVSS v3 Vector
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Published
2017-09-02
Last Modified
2026-06-17
NVD status
Modified

Frequently asked questions

What is CVE-2017-14099?

In res/res_rtp_asterisk.c in Asterisk 11.x before 11.25.2, 13.x before 13.17.1, and 14.x before 14.6.1 and Certified Asterisk 11.x before 11.6-cert17 and 13.x before 13.13-cert5, unauthorized data disclosure (media takeover in the RTP stack) is possible with careful timing by an attacker. The "strictrtp" option in rtp.conf enables a feature of the RTP stack that learns the source address of media for a session and drops any packets that do not originate from the expected address. This option is enabled by default in Asterisk 11 and above. The "nat" and "rtp_symmetric" options (for chan_sip and chan_pjsip, respectively) enable symmetric RTP support in the RTP stack. This uses the source address of incoming media as the target address of any sent media. This option is not enabled by default, but is commonly enabled to handle devices behind NAT. A change was made to the strict RTP support in the RTP stack to better tolerate late media when a reinvite occurs. When combined with the symmetric RTP support, this introduced an avenue where media could be hijacked. Instead of only learning a new address when expected, the new code allowed a new source address to be learned at all times. If a flood of RTP traffic was received, the strict RTP support would allow the new address to provide media, and (with symmetric RTP enabled) outgoing traffic would be sent to this new address, allowing the media to be hijacked. Provided the attacker continued to send traffic, they would continue to receive traffic as well.

Is CVE-2017-14099 actively exploited?

Active exploitation of CVE-2017-14099 has not been confirmed. Its EPSS score was 4.3% on 2026-10-22, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2017-14099?

CVE-2017-14099 has a CVSS v3 base score of 7.5 (HIGH severity), with vector string CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N.

Hear about the next vulnerability in your software

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, October 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database