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.
4 steps from start to impact.
Fingerprint Tomcat with curl or Burp
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.- Network reachability to the Tomcat-hosted application
- A Tomcat version in the affected range
- Some externally reachable application path
- 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
Map protected routes using Burp Suite
- 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
- 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
Bypass intended auth with curl
- 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
- 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
200 responses where auth redirects or 401/403 are expected.Leverage exposed data or actions manually
- The protected endpoint contains sensitive data or privileged actions
- The application does not perform secondary per-request authorization
- Blast radius is bounded by the specific application and route design
- No direct Tomcat-to-host compromise follows from these CVEs alone
The supporting signals.
| In-the-wild status | No 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 availability | No 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. |
| EPSS | CVE-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 status | Not KEV-listed as of 2026-05-30 based on the CISA KEV catalog and source review. |
| CVSS reality check | The 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 versions | Tomcat 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 versions | Upstream 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 reality | Internet 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 timeline | Tomcat 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 / reporting | CVE-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. |
noisgate verdict.
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.
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
106976relies 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.
What to do — in priority order.
- 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.
- 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.
- Review
web.xmland 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. - Alert on anonymous access to protected paths — Tune reverse-proxy and app logging so unauthenticated
200responses 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.
- 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.
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.
#!/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
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.