Apache Tomcat SEoL

Tenable plugin 171351 fires when it detects Apache Tomcat 7.0.x on a host. That entire branch reached end of life on 2021-03-31, with 7.0.109 as the final release, so every 7.0.x build is now permanently outside normal security maintenance. The plugin is not tied to one CVE; it is flagging that future Tomcat flaws in the 7.x line will not receive vendor fixes and that older 7.x deployments often lag behind years of prior security fixes.

Tenable's CRITICAL / 10.0 label is too aggressive for patch-priority decisions because unsupported status is not itself a remotely exploitable vulnerability. Real-world impact depends on extra conditions: the host has to be reachable, the specific Tomcat instance has to expose an exploitable surface like Manager or AJP, or it has to still be on a pre-7.0.100 build vulnerable to something like Ghostcat. For a 10,000-host estate, this is better treated as material attack-surface debt that deserves migration planning and exposure triage, not as an immediate all-hands critical unless the Tomcat 7 instances are internet-facing.

Why this verdict

• Down from vendor 10.0: Tenable is scoring a *state* (unsupported software), not proving an exploit primitive. There is no single unauthenticated remote action that turns 171351 into compromise on its own.
• Attacker position matters: If Tomcat 7 is internal-only, the prerequisite already implies post-initial-access. Requiring internal network reachability is major downward pressure on severity.
• Reachable population narrows fast: Real exploitation usually also needs exposed Manager, exposed AJP, or a specific lagging sub-version. Each prerequisite cuts the fraction of real enterprise deployments that are actually one request away from impact.
• Modern controls should intercept the chain: NGFW segmentation, WAF/reverse proxies, VPN requirements, IP allowlists on Manager, MFA/SSO in front of admin surfaces, and EDR on the host all raise attacker cost substantially.
• But not LOW: Tomcat is widely deployed on business-critical apps, and unsupported middleware accumulates silent risk. When the next Tomcat flaw drops, 7.x owners have no vendor patch path.

Why not higher?

To justify HIGH or CRITICAL, I would want direct evidence of active exploitation against this exact issue, or proof that the plugin maps to an unauthenticated exploit with broad default reachability. We do not have that here. 171351 is essentially an attack-surface debt finding that still depends on follow-on conditions.

Why not lower?

I would not drop this to LOW because unsupported Java middleware on production application servers is not harmless backlog dust. Tomcat 7 is old enough that orgs often carry inherited weak configs, and exposed Tomcat admin surfaces continue to attract scanning and brute-force activity. Even without a single active CVE, the residual risk is real.

1. Inventory every Tomcat 7 instance — Find the exact hosts, apps, owners, and exposure paths first, because the risk swings massively between internal middleware and internet-facing portals. For a MEDIUM verdict there is no mitigation SLA; do this as part of normal vulnerability operations while planning remediation inside the 365-day window.
2. Remove internet exposure — Put Tomcat 7 behind reverse proxies, VPN, or internal load balancers wherever business permits. This is the highest-value compensating control because it removes the unauthenticated remote path; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but exposed systems should be prioritized early.
3. Disable or restrict Tomcat Manager and AJP — If manager, host-manager, or AJP are not strictly required, turn them off; if they are required, IP-allowlist them and require strong authentication. This shrinks the real exploit surface that makes old Tomcat builds dangerous while you work toward migration.
4. Harden service accounts and secrets — Run Tomcat with least privilege, rotate stored credentials, and move secrets out of local config files where possible. This limits blast radius if a separate Tomcat flaw or credential attack later lands on the host.
5. Turn on targeted detections — Alert on repeated requests to /manager, /host-manager, /docs, AJP traffic to 8009, suspicious JSP uploads, and unusual child processes from java. Detection won't solve unsupported status, but it catches the follow-on exploit paths attackers actually use.

Run this from an auditor workstation, CI job, or directly on the target host with Python 3. Invoke it as python3 check_tomcat7_seol.py /opt/tomcat or point it at catalina.jar directly, for example python3 check_tomcat7_seol.py /opt/tomcat/lib/catalina.jar. No admin rights are required if you can read the Tomcat installation path.

#!/usr/bin/env python3
# check_tomcat7_seol.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE (Tomcat 7.0.x / unsupported)
#   2 = UNKNOWN (could not determine version)

import os
import re
import sys
import zipfile
from pathlib import Path

VERSION_RE = re.compile(r'(\d+\.\d+\.\d+)')


def extract_version_from_text(text: str):
    if not text:
        return None
    m = VERSION_RE.search(text)
    return m.group(1) if m else None


def read_manifest_version(jar_path: Path):
    try:
        with zipfile.ZipFile(jar_path, 'r') as zf:
            candidates = [
                'META-INF/MANIFEST.MF',
                'org/apache/catalina/util/ServerInfo.properties',
            ]
            for name in candidates:
                try:
                    data = zf.read(name).decode('utf-8', errors='ignore')
                    v = extract_version_from_text(data)
                    if v:
                        return v
                except KeyError:
                    continue
    except Exception:
        return None
    return None


def find_version(base: Path):
    if base.is_file() and base.name.lower() == 'catalina.jar':
        return read_manifest_version(base)

    jar_candidates = [
        base / 'lib' / 'catalina.jar',
        base / 'server' / 'lib' / 'catalina.jar',
    ]
    for jar in jar_candidates:
        if jar.exists():
            v = read_manifest_version(jar)
            if v:
                return v

    text_candidates = [
        base / 'RELEASE-NOTES',
        base / 'RUNNING.txt',
        base / 'webapps' / 'docs' / 'changelog.html',
    ]
    for f in text_candidates:
        if f.exists() and f.is_file():
            try:
                data = f.read_text(encoding='utf-8', errors='ignore')
                v = extract_version_from_text(data)
                if v:
                    return v
            except Exception:
                pass

    return None


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN - usage: python3 check_tomcat7_seol.py <tomcat_home|path_to_catalina.jar>')
        sys.exit(2)

    target = Path(sys.argv[1]).expanduser().resolve()
    if not target.exists():
        print(f'UNKNOWN - path does not exist: {target}')
        sys.exit(2)

    version = find_version(target)
    if not version:
        print('UNKNOWN - could not determine Tomcat version from installation files')
        sys.exit(2)

    if version.startswith('7.0.'):
        print(f'VULNERABLE - Apache Tomcat {version} is in the unsupported 7.0.x branch')
        sys.exit(1)

    print(f'PATCHED - Apache Tomcat {version} is not in the unsupported 7.0.x branch')
    sys.exit(0)


if __name__ == '__main__':
    main()

Sources

1. Tenable Nessus Plugin 171351
2. Apache Tomcat 7.0.x End of Life Notice
3. Apache Tomcat 7.x Vulnerabilities Page
4. Apache Tomcat 7.0.109 Changelog
5. NVD CVE-2020-1938
6. CISA Known Exploited Vulnerabilities Catalog
7. GreyNoise: Coordinated Brute Force Activity Targeting Apache Tomcat Manager
8. Tenable Ghostcat Analysis