Apache Tomcat 7

Plugin tenable:83764 maps to CVE-2014-7810, an Apache Tomcat Expression Language flaw fixed for the 7.x branch in 7.0.59 because 7.0.58 contained the fix but was never released. The bug lets a malicious web application abuse EL evaluation inside a privileged code path and bypass Tomcat's Java SecurityManager protections. For the vulnerable upstream line, Apache lists 7.0.0 through 7.0.57 as affected; the Nessus plugin flags < 7.0.59 for released-build hygiene.

paragraph 2: Vendor severity is technically defensible in a vacuum but too generous for most enterprise fleets. This is not an unauthenticated remote exploit against a normal Tomcat deployment; it generally matters only when you run untrusted third-party apps and enable SecurityManager isolation, which is a narrow shared-hosting or multi-tenant pattern. Tenable also says the plugin is version-only and did not verify exploitability on-host, which pushes this down hard in real patch queues.

Why this verdict

• Requires a prior foothold: the attacker typically needs a way to deploy or alter a webapp first, which implies compromised admin, CI/CD, or tenant access before this CVE matters
• Narrow exposure pattern: impact depends on Tomcat actually using SecurityManager sandboxing for less-trusted apps, which is a minority enterprise pattern
• Version-only detection: Nessus did not validate exploitability on-host; it flagged a version range, so population-level noise is expected
• No KEV / no solid exploitation evidence: no CISA KEV listing and no strong public proof of broad exploitation keep this out of urgent patch lanes
• Blast radius is contextual: the bug is mainly about bypassing app isolation on the same Tomcat instance, not clean unauthenticated server-wide code execution

Why not higher?

Because the headline CVSS framing masks a major prerequisite chain. If an attacker must already be able to publish a malicious app and the server must also rely on SecurityManager isolation, this is not a fleet-wide internet-exposed emergency for a normal enterprise. The reachable population is much smaller than the version count suggests.

Why not lower?

I am not putting this at IGNORE because some organizations really do run shared or delegated Tomcat estates, legacy hosting models, or third-party WAR deployments where SecurityManager was part of the safety boundary. In those environments this is a real isolation failure, just not one that deserves front-of-line treatment across a general enterprise fleet.

1. Audit who can deploy WARs — Confirm whether any tenant, partner, developer, or automation path can deploy or modify applications on affected Tomcat nodes. If deploy rights are tightly controlled, the practical risk collapses; for a LOW verdict there is no SLA (treat as backlog hygiene), but this review is the fastest way to prove the finding is low-noise.
2. Check whether SecurityManager is actually enabled — Review service definitions, startup scripts, and running process arguments for -security or -Djava.security.manager. If it is not enabled, the CVE's core bypass condition is absent; for a LOW verdict there is no SLA (treat as backlog hygiene).
3. Lock down Tomcat Manager and CI/CD deploy paths — Restrict Manager access, rotate old deployment credentials, and validate that only approved pipelines can publish apps. This matters more than the CVE itself because the exploit path starts with a code-deployment foothold; for a LOW verdict there is no SLA (treat as backlog hygiene).
4. Prefer distro backports where applicable — If the host uses vendor-packaged tomcat7 rather than upstream tarballs, verify the distro-fixed package version instead of chasing upstream 7.0.59 literally. For a LOW verdict there is no SLA (treat as backlog hygiene), but this avoids false-positive churn.

Run this on the target Tomcat host as a user that can read the Tomcat install tree and inspect running processes; root is best, but read access plus ps visibility is usually enough. Invoke it as bash verify_cve_2014_7810.sh /opt/tomcat and it will output VULNERABLE, PATCHED, or UNKNOWN based on Tomcat 7.x version and whether SecurityManager appears enabled.

#!/usr/bin/env bash
# verify_cve_2014_7810.sh
# Checks Apache Tomcat 7.x for CVE-2014-7810 exposure conditions.
# Exit codes:
#   0 = PATCHED / not affected
#   1 = VULNERABLE
#   2 = UNKNOWN / insufficient evidence

set -u

TOMCAT_HOME="${1:-}"
if [[ -z "$TOMCAT_HOME" ]]; then
  echo "UNKNOWN: usage: $0 /path/to/tomcat"
  exit 2
fi

if [[ ! -d "$TOMCAT_HOME" ]]; then
  echo "UNKNOWN: path not found: $TOMCAT_HOME"
  exit 2
fi

version=""

# Method 1: bin/version.sh if present
if [[ -x "$TOMCAT_HOME/bin/version.sh" ]]; then
  version=$("$TOMCAT_HOME/bin/version.sh" 2>/dev/null | awk -F': ' '/Server number/ {print $2; exit}')
fi

# Method 2: RELEASE-NOTES fallback
if [[ -z "$version" && -f "$TOMCAT_HOME/RELEASE-NOTES" ]]; then
  version=$(grep -Eo 'Apache Tomcat Version [0-9]+\.[0-9]+\.[0-9]+' "$TOMCAT_HOME/RELEASE-NOTES" 2>/dev/null | head -n1 | awk '{print $4}')
fi

# Method 3: catalina.jar + ServerInfo fallback (requires java)
if [[ -z "$version" && -f "$TOMCAT_HOME/lib/catalina.jar" && -n "$(command -v java 2>/dev/null)" ]]; then
  version=$(java -cp "$TOMCAT_HOME/lib/catalina.jar" org.apache.catalina.util.ServerInfo 2>/dev/null | awk -F'/| ' '/Server version/ {for (i=1;i<=NF;i++) if ($i ~ /^[0-9]+\.[0-9]+\.[0-9]+$/) {print $i; exit}}')
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN: could not determine Tomcat version"
  exit 2
fi

major=$(echo "$version" | cut -d. -f1)
minor=$(echo "$version" | cut -d. -f2)
patch=$(echo "$version" | cut -d. -f3)

if [[ "$major" != "7" ]]; then
  echo "PATCHED: Tomcat version $version is not in the Tomcat 7.x line checked by this script"
  exit 0
fi

# Only Apache Tomcat 7.0.0 through 7.0.57 are vulnerable upstream.
# Nessus flags < 7.0.59 because 7.0.58 was not released.
if [[ "$minor" -ne 0 ]]; then
  echo "UNKNOWN: unexpected Tomcat 7.x version format: $version"
  exit 2
fi

if (( patch >= 59 )); then
  echo "PATCHED: Tomcat $version is at or above 7.0.59"
  exit 0
fi

if (( patch == 58 )); then
  echo "UNKNOWN: 7.0.58 was not a released upstream build; validate packaging/backport provenance"
  exit 2
fi

# For 7.0.0 - 7.0.57, check whether SecurityManager appears enabled.
sm_enabled=0

# Process inspection
if ps -ef 2>/dev/null | grep -v grep | grep -E "[o]rg\.apache\.catalina\.startup\.Bootstrap|[t]omcat" | grep -Eq '(^| )-security( |$)|-Djava\.security\.manager'; then
  sm_enabled=1
fi

# Config/script inspection
if grep -RqsE '(^|[[:space:]])-security([[:space:]]|$)|-Djava\.security\.manager' \
  "$TOMCAT_HOME/bin" "$TOMCAT_HOME/conf" 2>/dev/null; then
  sm_enabled=1
fi

if (( sm_enabled == 1 )); then
  echo "VULNERABLE: Tomcat $version is in the affected range and SecurityManager appears enabled"
  exit 1
fi

echo "UNKNOWN: Tomcat $version is in the affected version range, but SecurityManager was not confirmed; review service wrappers, systemd units, and startup environment manually"
exit 2

Sources

1. Tenable Nessus Plugin 83764
2. Apache Tomcat 7.x security page
3. NVD CVE-2014-7810
4. Bugtraq disclosure for CVE-2014-7810
5. CISA Known Exploited Vulnerabilities catalog
6. Debian Security Tracker CVE-2014-7810
7. Ubuntu CVE page
8. OpenCVE entry for CVE-2014-7810