← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:106975 · Disclosed 2018-02-23

Apache Tomcat 7

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is less a broken front door than a lock that fails only if the app builder hung it on one very specific hinge

Plugin 106975 is really two Tomcat 7 issues fixed in 7.0.85: CVE-2018-1305, where Servlet annotation-based security constraints were enforced only after the target Servlet had loaded, and CVE-2018-1304, where a security constraint mapped to the empty-string context root could be ignored. Affected upstream Tomcat is 7.0.0 through 7.0.84; the bug lives in Tomcat, but exploitation depends on how the hosted application defines access controls.

Tenable calling this MEDIUM is defensible in a vacuum, but for enterprise patch triage it's a little hot. The scanner is version-only, the reachable population is much smaller than 'all Tomcat 7', there is no KEV listing or meaningful exploitation signal, and the blast radius is usually limited to specific protected paths inside a single webapp rather than immediate server takeover.

"Version-based finding, app-specific exploit path: patch it, but don't let this jump your queue"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Fingerprint a Tomcat 7 target

An attacker first identifies a reachable Tomcat instance and the deployed application paths using basic tooling such as curl, Burp Suite, or normal crawler logic. Tenable's own plugin is version-based, so the mere presence of 7.0.84 does not prove the app is actually exploitable.
Conditions required:
  • Public or internal HTTP(S) reachability to the Tomcat-hosted application
  • Tomcat 7.x in the affected range
Where this breaks in practice:
  • Reverse proxies often hide Tomcat fingerprints
  • Many enterprises do not expose Tomcat directly to the Internet
  • Version presence alone is not enough; the app must use the affected constraint patterns
Detection/coverage: Excellent coverage for version discovery; poor coverage for actual exploitability because most scanners cannot reason about web.xml / annotation security behavior.
STEP 02

Confirm the app uses the bad constraint pattern

For CVE-2018-1304, the webapp must define a security constraint on the empty-string context-root mapping. For CVE-2018-1305, the webapp must rely on annotation-defined Servlet constraints in a load-order scenario where protection is not fully active until the Servlet initializes. This is usually validated with manual probing or small PoC helpers, not a turnkey exploit framework.
Conditions required:
  • Application developers used empty-string context-root security constraints and/or annotation-based constraints
  • Protected content is exposed through those exact paths
Where this breaks in practice:
  • This is a narrow application design dependency
  • A large share of Tomcat apps use other authz patterns and are unaffected in practice
  • Exploitability may disappear behind SSO gateways, reverse proxies, or app-layer auth checks
Detection/coverage: Network scanners usually miss this entirely; code review, config review, or targeted dynamic testing is required.
STEP 03

Send a direct unauthorized request

Using curl or Burp Suite, the attacker requests the target path before the relevant Servlet has initialized or hits the exact context-root path covered by the broken mapping. If the app's authorization logic depends on Tomcat enforcing that constraint, the request may be served when it should have been blocked.
Conditions required:
  • A matching protected endpoint exists
  • No compensating authz enforcement exists higher in the stack
Where this breaks in practice:
  • Many apps also check authorization in application code
  • WAFs and SSO front ends may not stop the bug directly, but they often reduce anonymous reachability
  • The attacker still needs to discover the right path and timing/initialization behavior
Detection/coverage: Possible in web logs if you know which supposedly protected path returned 200/content to an unauthenticated request; generic IDS signatures are weak.
STEP 04

Access only the exposed app resource

Successful exploitation typically yields unauthorized access to a specific web resource, admin page, or data view that should have been access-controlled. This is not an automatic Tomcat compromise, not an instant webshell, and not a platform-wide escape; impact is bounded by what that one app path exposes.
Conditions required:
  • The exposed resource contains useful data or privileged functions
Where this breaks in practice:
  • Blast radius is usually limited to one application or URL space
  • No native path to code execution from these CVEs alone
  • Impact may be low if the exposed page is non-sensitive or additionally guarded
Detection/coverage: Look for access to protected endpoints without corresponding authenticated sessions, especially first-hit requests after app restart or requests to context-root-only protected routes.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence these CVEs are in the current CISA KEV catalog, and I found no credible reporting of sustained in-the-wild exploitation.
PoC availabilityThere are GitHub testing repos and walkthrough-style PoCs for CVE-2018-1304 (for example knqyf263/CVE-2018-1304 and thariyarox/tomcat_CVE-2018-1304_testing as indexed by Feedly/CVEfeed), but this is validation code, not a reliable mass-exploitation kit.
EPSSLow signal. Feedly shows CVE-2018-1304 at 0.41% EPSS / 70.7 percentile; Tenable's CVE page shows CVE-2018-1305 EPSS 0.19579.
KEV statusNot KEV-listed. No CISA due date pressure, no confirmed active exploitation override.
CVSS vector reality checkCVE-2018-1305 carries CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N and CVE-2018-1304 carries CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N. In practice, the real gating factor is not the network vector; it's whether the app uses the exact broken authorization pattern.
Affected versionsUpstream Apache Tomcat 7.0.0 through 7.0.84 are affected for both CVEs; the same flaws also existed in equivalent 8.0.x, 8.5.x, and early 9.0.x trains.
Fixed versionsUpstream fixed in Tomcat 7.0.85. Distro/backport examples: Debian Wheezy LTS fixed tomcat7 in 7.0.28-4+deb7u18; Amazon Linux 1 shipped tomcat7-7.0.85-1.32.amzn1.
Exposure dataBitsight's Groma page for Tomcat 7.0.84 shows 150 total public observations over the prior 30 days and 25,267 observations associated with CVE-2018-1304 across observed assets. That's exposure to old Tomcat, not proof the vulnerable app pattern is present.
Disclosure timelineApache lists the fix under 13 February 2018 (7.0.85); CVE-2018-1305 was made public 2018-02-23 and CVE-2018-1304 is tracked by NVD as published **2018-02-28`.
Researcher / reporterCVE-2018-1304 was reported publicly via Apache Bugzilla issue 62067; CVE-2018-1305 was identified by the Apache Tomcat Security Team.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.4/10)

The decisive factor is exploit population collapse: being on vulnerable Tomcat 7 is not enough; the hosted application must also use one of two narrow security-constraint patterns. That turns this from a broad platform bug into an app-specific authorization edge case with limited evidence of real-world weaponization.

HIGH Vendor version range and fixed release `7.0.85`
MEDIUM Real-world downgrade based on app-design dependency and low exploitation signal

Why this verdict

  • Downward pressure: version-only detection — Tenable 106975 does not test exploitability; it flags any Tomcat <7.0.85, so many findings will be false positives for actual reachable impact.
  • Downward pressure: attacker needs a specific app pattern — exploitation requires either empty-string context-root constraints or annotation-based constraints with favorable load order, which sharply narrows the exposed population.
  • Downward pressure: blast radius is local to one webapp path — these CVEs yield unauthorized access to specific resources, not default RCE or Tomcat instance takeover.
  • No threat amplifier — no KEV entry, no established mass-exploitation signal, and low EPSS compared with what we'd expect for internet-burning webapp bugs.

Why not higher?

This is not a generic unauthenticated Tomcat break. An attacker must land on a Tomcat deployment and a webapp using the exact broken security-constraint design, which means the vulnerable population is far smaller than the product install base. There is also no direct code execution path from these CVEs alone.

Why not lower?

It still affects a common public-facing platform, and when the bad pattern is present the outcome is real unauthorized access to protected resources. If one of your legacy apps relies on Tomcat for coarse-grained authz, this can become a quiet data-exposure bug rather than harmless noise.

05 · Compensating Control

What to do — in priority order.

  1. Review app auth mappings — Inspect web.xml, annotation-based @ServletSecurity usage, and any context-root protections on affected Tomcat 7 apps. For a LOW verdict there is no SLA; do this as backlog hygiene during normal application review, prioritizing Internet-facing apps first.
  2. Enforce auth upstream — Where feasible, require authentication and authorization at the reverse proxy, SSO gateway, or API gateway so Tomcat's local constraint handling is not the only guardrail. For LOW, deploy in normal change windows rather than breaking production for an edge-case bug.
  3. Log protected-path denials and allows — Add monitoring for requests to admin or protected routes that return success without expected session or identity context. This helps you spot silent exposure while you work through routine remediation.
What doesn't work
  • A generic network scanner re-scan doesn't prove safety, because the problem is app-specific authorization logic rather than a simple banner match.
  • An EDR agent on the host is not the right control here; there's usually no malware or process-level exploit artifact because successful abuse can just be an HTTP GET to the wrong path.
  • A WAF-only approach is weak unless it blocks access to the sensitive routes outright; the requests can look perfectly normal.
06 · Verification

Crowdsourced verification payload.

Run this on the target Tomcat host as a user with read access to the Tomcat installation. Invoke it with the Tomcat home path, for example: bash check_tomcat_106975.sh /opt/tomcat. It needs no root privileges unless your Tomcat directories are restricted.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_tomcat_106975.sh
# Determine whether an Apache Tomcat 7 installation is vulnerable to Tenable plugin 106975
# (Tomcat 7.0.0 < 7.0.85; CVE-2018-1304 / CVE-2018-1305)
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

TARGET_PATH="${1:-}"

find_tomcat_home() {
  local candidates=()
  if [ -n "$TARGET_PATH" ]; then
    candidates+=("$TARGET_PATH")
  fi
  [ -n "${CATALINA_HOME:-}" ] && candidates+=("$CATALINA_HOME")
  [ -n "${CATALINA_BASE:-}" ] && candidates+=("$CATALINA_BASE")
  candidates+=(/opt/tomcat /usr/share/tomcat7 /var/lib/tomcat7 /usr/local/tomcat /opt/apache-tomcat*)

  local c
  for c in "${candidates[@]}"; do
    [ -e "$c" ] || continue
    if [ -f "$c/lib/catalina.jar" ] || [ -f "$c/RELEASE-NOTES" ] || [ -f "$c/RUNNING.txt" ]; then
      echo "$c"
      return 0
    fi
  done
  return 1
}

extract_version() {
  local home="$1"
  local v=""

  # Try RELEASE-NOTES first
  if [ -f "$home/RELEASE-NOTES" ]; then
    v=$(grep -Eom1 'Apache Tomcat Version [0-9]+\.[0-9]+\.[0-9]+' "$home/RELEASE-NOTES" | awk '{print $4}')
    [ -n "$v" ] && { echo "$v"; return 0; }
  fi

  # Try RUNNING.txt
  if [ -f "$home/RUNNING.txt" ]; then
    v=$(grep -Eom1 'Apache Tomcat Version [0-9]+\.[0-9]+\.[0-9]+' "$home/RUNNING.txt" | awk '{print $4}')
    [ -n "$v" ] && { echo "$v"; return 0; }
  fi

  # Try manifest inside catalina.jar
  if [ -f "$home/lib/catalina.jar" ] && command -v unzip >/dev/null 2>&1; then
    v=$(unzip -p "$home/lib/catalina.jar" META-INF/MANIFEST.MF 2>/dev/null | sed -n 's/^Implementation-Version: //p' | head -n1 | tr -d '\r')
    [ -n "$v" ] && { echo "$v"; return 0; }
  fi

  return 1
}

version_lt() {
  # returns 0 if $1 < $2
  [ "$1" = "$2" ] && return 1
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

HOME_DIR=$(find_tomcat_home) || {
  echo "UNKNOWN - could not locate Tomcat home; pass the install path explicitly"
  exit 2
}

VERSION=$(extract_version "$HOME_DIR") || {
  echo "UNKNOWN - could not determine Tomcat version from $HOME_DIR"
  exit 2
}

# Only assess Tomcat 7 for this specific Tenable finding.
case "$VERSION" in
  7.*)
    if version_lt "$VERSION" "7.0.85"; then
      echo "VULNERABLE - Apache Tomcat version $VERSION detected at $HOME_DIR (< 7.0.85)"
      exit 1
    else
      echo "PATCHED - Apache Tomcat version $VERSION detected at $HOME_DIR (>= 7.0.85)"
      exit 0
    fi
    ;;
  *)
    echo "UNKNOWN - Tomcat version $VERSION detected at $HOME_DIR; this script only evaluates the Tomcat 7.x condition behind plugin 106975"
    exit 2
    ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: don't treat 106975 like an emergency internet-fire drill, but don't blindly suppress it either. Triage Internet-facing and legacy business apps on Tomcat 7 first, confirm whether they use annotation-based constraints or empty-string context-root protections, and roll the finding into normal patch hygiene. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — go fix it through routine maintenance and application review, not with an outage-grade patch rush.

Sources

  1. Tenable Nessus Plugin 106975
  2. Apache Tomcat 7 security advisories
  3. NVD CVE-2018-1304
  4. NVD CVE-2018-1305
  5. CISA Known Exploited Vulnerabilities Catalog
  6. Bitsight Groma: Apache Tomcat 7.0.84 Observation Footprint
  7. Debian LTS DLA-1301-1 tomcat7 security update
  8. Feedly CVE-2018-1304 intelligence card
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.