Rocky Linux 9 Tomcat Security Update RLSA-2026-68660: Patching and Exploitation Detection Guide

Excerpt: Rocky Linux 9 has shipped a moderate-severity Tomcat security, bug fix, and enhancement update tracked as RLSA-2026-68660. If you run Tomcat workloads on Rocky 9 — and a surprising number of enterprises do, often forgotten inside appliance-style deployments — this advisory warrants a place in this week's patch window, plus a retro-hunt for webshell activity.

Introduction

Red Hat's upstream errata pipeline has pushed another Tomcat update down to the Rocky Linux 9 rebuild, published as RLSA-2026-68660 and rated Moderate severity. The advisory bundles security fixes alongside bug fixes and enhancements for the Tomcat servlet container packages.

Let me be direct about why a "Moderate" advisory still deserves urgency. In 15+ years of incident response, Apache Tomcat has been one of the most consistently exploited pieces of middleware we encounter in compromised environments. It sits internet-facing or one hop behind a reverse proxy, it often runs with more privilege than it should, it frequently ships with the manager application exposed or weakly credentialed, and — critically — it tends to be forgotten. Tomcat instances get deployed as part of a vendor application stack and never enter the organization's regular patch cadence. Attackers know this. A moderate-rated fix in Tomcat is a moderate-rated fix in an asset class that is persistently targeted for initial access and webshell deployment.

This post covers what the advisory means, how Tomcat exploitation actually looks from the defender's side of the glass, and gives you field-tested detection content — Sigma, KQL, and Velociraptor VQL — plus a remediation script you can run today.

Technical Analysis

Affected Products and Platform

• Product: Apache Tomcat (tomcat packages)
• Distribution: Rocky Linux 9 (AppStream repository)
• Advisory: RLSA-2026-68660 — Moderate: tomcat security, bug fix, and enhancement update
• Source: Rocky Linux RLSA-2026-68660 via LinuxSecurity

Rocky Linux advisories mirror Red Hat Enterprise Linux 9 errata, so the underlying fixes correspond to an upstream RHSA of the same cadence. The Tomcat package on EL9-family distributions tracks the Tomcat 9.x branch, providing the servlet container, EL, JSP, and websocket libraries.

Severity and Exploitation Context

The advisory carries a Moderate rating. In Red Hat/Rocky severity taxonomy, Moderate typically maps to flaws that are exploitable but require meaningful preconditions — for example, specific connector configurations (AJP enabled), an authenticated session, non-default settings, or conditions that limit impact to denial of service or information disclosure rather than unauthenticated remote code execution. No CVE identifiers were disclosed in the advisory summary at time of writing, and there is no confirmed in-the-wild exploitation tied to this advisory and no CISA KEV listing associated with it.

That said, do not let the rating drive complacency. Tomcat's real-world risk profile is dominated by how exploitation chains work in practice:

1. Reconnaissance: Attackers enumerate Tomcat by probing :8080, :8443, and the AJP connector on :8009, fingerprinting /manager/html, /host-manager, and default error pages that leak the exact Tomcat version.
2. Initial access: Weak or default manager credentials, an exposed AJP connector, or an unpatched flaw in the servlet container provides the foothold.
3. Execution: The classic endgame is a malicious WAR deployment containing a JSP webshell. The moment that shell is invoked, the Tomcat JVM process spawns /bin/sh, bash, curl, wget, or python — this is the highest-fidelity behavioral signal a defender can ask for, and it is precisely what the detections below target.
4. Persistence and pivot: Webshells in the webapps directory, cron entries, and lateral movement from what is often an under-monitored Linux host.

The defensive lesson of RLSA-2026-68660 is therefore twofold: apply the patch, and verify you would actually see Tomcat exploitation if it happened — because for many organizations, the answer today is no.

Exposure Check

Before patching, inventory your exposure. Any of the following materially raises your risk:

• Tomcat listening on 0.0.0.0:8080/8443 reachable from untrusted networks
• AJP connector (Connector port="8009" protocol="AJP/1.3") enabled without a secret or address binding restriction
• manager or host-manager applications deployed and reachable
• tomcat-users.xml with weak, default, or role-heavy credentials (manager-gui, manager-script)
• Tomcat running as root or as a user with sudo rights (check ps -o user= -C java)

Detection & Response

This is a technical advisory, so the following detections are tuned for the dominant Tomcat exploitation behavior: the Java/Tomcat process spawning unexpected child processes (webshell execution) and suspicious JSP artifacts landing in webapps directories. These are high-fidelity signals — a stock Tomcat servlet container almost never spawns shells or downloads binaries.

Sigma Rules

---
title: Tomcat Java Process Spawning Shell or Command Interpreter
id: 3f8a2b91-7c4e-4d1a-9e6b-2a5c8f0d1e34
status: experimental
description: Detects the Tomcat JVM spawning a shell or scripting interpreter, a hallmark of JSP webshell execution following Tomcat compromise (e.g., malicious WAR deployment).
references:
  - https://linuxsecurity.com/advisories/rockylinux/rocky-linux-rlsa-2026-68660-tomcat-advisories-updates
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.execution
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - '/java'
    ParentCommandLine|contains:
      - 'catalina'
      - 'tomcat'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Rare application integrations that legitimately shell out from Java (e.g., monitoring plugins); baseline per host and allowlist known application paths
level: high
---
title: Tomcat JVM Downloading or Executing Remote Content
id: 8c1d4e72-5a09-4b3f-a2d6-9e7f1c3b5a08
status: experimental
description: Detects curl or wget executed as a child of the Tomcat Java process, consistent with webshell-driven payload retrieval after Tomcat exploitation.
references:
  - https://linuxsecurity.com/advisories/rockylinux/rocky-linux-rlsa-2026-68660-tomcat-advisories-updates
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'catalina'
      - 'tomcat'
  selection_child:
    Image|endswith:
      - '/curl'
      - '/wget'
  condition: selection_parent and selection_child
falsepositives:
  - Health-check or deployment automation that explicitly invokes downloaders from within the Tomcat JVM; uncommon and easily baselined
level: high
---
title: JSP File Created in Tomcat Webapps Directory
id: b2e7f4a1-6d38-4c9e-81a5-4f6d2b9c7e12
status: experimental
description: Detects creation of JSP files in Tomcat webapps or work directories, a strong indicator of webshell deployment via malicious WAR or manager-app upload. JSPs in production should arrive only through controlled deployment pipelines.
references:
  - https://linuxsecurity.com/advisories/rockylinux/rocky-linux-rlsa-2026-68660-tomcat-advisories-updates
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '/tomcat/webapps/'
      - '/tomcat/work/'
      - '/tomcat/webapps/ROOT/'
    TargetFilename|endswith: '.jsp'
  filter_deploy_user:
    User|contains:
      - 'deploy'
      - 'ci-'
  condition: selection and not filter_deploy_user
falsepositives:
  - Legitimate application deployments outside the CI/CD allowlist; tune the filter to your deployment service accounts
level: high

KQL — Microsoft Sentinel / Defender

Tomcat hosts onboarded to Sentinel via the Syslog/CEF connector (or Defender for Endpoint on Linux) can be hunted with the following. It looks for the same core behavior — the Tomcat JVM spawning shells or downloaders — across both process tables, and a second pass on Syslog for Tomcat-related command execution.

// Hunt 1: Tomcat JVM spawning shells, interpreters, or downloaders (Defender for Endpoint on Linux)
let suspiciousChildren = dynamic(["sh", "bash", "dash", "zsh", "python", "python3", "perl", "nc", "ncat", "curl", "wget"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessCommandLine has_any ("catalina", "tomcat")
   or InitiatingProcessFileName has "tomcat"
| where FileName in~ (suspiciousChildren)
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          AccountName, SHA256
| order by TimeGenerated desc;

// Hunt 2: Same behavior via Syslog ingestion (auditd/execve forwarding)
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("catalina", "tomcat")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl", "wget", "python", "ncat")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

// Hunt 3: Network connections to common Tomcat management/AJP ports from unusual sources
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationPort in (8009, 8080, 8443)
| where DeviceAction !in ("Deny", "Drop")
| summarize ConnectionCount = count(), SourceIPs = make_set(SourceIP)
    by DestinationIP, DestinationPort
| order by ConnectionCount desc;

Velociraptor VQL

Use this artifact for fleet-wide hunting on suspected Tomcat hosts. It identifies the running Tomcat JVM and enumerates its child processes and network listeners — exactly what you need to triage for webshell execution and unexpected exposure (e.g., AJP bound to 0.0.0.0).

-- Hunt: Tomcat process tree and listener exposure
-- Identify Tomcat JVMs, their child processes, and listening sockets
LET tomcat_procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'catalina|tomcat'

LET tomcat_pids = SELECT Pid FROM tomcat_procs

SELECT 'tomcat_process' AS FindingType, Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM tomcat_procs
UNION ALL
SELECT 'child_of_tomcat' AS FindingType, Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM tomcat_pids)
   AND Name =~ 'sh|bash|dash|python|perl|curl|wget|nc|ncat'

-- Hunt: Suspicious JSP artifacts in Tomcat webapps directories
-- Flag recently created or modified JSP files outside deployment windows
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/usr/share/tomcat/webapps/**/*.jsp',
                 '/var/lib/tomcat*/webapps/**/*.jsp',
                 '/opt/tomcat*/webapps/**/*.jsp'])
WHERE Mtime > now() - 604800  -- last 7 days
ORDER BY Mtime DESC

Remediation

1. Apply the Update

RLSA-2026-68660 is available through the standard Rocky Linux 9 repositories. Update the Tomcat packages and restart the service — note that Tomcat package updates do not auto-restart the JVM, so the running process will remain on the vulnerable code until restarted.

#!/bin/bash
# RLSA-2026-68660 - Tomcat patch, verification, and baseline hardening
# Run as root or via sudo on Rocky Linux 9

set -euo pipefail

echo "=== [1/5] Current Tomcat package state ==="
rpm -qa | grep -i tomcat || echo "No tomcat packages installed"

echo "=== [2/5] Applying RLSA-2026-68660 update ==="
dnf clean all
dnf updateinfo list --security | grep -i tomcat || true
dnf -y update 'tomcat*'

echo "=== [3/5] Restarting Tomcat to load patched classes ==="
systemctl restart tomcat
sleep 5
systemctl is-active --quiet tomcat && echo "Tomcat service: RUNNING" || { echo "Tomcat FAILED to start"; exit 1; }

echo "=== [4/5] Verifying patched package versions ==="
rpm -qa | grep -i tomcat
dnf updateinfo list --security --installed | grep -i tomcat || true

echo "=== [5/5] Exposure audit ==="
echo "--- Listening sockets (expect 8080/8443; investigate 8009/AJP on 0.0.0.0) ---"
ss -tlnp | grep -E ':(8009|8080|8443)' || echo "No Tomcat ports listening"
echo "--- Tomcat runtime user (should NOT be root) ---"
ps -o user=,comm= -C java | head -5
echo "--- AJP connector check in server.xml ---"
grep -n 'AJP' /etc/tomcat/server.xml 2>/dev/null || echo "No AJP connector defined (good)"
echo "--- Manager/host-manager deployment check ---"
ls -d /usr/share/tomcat/webapps/manager /usr/share/tomcat/webapps/host-manager 2>/dev/null \
  || echo "Manager apps not deployed (good)"
echo "--- Recent JSP files in webapps (retro-webshell check) ---"
find /usr/share/tomcat/webapps /var/lib/tomcat*/webapps -name '*.jsp' -mtime -30 2>/dev/null \
  || echo "No JSP files modified in the last 30 days"

echo "=== Done. Review the audit output above and address any findings. ==="

2. Configuration Hardening (Defense in Depth)

Regardless of the specific flaw addressed, these changes shrink the Tomcat attack surface dramatically:

• Remove or restrict the manager/host-manager apps. If they are not operationally required, delete them. If required, restrict by IP via a RemoteAddrValve in the context and enforce strong, unique credentials in tomcat-users.xml. Never grant manager-script to a GUI user.
• Disable or bind the AJP connector to localhost if you are not fronting Tomcat with mod_jk/mod_proxy_ajp. If AJP is required, set a strong secret attribute.
• Suppress version disclosure. Set server=" " on connectors and configure an ErrorReportValve with showServerInfo="false" and showReport="false" so error pages do not fingerprint your exact build for attackers.
• Run Tomcat as a dedicated unprivileged user with no sudo rights, and set NoNewPrivileges=true and ProtectSystem=strict in the systemd unit where application compatibility allows.
• Restrict outbound egress from Tomcat hosts. A servlet container rarely needs to initiate arbitrary outbound connections; blocking egress neuters most webshell payload-retrieval and C2 behavior.

3. Retro-Hunt Before You Patch

Patching first destroys evidence. If any Tomcat host was internet-exposed and unpatched, run the VQL hunts and the KQL queries above before the update, and snapshot suspicious JSP files for analysis (hash them, preserve timestamps, do not simply delete them). A JSP with a recent mtime that nobody on your team deployed is an incident, not a cleanup task.

4. Ongoing

• Subscribe to Rocky Linux security announcements and mirror errata into your vulnerability management platform so EL9 advisories like RLSA-2026-68660 auto-generate tickets.
• Ensure Tomcat hosts forward auditd execve events and application logs to your SIEM — the detections in this post are useless if the telemetry never leaves the box.
• There is currently no CISA KEV deadline associated with this advisory; it is not listed as known-exploited. Remediate within your standard Moderate-severity SLA, but prioritize any internet-facing instance.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub