CVE-2017-14098

Exploitation likely. EPSS gives it a 50% chance of exploitation in the next 30 days. A vendor fix is available.

CVSS 3.07.5High EPSS percentile99th50% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known FixVendor fixNo build named by the sources

Published 2017-09-02Updated 2026-05-13Sources: CVE.org, NVD

NVD CVE.org

What to do

The vendor has published a fix. Version details are below where the sources state them.

Steps

Written by AI from the record

Check your Asterisk version (e.g., via your server’s package info or Asterisk CLI) and confirm whether it falls in 13.x before 13.17.1 or 14.x before 14.6.1.
If you are on affected versions, upgrade Asterisk to 13.17.1 or later, or upgrade to 14.6.1 or later.
After upgrading, run a quick call/SIP test and watch Asterisk stability (no crashes) during normal call handling.
If you can’t upgrade right away, restrict SIP exposure (limit who can reach your SIP endpoints) and monitor for repeated crashes/restarts, then schedule the upgrade as soon as possible.

Vendor advisory Some work to apply

Check it yourselfA free OpenVAS check exists for this CVE. Run it against your hosts.Is your organisation exposed?Request an assessment to establish which checks fit your systems.

What it is

From the CVE record

In the pjsip channel driver (res_pjsip) in Asterisk 13.x before 13.17.1 and 14.x before 14.6.1, a carefully crafted tel URI in a From, To, or Contact header could cause Asterisk to crash.

In plain language

Written by AI from the record

If you run Asterisk, a specially crafted phone-number style address (a tel URI) in common call headers could make your phone system crash—this is a high-impact availability issue, so you should check for the patched Asterisk versions.

Asterisk res_pjsip (PJSIP channel driver) contains a parsing flaw where a crafted tel URI placed in SIP From/To/Contact headers can trigger an Asterisk crash (denial of service) in Asterisk 13.x before 13.17.1 and 14.x before 14.6.1.

If you're affected

Phone service outage
Dropped calls and failed calls
Emergency calling disruption
Operational disruption

What is it

Think of Asterisk as the “phone switchboard” for your business. This bug is like a trapdoor: if someone sends a specially formed phone-number address in certain call header fields, Asterisk can fall over and stop handling calls until it recovers or restarts. For a small business, that usually shows up as sudden call failures or a temporary outage.

Who is affected

This matters if you run Asterisk and have the res_pjsip (PJSIP channel driver) enabled for SIP calling. You’re most at risk when an attacker can reach your SIP endpoints and send SIP calls/requests that populate the SIP From/To/Contact headers—because the outcome is a crash, not just a bad call. This is only a risk when the vulnerable code path is reachable (i.e., the relevant SIP traffic reaches your Asterisk instance).

How urgent is it

Treat this as AMBER because it can take your phone system down (availability impact) and the likelihood of it being used in real attacks is rising. Even though there’s no public exploit code on record and it’s not listed in CISA KEV, the crash impact is serious enough to prioritize upgrading.

What to do — in detail

Confirm exposure
- Identify the exact Asterisk version you run.
- Asterisk is affected if you are on:
  - 13.x < 13.17.1, or
  - 14.x < 14.6.1.
- If you have multiple Asterisk installations, check each one.
Upgrade to the fixed versions
- Upgrade Asterisk to:
  - 13.17.1 or later (for the 13.x line), or
  - 14.6.1 or later (for the 14.x line).
- The vendor fix is referenced by Asterisk security update AST-2017-007, and additional package/report links are provided in the security/bug tracker materials.
Post-upgrade verification
- Confirm Asterisk is running normally after the upgrade.
- Perform a short round of real or test SIP calling (both inbound and outbound as applicable for your setup).
- Monitor for stability issues and any crash/restart behavior during typical usage.
Temporary workaround if upgrading is delayed
- Reduce exposure of your SIP services so fewer unknown callers can reach Asterisk.
- Concretely: limit SIP access using network/firewall rules to only trusted sources (providers, gateways, extensions) so hostile SIP traffic is less likely to reach the headers that trigger the crash.
- Keep an eye on logs/restart events so you can detect attempted crashes quickly.
What to monitor going forward
- Asterisk crash logs and service restarts.
- SIP traffic patterns (spikes from unusual sources) that correlate with instability.

Note: KEV is not listed for this issue, and there is no public exploit code on record, but the crash impact makes version upgrade the primary remediation.

Technical context

Severity/impact: This is a denial-of-service issue (A:H availability impact), where Asterisk can crash. The weakness is identified as CWE-20 (improper input validation / mishandling of crafted inputs).

Affected component and mechanism: In the pjsip channel driver (res_pjsip) in Asterisk 13.x before 13.17.1 and 14.x before 14.6.1, a carefully crafted tel URI placed inside SIP header fields (From, To, or Contact) can trigger the crash.

Exploitation status: No KEV listing from CISA for this CVE and no public exploit code on record. However, press attention is rising and predicted attack likelihood is rising; per the assessment, treat this as AMBER rather than low priority.

What KEV means here: KEV listing would indicate confirmed exploitation in the wild; since it is not listed, confirmed exploitation is not established by that signal for this CVE.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS99th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

50% chance of exploitation activity in the next 30 days, which ranks it in the 99th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

24 events over 3308 days, from the signal feeds we watch.

2026-09-23EPSS band changemoderate → highepss band change
2026-09-21EPSS band changehigh → moderateepss band change
2026-09-06EPSS band changemoderate → highepss band change
2026-09-05EPSS band changehigh → moderateepss band change
2026-08-31EPSS band changemoderate → highepss band change
2026-08-29EPSS band changehigh → moderate

Affected products

digiumcommercial · USaka asterisk
- asteriskCommunications

And 1 more affected product. See all after sign-in

Technical detail

CVSS 3.0 vector

Open in the CVSS calculator

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Scored 7.5 by NVD.

How it is reached

Attack Vector NetworkExploitable remotely over the network without any special conditions
Attack Complexity LowNo special conditions — the attack can be reliably reproduced
Privileges Required NoneNo authentication required — anyone can exploit this
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

Confidentiality NoneNo confidentiality impact
Integrity NoneNo integrity impact
Availability HighTotal denial of service — the component is completely unavailable