← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:111067 · Disclosed 2018-07-22

Apache Tomcat 8

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

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.

"This is a version-only hit on two low-end Tomcat issues, not a practical server-takeover bug."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a Tomcat app actually using the vulnerable CORS filter defaults

The attacker first needs an application on Tomcat that enabled the bundled CORS filter and left permissive defaults in place. This is not the same as 'Tomcat is installed'; it is an application-specific configuration condition on top of the version match.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Nessus 111067 does not validate this condition; it keys off Tomcat version only. Confirm with app config review or browser-based CORS testing.
STEP 02

Abuse a victim browser, not the server itself

For 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.
Conditions required:
  • Victim has an active authenticated session
  • Victim visits attacker-controlled page or script
  • Target endpoint is reachable from victim browser
Where this breaks in practice:
  • 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
Detection/coverage: Best found with web app testing, CSP/CORS review, and proxy/browser telemetry. Infra vuln scanners usually miss exploitability.
STEP 03

Harvest application data or perform limited app actions

If the CORS path works, the attacker can read or trigger application-layer actions exposed to that user. This is not unauthenticated remote code execution against Tomcat and does not inherently grant OS or container control.
Conditions required:
  • Sensitive API routes exposed through the bad CORS policy
  • Victim account has useful permissions
Where this breaks in practice:
  • 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
Detection/coverage: Watch for unusual cross-origin requests, browser telemetry, and application logs showing authenticated requests from unexpected origins.
STEP 04

Alternative path: man-in-the-middle an outbound WebSocket client

For 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Network TLS inspection, proxy logs, and code/config review are the right controls. Version scanning alone overstates exposure.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityCVE-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.
EPSSUse 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 statusNot listed in CISA KEV as of this review; there is no KEV add date or due date to drive emergency treatment.
CVSS mismatchCVE-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 versionsPlugin 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 versionsUpstream 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 realityInternet 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 timelineCVE-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 / reporterApache 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.4/10)

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.

HIGH Severity downgrade from version-based vendor labeling
MEDIUM Population-level exposure estimate across enterprise Tomcat deployments
MEDIUM Lack of public exploitation signal

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-8034 is 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-8014 is 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.

05 · Compensating Control

What to do — in priority order.

  1. 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 LOW verdict there is no mitigation SLA; handle this as backlog hygiene during normal application hardening.
  2. 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 LOW there is no mitigation SLA; fold this into regular secure configuration review rather than emergency change windows.
  3. Prioritize supported Tomcat branches — Treat any surviving 8.0.x footprint as lifecycle debt and move workloads to a supported branch so future Tomcat security fixes are available. For LOW, there is no special deadline from noisgate; schedule in the routine modernization queue.
What doesn't work
  • 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-8034 because 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not let this plugin jump the queue ahead of real internet-reachable RCEs. For a 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

  1. Tenable plugin 111067
  2. Apache Tomcat 8 security advisories
  3. NVD CVE-2018-8014
  4. NVD CVE-2018-8034
  5. CISA Known Exploited Vulnerabilities catalog
  6. FIRST EPSS API documentation
  7. Amazon Linux advisory for CVE-2018-8014
  8. Censys blog on finding Apache Tomcat servers
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.