This is more like a loose window latch than a missing front door
Tenable plugin 111067 flags Tomcat 8.0.0.RC1 through 8.0.52 because 8.0.53 fixed two issues: CVE-2018-8014 (the Tomcat CORS filter shipped with insecure defaults that could allow credentialed cross-origin access if admins used the default filter behavior) and CVE-2018-8034 (Tomcat's WebSocket client did not verify hostnames by default over TLS). Neither bug is a straight remote server compromise in a default enterprise deployment.
The vendor/NVD severity is inflated versus reality. Apache rated both flaws Low, and the Apache advisory explicitly says most users are not expected to be impacted by CVE-2018-8014; CVE-2018-8034 hits outbound WebSocket client use, not the normal inbound Tomcat server path. Tenable is also clear this plugin is version-only and did not test exploitability, so treating this as a critical patch fire is the wrong move.
4 steps from start to impact.
Find a Tomcat app actually using the vulnerable CORS filter defaults
- Tomcat 8.0.0.RC1-8.0.52
- Application uses Tomcat's CORS filter
- Filter is left in insecure default configuration
- Sensitive endpoints respond to browser-originated requests
- Many Tomcat deployments do not use the built-in CORS filter at all
- Apps commonly override CORS behavior at framework or proxy level
- Apache states most users are not expected to be impacted
111067 does not validate this condition; it keys off Tomcat version only. Confirm with app config review or browser-based CORS testing.Abuse a victim browser, not the server itself
CVE-2018-8014, the realistic attack is a browser-mediated cross-origin read or action using the victim's existing session. The attacker usually needs a logged-in victim to visit attacker-controlled content so the browser sends authenticated requests and exposes responses under the bad CORS policy.- Victim has an active authenticated session
- Victim visits attacker-controlled page or script
- Target endpoint is reachable from victim browser
- Requires user interaction or an existing browser foothold
- Only impacts data/actions reachable through the victim's session
- Modern SSO session controls, CSRF protections, and narrow CORS rules frequently break the chain
Harvest application data or perform limited app actions
- Sensitive API routes exposed through the bad CORS policy
- Victim account has useful permissions
- Blast radius is constrained to what the victim account can access
- No direct server takeover primitive is described in the advisory
- Privilege escalation depends on separate app design weaknesses
Alternative path: man-in-the-middle an outbound WebSocket client
CVE-2018-8034, the attacker must get in position to intercept TLS used by a Tomcat WebSocket client and present the wrong certificate hostname without being rejected. That is a classic position-dependent MITM scenario, not an internet-to-server exploit.- Target app uses Tomcat's WebSocket client over TLS
- Attacker has on-path network position or equivalent trust-anchor abuse
- Outbound connection reaches attacker-controlled or interceptable infrastructure
- Requires internal/on-path attacker position or prior compromise
- Affects client behavior, not the ordinary inbound Tomcat server role
- Many enterprise apps never use this component
The supporting signals.
| In-the-wild status | No evidence from the CISA KEV catalog that either CVE-2018-8014 or CVE-2018-8034 is KEV-listed. I also found no public campaign reporting tied to these two CVEs. |
|---|---|
| PoC availability | CVE-2018-8014 has public GitHub proof-of-concept references in aggregator data, but they are app-misconfiguration demos rather than turnkey server-compromise tooling. Tenable states no known exploits are available for the plugin overall. |
| EPSS | Use the FIRST EPSS API to pull the current score before ticketing at scale. EPSS is not a meaningful amplifier here because the attack chain is configuration- and position-dependent, and there is no public exploitation signal to override that. |
| KEV status | Not listed in CISA KEV as of this review; there is no KEV add date or due date to drive emergency treatment. |
| CVSS mismatch | CVE-2018-8014 carries an NVD 9.8 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), but Apache rates it Low and explicitly says most users are unlikely to be impacted. That's a textbook case where abstract CVSS impact modeling outruns real deployment friction. |
| Affected versions | Plugin scope is Tomcat 8.0.0.RC1 through 8.0.52. Upstream records CVE-2018-8014 for 8.0.0.RC1-8.0.52 and CVE-2018-8034 for 8.0.0.RC1-8.0.52. |
| Fixed versions | Upstream fix point is Apache Tomcat 8.0.53. Distros may backport without reporting 8.0.53; examples include Amazon Linux tomcat8 fixed via ALAS-2018-1056, and multiple Debian/Red Hat advisories referenced by NVD/OSV. |
| Scanning and exposure reality | Internet search platforms can fingerprint Tomcat broadly, but they cannot tell you whether the built-in CORS filter is enabled with vulnerable defaults or whether the host uses Tomcat's outbound WebSocket client. Exposure population is therefore far smaller than 'all Tomcat 8.0.x servers'. |
| Disclosure timeline | CVE-2018-8014 was publicly announced on 2018-05-16; CVE-2018-8034 was formally announced on 2018-07-22. Apache fixed both for the 8.0 branch in release 8.0.53 dated 2018-07-06. |
| Researcher / reporter | Apache says CVE-2018-8014 was reported publicly on 2018-05-01. CVE-2018-8034 was reported publicly on 2018-06-11; no named external researcher is highlighted in the Apache 8.x advisory entry. |
noisgate verdict.
The decisive factor is attack-path friction: the more plausible flaw requires optional, app-level CORS misconfiguration plus a victim browser session, while the second flaw requires an on-path attack against an outbound WebSocket client. That is nowhere near the exposure profile of an unauthenticated remote server exploit, regardless of the headline CVSS.
Why this verdict
- Optional feature dependency: the dominant path needs the Tomcat CORS filter to be enabled and left with insecure defaults; that narrows real exposure well below 'every Tomcat host'.
- Attacker-position friction:
CVE-2018-8034is a WebSocket *client* hostname-validation bug, which implies outbound client use plus MITM/on-path capability or equivalent prior compromise. - Limited blast radius: even if
CVE-2018-8014is exploitable, impact is bounded to browser-mediated application data or actions under a victim session, not straight Tomcat or OS takeover.
Why not higher?
There is no KEV listing, no credible public exploitation wave, and no direct unauthenticated server-compromise primitive in the upstream advisory. The strongest 'critical' signal here is an NVD score for CVE-2018-8014, but Apache's own description and the required prerequisites cut that down hard in real environments.
Why not lower?
I am not calling it IGNORE because these are still real flaws, and a subset of enterprises absolutely do run sensitive browser apps with sloppy CORS or custom outbound WebSocket logic. Also, Tomcat 8.0.x is end-of-life, so a version-only finding can still be a useful marker for stale platform debt even when this specific vuln bundle is low priority.
What to do — in priority order.
- Lock down CORS explicitly — Review apps using Tomcat's CORS filter and set explicit allowed origins, methods, and credential behavior rather than relying on defaults. For a
LOWverdict there is no mitigation SLA; handle this as backlog hygiene during normal application hardening. - Inventory outbound WebSocket client use — Identify apps that use Tomcat's WebSocket client over TLS and verify hostname validation through code review or test harnesses. Again, for
LOWthere is no mitigation SLA; fold this into regular secure configuration review rather than emergency change windows. - Prioritize supported Tomcat branches — Treat any surviving
8.0.xfootprint as lifecycle debt and move workloads to a supported branch so future Tomcat security fixes are available. ForLOW, there is no special deadline from noisgate; schedule in the routine modernization queue.
- A generic WAF does not fix a bad browser trust decision created by permissive CORS headers; if the app says the browser may read the response, the WAF is usually out of the loop.
- Perimeter inbound firewalling does little for
CVE-2018-8034because the issue is on the outbound client side and depends on certificate hostname validation during TLS. - Treating the Nessus hit as proof of exploitability doesn't work; the plugin itself says it relied on the application's self-reported version and did not test the vulnerable conditions.
Crowdsourced verification payload.
Run this on the target host or from an auditor workstation with filesystem access to the Tomcat install. Invoke it with python3 check_tomcat_111067.py /opt/tomcat or python check_tomcat_111067.py C:\Tomcat; no admin rights are required if you can read lib/catalina.jar.
#!/usr/bin/env python3
# check_tomcat_111067.py
# Detects whether a Tomcat installation falls into Tenable plugin 111067 scope
# (Apache Tomcat 8.0.0.RC1 through 8.0.52, fixed in 8.0.53).
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import re
import sys
import zipfile
def read_server_info(catalina_home):
jar_path = os.path.join(catalina_home, 'lib', 'catalina.jar')
if not os.path.isfile(jar_path):
return None, f'missing {jar_path}'
candidates = [
'org/apache/catalina/util/ServerInfo.properties',
'org/apache/catalina/util/serverinfo.properties',
]
try:
with zipfile.ZipFile(jar_path, 'r') as zf:
for name in candidates:
try:
data = zf.read(name).decode('utf-8', errors='ignore')
m = re.search(r'server\.info\s*=\s*Apache Tomcat/([^\s\r\n]+)', data)
if m:
return m.group(1).strip(), None
except KeyError:
continue
except Exception as e:
return None, str(e)
return None, 'server.info not found in catalina.jar'
def parse_version(ver):
# Handles 8.0.53, 8.0.0.RC1, 8.0.0-RC1, 8.0.0RC1
raw = ver.strip()
m = re.match(r'^(\d+)\.(\d+)\.(\d+)(?:[.-]?(?:RC)(\d+))?$', raw, re.IGNORECASE)
if not m:
return None
major = int(m.group(1))
minor = int(m.group(2))
patch = int(m.group(3))
rc = int(m.group(4)) if m.group(4) else None
return (major, minor, patch, rc)
def compare_versions(a, b):
# Compare tuples (major, minor, patch, rc) where rc is None for final release.
# RC is considered lower than final release of same numeric version.
for i in range(3):
if a[i] < b[i]:
return -1
if a[i] > b[i]:
return 1
arc = -1 if a[3] is not None else 10**9
brc = -1 if b[3] is not None else 10**9
if arc < brc:
return -1
if arc > brc:
return 1
return 0
def main():
if len(sys.argv) != 2:
print('UNKNOWN - usage: python3 check_tomcat_111067.py <CATALINA_HOME>')
sys.exit(2)
catalina_home = sys.argv[1]
version, err = read_server_info(catalina_home)
if not version:
print(f'UNKNOWN - could not determine Tomcat version: {err}')
sys.exit(2)
parsed = parse_version(version)
if not parsed:
print(f'UNKNOWN - unrecognized Tomcat version format: {version}')
sys.exit(2)
lower = (8, 0, 0, 1) # 8.0.0.RC1
upper_fixed = (8, 0, 53, None)
if parsed[0] != 8 or parsed[1] != 0:
print(f'UNKNOWN - Tomcat {version} is outside plugin 111067 branch scope (expects 8.0.x)')
sys.exit(2)
if compare_versions(parsed, lower) >= 0 and compare_versions(parsed, upper_fixed) < 0:
print(f'VULNERABLE - Apache Tomcat/{version} is in 8.0.0.RC1 through 8.0.52')
sys.exit(1)
if compare_versions(parsed, upper_fixed) >= 0:
print(f'PATCHED - Apache Tomcat/{version} is 8.0.53 or later in the 8.0.x branch')
sys.exit(0)
print(f'UNKNOWN - Apache Tomcat/{version} did not match expected vulnerable range logic')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
LOW verdict there is no noisgate mitigation SLA and effectively no noisgate remediation SLA beyond backlog hygiene, so validate whether any affected apps actually use Tomcat's CORS filter or outbound WebSocket client, then roll the fix into your next normal Tomcat maintenance cycle; because 8.0.x is end-of-life, use that cycle to move off the unsupported branch rather than treating 111067 as an emergency patch event.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.