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

Apache Tomcat 8

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

This is less a blown front door than a lock that only fails on oddly hung doors

Tenable plugin 106976 rolls up two Apache Tomcat 8 fixes shipped in 8.0.50: CVE-2018-1305, where servlet annotation-based security constraints were applied only after a servlet loaded, and CVE-2018-1304, where a security constraint mapped to the empty-string context root could be ignored. For Tomcat 8.0.0.RC1 through 8.0.49, the outcome is possible unauthorized access to protected application resources if the deployed webapp uses the affected security patterns.

Vendor MEDIUM is basically right. The impact is real, but the reachable population is much smaller than a generic remote Tomcat bug because exploitation depends on how the application defines security constraints, not just Tomcat being present. Nessus also says this plugin is a version-only check, which means a lot of hits are patch-priority noise unless the hosted app actually uses the vulnerable mappings.

"Real bug, narrow trigger: this is an app-specific auth bypass risk, not a mass-exploitation Tomcat fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Fingerprint Tomcat with curl or Burp

An attacker first identifies an exposed Tomcat-backed application and confirms it is on a vulnerable branch before 8.0.50. In practice this is done with basic HTTP probing, banner collection, package inventory leakage, or by piggybacking on scanner findings like Nessus plugin 106976.
Conditions required:
  • Network reachability to the Tomcat-hosted application
  • A Tomcat version in the affected range
  • Some externally reachable application path
Where this breaks in practice:
  • Many enterprises hide Tomcat behind reverse proxies or application servers, making precise versioning unreliable
  • The bug is not exposed by Tomcat alone; the hosted application has to use the affected security-constraint pattern
Detection/coverage: Good for version detection, weak for exploitability determination. Nessus explicitly notes this plugin relies on the application's self-reported version and does not test the flaws.
STEP 02

Map protected routes using Burp Suite

The attacker looks for URLs that should require authentication and compares behavior across paths, especially context-root handling and servlet paths protected by annotations. The goal is to find an endpoint where the application intended a security constraint but Tomcat failed to enforce it because of the vulnerable mapping or load-order behavior.
Conditions required:
  • The application uses servlet annotations for auth constraints, or uses an empty-string URL pattern mapped to the context root
  • Protected resources are reachable over HTTP(S)
  • The attacker can observe different auth outcomes across paths
Where this breaks in practice:
  • This is application-specific and often requires trial-and-error against each app
  • Many apps do not use the empty-string constraint pattern at all
  • The annotation bug depends on servlet load order, so reproducibility can vary
Detection/coverage: WAFs may log unusual path probing, but there is no generic signature for 'auth constraint not applied.' App logs showing anonymous access to normally protected routes are more useful.
STEP 03

Bypass intended auth with curl

If the app is one of the unlucky ones, the attacker requests the target URL in a way that lands on the unprotected path interpretation. Successful exploitation exposes resources that should have required authentication, potentially leaking data or enabling unauthorized function access depending on the app.
Conditions required:
  • A vulnerable route has been identified
  • The resource behind that route returns useful content or functionality
  • No compensating auth exists in the application logic itself
Where this breaks in practice:
  • If the app performs authorization checks in code, Tomcat's missed container-level constraint may not be enough
  • Impact can be limited to a narrow set of URLs instead of full application compromise
Detection/coverage: Look for anonymous requests to endpoints that should correlate with authenticated sessions, especially 200 responses where auth redirects or 401/403 are expected.
STEP 04

Leverage exposed data or actions manually

The final impact is whatever the protected endpoint does: read-only data leakage, administrative metadata exposure, or business-action abuse. This is not an automatic RCE chain; the attacker still needs the app to expose something valuable behind the bypassed constraint.
Conditions required:
  • The protected endpoint contains sensitive data or privileged actions
  • The application does not perform secondary per-request authorization
Where this breaks in practice:
  • Blast radius is bounded by the specific application and route design
  • No direct Tomcat-to-host compromise follows from these CVEs alone
Detection/coverage: EDR is mostly irrelevant here. Application audit logs, reverse-proxy logs, and anomaly detection on unauthenticated access patterns matter more.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation in cited primary sources. Tenable marks plugin 106976 as Exploit Ease: No known exploits are available, and these CVEs do not appear in CISA KEV.
Proof-of-concept availabilityNo widely cited weaponized public exploit repo surfaced in primary-source review. This looks more like a manual curl/Burp validation issue than a commodity exploit; that is an inference from the source set.
EPSSCVE-2018-1305 EPSS is about 0.19579 (~19.6%) per Tenable's CVE page; CVE-2018-1304 is about 2.08% / ~84th percentile per CVE Details. Treat 1305 as the risk driver.
KEV statusNot KEV-listed as of 2026-05-30 based on the CISA KEV catalog and source review.
CVSS reality checkThe highest vendor/NVD vector in the bundle is CVE-2018-1305 at 6.5 / MEDIUM: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. That overstates broad enterprise urgency because the missing piece is app-specific usage of the vulnerable security model.
Affected versionsTomcat 8.0.0.RC1 through 8.0.49 are affected by both issues in this plugin. The same bugs also touched Tomcat 8.5.0-8.5.27, 7.0.0-7.0.84, and early 9.0.0.M* lines.
Fixed versionsUpstream fixed this in Apache Tomcat 8.0.50. Distro backports exist, e.g. Debian stretch fixed tomcat8 in 8.5.14-1+deb9u3 and Ubuntu fixed packages such as 8.5.21-1ubuntu1.1 and 8.0.32-1ubuntu1.6 depending on release.
Exposure/scanning realityInternet exposure is not the same as exploitability. You can find Tomcat-backed apps externally, but there is no generic Shodan/Censys-style fingerprint for 'uses empty-string security constraint' or 'annotation load-order bug present.'
Disclosure timelineTomcat says these fixes landed in 8.0.50 on 2018-02-13 and the vulnerabilities were made public on 2018-02-23. Tenable published plugin 106976 on 2018-02-23.
Researcher / reportingCVE-2018-1305 was identified by the Apache Tomcat Security Team on 2018-02-01. CVE-2018-1304 traces to public bug report 62067 on 2018-01-31, with security implications recognized the same day.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.9/10)

The decisive downward pressure is that exploitation requires a vulnerable application security pattern, not merely a reachable Tomcat server. This keeps the real exposed population much smaller than the raw Tomcat install base, and there is no KEV or strong active-exploitation signal to offset that friction.

HIGH Affected upstream version range and fixed release
MEDIUM Reassessed severity versus vendor MEDIUM
LOW Public PoC absence / lack of exploitation evidence from primary-source review

Why this verdict

  • App-specific prerequisite: the attacker only wins if the hosted webapp actually uses annotation-based constraints or the empty-string context-root mapping pattern.
  • Version-only detection: Nessus says plugin 106976 relies on self-reported version and does not validate exploitability, so many findings are not immediately actionable fire alarms.
  • No live-fire intel: no KEV listing and no strong primary-source evidence of broad in-the-wild exploitation keeps this out of HIGH.

Why not higher?

This is not a generic unauthenticated Tomcat takeover. There is no built-in code execution, no trivial one-packet exploit path, and no evidence in the reviewed source set that attackers are mass-scanning or mass-weaponizing these exact CVEs. The required application behavior sharply narrows real exposure.

Why not lower?

If the application does rely on the affected constraint handling, the result is an actual authorization bypass to protected resources, not a cosmetic bug. On externally reachable business apps, that can mean real data exposure or unauthorized actions, so writing it off as LOW would understate the downside.

05 · Compensating Control

What to do — in priority order.

  1. Restrict direct access — Put affected Tomcat apps behind a reverse proxy, VPN, or IP allowlist where possible to reduce unauthenticated route probing. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but use this sooner for internet-facing apps with sensitive routes.
  2. Enforce auth in application code — Where you own the app, do not rely solely on container-managed constraints for high-value routes; add explicit authorization checks in the application layer. This reduces exposure even if Tomcat's constraint mapping is wrong, and should be prioritized before the 365-day remediation window closes.
  3. Review web.xml and annotations — Search for empty-string URL patterns, servlet-security annotations, and root-context protections that assume Tomcat container enforcement. Validate those patterns now on exposed apps, then patch within the noisgate remediation SLA for this severity.
  4. Alert on anonymous access to protected paths — Tune reverse-proxy and app logging so unauthenticated 200 responses on routes expected to redirect or deny are visible. This is a low-cost detective control while you work through patch validation and complete remediation inside the 365-day window.
What doesn't work
  • EDR on the Tomcat host does not meaningfully stop this by itself; this is an authorization logic failure at the web/container layer, not malware execution.
  • A generic WAF ruleset is weak here because the exploit is often just a normal-looking request to an application path that should have been protected.
  • Closing AJP or hardening the JVM does not address these specific CVEs; the issue is security-constraint evaluation in the servlet container.
06 · Verification

Crowdsourced verification payload.

Run this on the target Tomcat host or inside the container image layer where Tomcat is installed. Invoke it as bash verify_tomcat_106976.sh /opt/tomcat or point it directly at catalina.jar; no root is required if you can read Tomcat's lib/ directory.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# verify_tomcat_106976.sh
# Checks whether an Apache Tomcat installation is in the vulnerable range for Tenable plugin 106976
# Vulnerable upstream range: 8.0.0.RC1 <= version < 8.0.50
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET="${1:-}"

if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <tomcat_home | path_to_catalina.jar>"
  echo "UNKNOWN"
  exit 2
fi

find_catalina_jar() {
  local t="$1"
  if [[ -f "$t" && "$(basename "$t")" == "catalina.jar" ]]; then
    echo "$t"
    return 0
  fi
  if [[ -d "$t" ]]; then
    if [[ -f "$t/lib/catalina.jar" ]]; then
      echo "$t/lib/catalina.jar"
      return 0
    fi
    local hit
    hit=$(find "$t" -type f -name catalina.jar 2>/dev/null | head -n1)
    if [[ -n "$hit" ]]; then
      echo "$hit"
      return 0
    fi
  fi
  return 1
}

extract_version() {
  local jar="$1"
  local tmpdir
  tmpdir=$(mktemp -d)
  trap 'rm -rf "$tmpdir"' EXIT

  if ! command -v unzip >/dev/null 2>&1; then
    return 1
  fi

  unzip -qq -o "$jar" org/apache/catalina/util/ServerInfo.properties -d "$tmpdir" >/dev/null 2>&1 || true
  unzip -qq -o "$jar" META-INF/MANIFEST.MF -d "$tmpdir" >/dev/null 2>&1 || true

  local v=""
  if [[ -f "$tmpdir/org/apache/catalina/util/ServerInfo.properties" ]]; then
    v=$(grep -E '^server.info=' "$tmpdir/org/apache/catalina/util/ServerInfo.properties" | sed -E 's/^server.info=Apache Tomcat\/?//')
  fi

  if [[ -z "$v" && -f "$tmpdir/META-INF/MANIFEST.MF" ]]; then
    v=$(grep -Ei '^Implementation-Version:' "$tmpdir/META-INF/MANIFEST.MF" | head -n1 | sed -E 's/^Implementation-Version:[[:space:]]*//I')
  fi

  rm -rf "$tmpdir"
  trap - EXIT

  if [[ -n "$v" ]]; then
    echo "$v"
    return 0
  fi
  return 1
}

version_to_sortable() {
  # Converts 8.0.0.RC1 -> 8.0.0~RC1 for sort -V friendliness
  echo "$1" | sed -E 's/\.RC/~RC/I; s/-/~/'
}

version_lt() {
  local a b
  a=$(version_to_sortable "$1")
  b=$(version_to_sortable "$2")
  [[ "$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)" != "$b" && "$a" != "$b" ]]
}

version_ge() {
  local a b
  a=$(version_to_sortable "$1")
  b=$(version_to_sortable "$2")
  [[ "$a" == "$b" ]] && return 0
  [[ "$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)" == "$b" ]]
}

JAR=$(find_catalina_jar "$TARGET") || {
  echo "UNKNOWN"
  exit 2
}

VERSION=$(extract_version "$JAR") || {
  echo "UNKNOWN"
  exit 2
}

# Normalize common prefixes/spaces
VERSION=$(echo "$VERSION" | tr -d '\r' | xargs)

if version_ge "$VERSION" "8.0.0.RC1" && version_lt "$VERSION" "8.0.50"; then
  echo "VULNERABLE"
  exit 1
fi

if version_ge "$VERSION" "8.0.50"; then
  echo "PATCHED"
  exit 0
fi

# Outside the plugin's affected upstream branch
if version_lt "$VERSION" "8.0.0.RC1"; then
  echo "PATCHED"
  exit 0
fi

echo "UNKNOWN"
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, split this finding into internet-facing business apps versus everything else. For this MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but do immediate configuration review on exposed apps to confirm whether they use servlet-annotation constraints or empty-string context-root protections; then complete the actual upgrade to 8.0.50+ or a supported distro backport within the noisgate remediation SLA of 365 days. If the app is public-facing and you confirm it uses the affected patterns, treat that single app as an exception and front-load the patch despite the overall MEDIUM score.

Sources

  1. Tenable plugin 106976
  2. Apache Tomcat 8 security page
  3. NVD CVE-2018-1304
  4. NVD CVE-2018-1305
  5. Debian DSA-4281 tomcat8 security update
  6. Ubuntu CVE-2018-1305 status
  7. Tenable CVE-2018-1305
  8. CISA Known Exploited Vulnerabilities Catalog
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.