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.
4 steps from start to impact.
Fingerprint a Tomcat 7 target
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.- Public or internal HTTP(S) reachability to the Tomcat-hosted application
- Tomcat 7.x in the affected range
- 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
web.xml / annotation security behavior.Confirm the app uses the bad constraint pattern
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.- Application developers used empty-string context-root security constraints and/or annotation-based constraints
- Protected content is exposed through those exact paths
- 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
Send a direct unauthorized request
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.- A matching protected endpoint exists
- No compensating authz enforcement exists higher in the stack
- 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
200/content to an unauthenticated request; generic IDS signatures are weak.Access only the exposed app resource
- The exposed resource contains useful data or privileged functions
- 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
The supporting signals.
| In-the-wild status | No evidence these CVEs are in the current CISA KEV catalog, and I found no credible reporting of sustained in-the-wild exploitation. |
|---|---|
| PoC availability | There 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. |
| EPSS | Low 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 status | Not KEV-listed. No CISA due date pressure, no confirmed active exploitation override. |
| CVSS vector reality check | CVE-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 versions | Upstream 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 versions | Upstream 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 data | Bitsight'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 timeline | Apache 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 / reporter | CVE-2018-1304 was reported publicly via Apache Bugzilla issue 62067; CVE-2018-1305 was identified by the Apache Tomcat Security Team. |
noisgate verdict.
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.
Why this verdict
- Downward pressure: version-only detection — Tenable
106975does 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.
What to do — in priority order.
- Review app auth mappings — Inspect
web.xml, annotation-based@ServletSecurityusage, 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. - 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.
- 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.
- 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
GETto the wrong path. - A WAF-only approach is weak unless it blocks access to the sensitive routes outright; the requests can look perfectly normal.
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.
#!/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
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.