Apache Tomcat 7

This finding maps to CVE-2015-5346, a Tomcat session fixation bug caused by the requestedSessionSSL field not being recycled correctly when Tomcat reuses a Request object. For Tomcat 7, Apache says the affected range is 7.0.5 through 7.0.65; the fix shipped in 7.0.67 because the 7.0.66 release candidate never became a formal release. The bug matters only when at least one deployed application is configured to use the SSL session ID as the HTTP session ID, which Apache explicitly says is uncommon.

The vendor-style CVSS 8.1 / High overstates enterprise risk here. Apache itself rated it Low, and the vendor note explains why: the attacker cannot force the victim onto the 'correct' recycled Request object, so exploitation depends on both a rare configuration and a hard-to-control runtime condition. In practice this is not a front-door internet RCE; it is a narrow session hijack edge case with weak evidence of operational abuse.

Why this verdict

• Baseline down from 8.1/High: Apache, the product maintainer, rates this issue Low and explicitly calls exploitation hard.
• Major prerequisite friction: exploitation requires at least one webapp configured to use the SSL session ID as the HTTP session ID, which Apache says is not a common configuration.
• Runtime control is weak: the attacker cannot force the victim onto the needed recycled Request object, so success depends on timing and connector reuse behavior rather than a reliable request/response primitive.
• Impact is session hijack, not server compromise: even if it works, the outcome is application-session takeover with blast radius limited to the victim account or app context.
• Threat intel is quiet: no KEV listing, no reviewed campaign reporting, and Tenable still notes no known exploits.

Why not higher?

This does not behave like a clean unauthenticated remote exploit. The attack chain narrows sharply at each stage: uncommon configuration, timing-sensitive object reuse, and the need to convert fixation into a real victim-authenticated session. That is too much friction for a HIGH or CRITICAL operational priority.

Why not lower?

It is still a genuine remotely reachable security flaw in public-facing middleware, and the end state can be session hijacking of legitimate users. If you run legacy Tomcat with unusual session handling, the bug is not theoretical enough to ignore completely.

1. Use cookie-only session tracking — Disable any application pattern that binds the HTTP session to the SSL session ID rather than normal cookie rotation. This directly removes the unusual prerequisite that makes CVE-2015-5346 matter; for a LOW verdict there is no SLA, so do this during normal hardening and configuration review.
2. Rotate sessions on authentication — Ensure applications issue a fresh session identifier after login and privilege changes. That breaks the fixation-to-hijack transition even if a stale pre-auth session were influenced; for a LOW verdict, fold this into routine app-security hygiene rather than emergency change windows.
3. Keep Tomcat admin surfaces internal — Limit Manager and Host Manager access to internal admin networks and authenticated operators only. It does not fix this CVE directly, but it reduces adjacent session abuse opportunities on the same legacy Tomcat estate; apply in the normal maintenance cycle.
4. Shorten session lifetime for sensitive apps — Short session TTLs, re-authentication on sensitive actions, and device/risk checks reduce the value of any hijacked application session. This is a sensible hardening step for internet-facing Tomcat applications where patching is delayed.

Run this on the target Tomcat host with local read access to the Tomcat installation. Invoke it as sudo bash check_cve_2015_5346.sh /opt/tomcat (replace with your CATALINA_HOME or CATALINA_BASE); root is not strictly required unless Tomcat files are permission-restricted. The script prints only VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check_cve_2015_5346.sh
# Determine likely exposure to CVE-2015-5346 for upstream Apache Tomcat 7.
# Outputs exactly one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET="${1:-${CATALINA_HOME:-${CATALINA_BASE:-}}}"

if [[ -z "$TARGET" || ! -d "$TARGET" ]]; then
  echo "UNKNOWN"
  exit 2
fi

# If this looks like a distro-managed install, version strings may be backported and misleading.
if command -v dpkg-query >/dev/null 2>&1; then
  if dpkg-query -W -f='${Package}\n' 2>/dev/null | grep -Eq '^(tomcat7|tomcat8|tomcat9|libtomcat)'; then
    echo "UNKNOWN"
    exit 2
  fi
fi
if command -v rpm >/dev/null 2>&1; then
  if rpm -qa 2>/dev/null | grep -Eiq '^(tomcat|apache-tomcat|jboss-web-server)'; then
    echo "UNKNOWN"
    exit 2
  fi
fi

version=""

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

# Fallback to RELEASE-NOTES / RUNNING.txt / manifest-like files.
if [[ -z "$version" ]]; then
  for f in "$TARGET/RELEASE-NOTES" "$TARGET/RUNNING.txt" "$TARGET/lib/catalina.jar"; do
    if [[ -r "$f" ]]; then
      v=$(strings "$f" 2>/dev/null | grep -Eo '7\.0\.[0-9]+' | head -n1)
      if [[ -n "$v" ]]; then
        version="$v"
        break
      fi
    fi
  done
fi

if [[ ! "$version" =~ ^7\.0\.[0-9]+$ ]]; then
  echo "UNKNOWN"
  exit 2
fi

patch=${version##*.}

# CVE-2015-5346 affects Tomcat 7.0.5 through 7.0.65 inclusive.
# 7.0.66 was a failed release candidate; upstream fixed release is 7.0.67.
if (( patch >= 5 && patch <= 65 )); then
  echo "VULNERABLE"
  exit 1
fi

if (( patch >= 67 )) || (( patch >= 0 && patch <= 4 )); then
  echo "PATCHED"
  exit 0
fi

# Any oddball 7.0.66 or unparseable edge case: treat as unknown for manual review.
echo "UNKNOWN"
exit 2

Sources

1. Tenable plugin 121118
2. Apache Tomcat 7 security advisory
3. NVD CVE-2015-5346
4. Ubuntu CVE tracker
5. Debian security tracker
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS API documentation
8. Shodan facet showing exposed Tomcat banners