Apache Tomcat 8

Tenable plugin 103698 maps to CVE-2017-12617 for Tomcat 8.5.0 through 8.5.22, fixed in 8.5.23. The bug lets an unauthenticated attacker upload a JSP and then execute it as server-side code, but only when Tomcat accepts writable HTTP PUT to the DefaultServlet, typically because the readonly init parameter was changed to false or an equivalent writable configuration exists. Upstream also lists affected branches as 9.0.0.M1 to 9.0.0, 8.0.0.RC1 to 8.0.46, and 7.0.0 to 7.0.81.

In lab terms this is straightforward RCE; in enterprise reality it is not default-reachable on most Tomcat deployments. That friction keeps it out of CRITICAL for me. But it is still HIGH because the attack is unauthenticated, public exploit code and Metasploit support have existed for years, CISA has it in KEV, and exposed misconfigured servers have been used in opportunistic campaigns like cryptomining.

Why this verdict

• Start at vendor HIGH: if the preconditions line up, this is unauthenticated network RCE with full CIA impact.
• Downward adjustment for attacker position reality: the attacker needs not just remote reachability, but a Tomcat deployment that also left PUT writable to the DefaultServlet or equivalent path; that is a meaningful narrowing of the exposed population.
• Upward adjustment for threat evidence: KEV listing, long-lived public PoCs, Metasploit support, and observed opportunistic abuse mean the remaining exposed hosts are attractive and quickly targeted.

Why not higher?

This is not a default-on Tomcat catastrophe. The exploit chain assumes external reachability plus a writable PUT path that many mature deployments do not expose, and reverse proxies or WAFs frequently kill that verb before it reaches Tomcat. Those compounding prerequisites are exactly why I won't call it CRITICAL across a 10,000-host estate.

Why not lower?

Dropping this to MEDIUM would underweight two things that matter in the real world: unauthenticated RCE and known exploitation. Once you do have the bad configuration, this is easy to weaponize and the impact is immediate application-server compromise, not a theoretical edge case.

1. Block HTTP PUT now — At reverse proxies, load balancers, WAFs, and Tomcat itself, deny PUT to JSP-capable paths and default-servlet targets. Because this CVE is KEV-listed, deploy this immediately, within hours, not on the normal HIGH timeline.
2. Restore readonly=true — Review conf/web.xml and any application-specific WEB-INF/web.xml overrides for the DefaultServlet readonly parameter and force it back to the safe default. Do this immediately, within hours anywhere the affected version range is still present.
3. Constrain Tomcat exposure — Move direct Tomcat access behind vetted reverse proxies, restrict source IPs, and keep app-tier listeners off the open internet where possible. For KEV-listed exposure, enforce this immediately, within hours on internet-facing systems.
4. Hunt for JSP drops and child processes — Search webroots for recently created .jsp files, correlate PUT followed by GET to the same object, and alert on Tomcat spawning shells, downloaders, or miners. Start the hunt immediately, within hours for exposed servers in the vulnerable range.

Run this on the Tomcat host with read access to the Tomcat installation and configuration. Invoke it as sudo bash check_cve_2017_12617.sh /opt/tomcat or set CATALINA_BASE; root is not strictly required, but you need permission to read conf/web.xml, app web.xml files, and the Tomcat version data.

#!/usr/bin/env bash
# check_cve_2017_12617.sh
# Local check for Apache Tomcat CVE-2017-12617 on the 8.5.x branch.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 3=UNKNOWN

set -u

BASE="${1:-${CATALINA_BASE:-${CATALINA_HOME:-}}}"
if [[ -z "$BASE" ]]; then
  for d in /opt/tomcat /usr/local/tomcat /usr/share/tomcat* /var/lib/tomcat*; do
    if [[ -d "$d" ]]; then
      BASE="$d"
      break
    fi
  done
fi

if [[ -z "$BASE" || ! -d "$BASE" ]]; then
  echo "UNKNOWN - could not determine Tomcat base directory; pass it as the first argument"
  exit 3
fi

version=""
if [[ -x "$BASE/bin/version.sh" ]]; then
  out="$($BASE/bin/version.sh 2>/dev/null || true)"
  version="$(printf '%s\n' "$out" | sed -n 's/^Server version: .*\/\([0-9][0-9.]*\).*$/\1/p' | head -n1)"
fi

if [[ -z "$version" && -f "$BASE/RELEASE-NOTES" ]]; then
  version="$(sed -n 's/^Apache Tomcat Version \([0-9][0-9.]*\).*$/\1/p' "$BASE/RELEASE-NOTES" | head -n1)"
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN - could not determine Tomcat version under $BASE"
  exit 3
fi

verlte() {
  [[ "$1" == "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" ]]
}

vergte() {
  [[ "$1" == "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" ]]
}

# This check is intentionally scoped to the Tenable 8.5.x finding.
if ! vergte "$version" "8.5.0" || ! verlte "$version" "8.5.22"; then
  echo "PATCHED - Tomcat version $version is outside the vulnerable 8.5.0-8.5.22 range for this finding"
  exit 0
fi

check_readonly_false() {
  local f
  for f in "$BASE/conf/web.xml" "$BASE"/webapps/*/WEB-INF/web.xml; do
    [[ -f "$f" ]] || continue
    if awk 'BEGIN{RS="</servlet>"; IGNORECASE=1}
      /<servlet-name>[[:space:]]*default[[:space:]]*<\/servlet-name>/ &&
      /<param-name>[[:space:]]*readonly[[:space:]]*<\/param-name>/ &&
      /<param-value>[[:space:]]*false[[:space:]]*<\/param-value>/ {found=1}
      END{exit(found?0:1)}' "$f"; then
      echo "$f"
      return 0
    fi
  done
  return 1
}

if hit="$(check_readonly_false)"; then
  echo "VULNERABLE - Tomcat $version is in range and writable DefaultServlet configuration was found in $hit"
  exit 1
fi

echo "UNKNOWN - Tomcat $version is in the affected range, but writable DefaultServlet PUT was not confirmed in scanned web.xml files"
exit 3

Sources

1. Tenable plugin 103698
2. Apache Tomcat 8 security page
3. NVD CVE-2017-12617
4. CISA KEV catalog (print view)
5. Ubuntu CVE page for backports
6. Security Risk Advisors analysis
7. Alphabot analysis
8. LAC JSOC report discussing attacks and mining activity