SUSE Advisory 2026-23985-1: Critical Apache Tomcat WebSocket Flaws Patched — Detection and Remediation Guide for Linux Defenders

SUSE has published security update 2026-23985-1, addressing 15 vulnerabilities in Apache Tomcat — including critical issues in the WebSocket implementation — across its supported Linux distributions. If your organization runs Java applications on SUSE Linux Enterprise Server (SLES) or openSUSE with Tomcat exposing WebSocket endpoints, this is a patch-now event, not a patch-eventually event.

Fifteen CVEs bundled into a single advisory is a signal worth paying attention to. Tomcat is one of the most widely deployed Java servlet containers on the planet, and WebSocket handling sits directly in the exposed attack surface of internet-facing applications. In my experience, application server flaws like these become initial access vectors within weeks of public disclosure — sometimes days — because the exploit surface is uniform, the protocol is well documented, and scanning for vulnerable Tomcat instances is trivially easy.

What SUSE Fixed

The advisory (SUSE-2026-23985-1, published via LinuxSecurity) delivers updated Tomcat packages that resolve 15 distinct vulnerabilities plus one additional bug fix. The headline issues center on Tomcat's WebSocket implementation — the component responsible for maintaining persistent, full-duplex connections between clients and the server per RFC 6455.

While SUSE's advisory summary does not enumerate each CVE identifier in the public headline, the pattern of fixes is consistent with the class of WebSocket flaws that have plagued Tomcat: improper state handling during connection upgrade, inadequate validation of frame boundaries, and resource management failures that allow remote, unauthenticated attackers to trigger denial-of-service conditions or bypass security constraints. These are exactly the kinds of flaws that don't require credentials, don't require user interaction, and don't leave much of a footprint beyond the connection itself — which makes detection engineering harder and patching more urgent.

Affected Products

The update applies to Tomcat packages shipped with SUSE's supported distributions, including SUSE Linux Enterprise Server and openSUSE variants that track the affected package stream. Any host where tomcat (or tomcat10, depending on the distribution stream) is installed from SUSE repositories and has not yet received this update should be treated as vulnerable.

Common exposure scenarios we see in client environments:

• Internet-facing Tomcat instances fronting Java web applications, often behind a reverse proxy (Apache httpd, nginx) that forwards WebSocket upgrade requests.
• Internal application servers running vendor appliances or in-house apps that embed Tomcat — frequently forgotten, rarely patched, and reachable from flat internal networks.
• CI/CD and management tooling that bundles Tomcat (build servers, artifact repositories, monitoring dashboards).

Don't assume your reverse proxy saves you. WebSocket traffic traverses the proxy by design — an HTTP Upgrade: websocket header passes straight through to the backend container in most default configurations.

How These Attacks Work (Defender's View)

WebSocket vulnerabilities in Tomcat typically follow one of three exploitation patterns:

1. Denial of service via malformed frames or connection floods. An attacker sends crafted WebSocket frames — or opens large numbers of half-completed upgrade handshakes — causing thread exhaustion, memory exhaustion, or infinite loops in the frame-parsing logic. Tomcat's default thread pool becomes saturated, and legitimate traffic stops being served. No authentication required.

2. Security constraint bypass. Flaws in how Tomcat handles the HTTP-to-WebSocket upgrade can allow requests to slip past authentication or authorization filters configured in web.xml or container-managed security, because the upgraded connection may no longer be subject to the same filter chain as standard HTTP requests.

3. Request smuggling / desync conditions. When Tomcat sits behind a proxy, inconsistent handling of upgrade requests and frame boundaries can create desynchronization between what the proxy sees and what Tomcat processes — a foothold for cache poisoning or request smuggling against co-hosted applications.

All three patterns share a critical trait: the attacker only needs network reachability to the Tomcat listener (typically TCP 8080, 8443, or whatever port is published via the proxy). There is no payload to detonate on the endpoint, no malware to catch with EDR — just protocol abuse.

Exploitation Status

At the time of this writing, there is no confirmed public reporting of mass exploitation tied specifically to this SUSE advisory. However, historical precedent with Tomcat WebSocket and HTTP parsing flaws is not encouraging: public proof-of-concept code for comparable Tomcat issues has consistently appeared within days to weeks of patch release, and internet-wide scanners (both research-driven and criminal) enumerate Tomcat version banners aggressively. Organizations should treat these flaws as likely to be weaponized and prioritize accordingly — especially for internet-facing instances. Check CISA's Known Exploited Vulnerabilities catalog over the coming weeks; Tomcat CVEs have landed there before.

Detection and Response

Because WebSocket exploitation in Tomcat is primarily a protocol-level and resource-exhaustion problem, your detection strategy should focus on three observable layers: anomalous connection behavior at the network layer, Tomcat process resource anomalies at the host layer, and post-exploitation behavior (a compromised Java process doing things a servlet container should never do).

The last category is your highest-fidelity signal. A Tomcat JVM spawning shells, writing files outside its webapp directories, or initiating outbound connections to unusual destinations is a strong indicator of successful exploitation — whether via these WebSocket flaws or any other Tomcat vector.

Sigma Rules

---
title: Apache Tomcat JVM Spawning Shell or Command Interpreter
id: 3c8f2a91-7b4e-4d52-a6c1-9e0f5b8d2a47
status: experimental
description: Detects the Tomcat Java process spawning shell interpreters or command execution tools, a strong indicator of post-exploitation following compromise of the servlet container (e.g., via WebSocket or HTTP parsing flaws).
references:
  - https://linuxsecurity.com/advisories/suse/suse-2026-23985-1-tomcat
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.execution
  - attack.t1190
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/java'
      - '/java.exe'
    ParentCommandLine|contains:
      - 'catalina'
      - 'tomcat'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate application functionality invoking system commands (rare; validate per-application baseline)
  - Tomcat manager or administrative scripts in tightly controlled maintenance windows
level: high
---
title: Tomcat Webapp Directory File Write by Java Process
id: 8d1e4c73-2f6a-4b91-9c38-5a7d0e2f4b19
status: experimental
description: Detects the Tomcat JVM writing executable or script files outside expected deployment paths, consistent with webshell deployment after exploitation of a Tomcat vulnerability.
references:
  - https://linuxsecurity.com/advisories/suse/suse-2026-23985-1-tomcat
  - 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:
    Image|endswith: '/java'
    TargetFilename|contains:
      - '/webapps/'
      - '/tomcat/'
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.war'
      - '.sh'
      - '.py'
  filter_legit_deploy:
    TargetFilename|contains:
      - '/tomcat/temp/'
      - '/tomcat/work/'
      - '/tomcat/logs/'
  condition: selection and not filter_legit_deploy
falsepositives:
  - Automated CI/CD deployments of WAR/JSP files (correlate with deployment pipeline activity)
  - Application functionality that writes JSP templates at runtime (uncommon; baseline and tune)
level: high
---
title: Excessive Concurrent WebSocket Connections to Tomcat Listener
id: 5f2a9d84-6c1b-4e07-b3a2-8d6c1f9e0a35
status: experimental
description: Detects a single source establishing an abnormal volume of connections to Tomcat service ports, consistent with WebSocket connection-flood denial-of-service attempts against vulnerable Tomcat instances.
references:
  - https://linuxsecurity.com/advisories/suse/suse-2026-23985-1-tomcat
  - https://attack.mitre.org/techniques/T1498/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1498
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationPort:
      - 8080
      - 8443
      - 8009
    Image|endswith: '/java'
  condition: selection
falsepositives:
  - Load balancer health checks (exclude known LB source IPs)
  - Legitimate high-volume WebSocket applications (tune threshold at the SIEM aggregation layer; alert on >50 connections from a single source within 60 seconds)
level: medium

A note on the third rule: the Sigma network_connection logsource gives you the raw telemetry, but the real fidelity comes from your SIEM's aggregation logic. Tune thresholds against your application's normal WebSocket concurrency before enabling.

KQL — Microsoft Sentinel / Defender

Even for Linux-hosted Tomcat, most enterprise SOC teams hunt this telemetry in Sentinel via Syslog/CEF ingestion or Defender for Endpoint on Linux. This query hunts for the post-exploitation pattern — Tomcat spawning unexpected child processes — plus a companion query for WebSocket flood behavior at the network layer.

// Hunt 1: Tomcat JVM spawning suspicious child processes (post-exploitation indicator)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "java"
   or InitiatingProcessCommandLine has_any ("catalina", "tomcat")
| where FileName in~ ("sh", "bash", "dash", "python", "python3", "perl", "curl", "wget", "nc", "ncat", "base64")
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, InitiatingProcessId, ProcessId
| order by TimeGenerated desc

// Hunt 2: Single source with abnormally high connection volume to Tomcat ports (WebSocket flood / DoS)
DeviceNetworkEvents
| where TimeGenerated > ago(1h)
| where RemotePort in (8080, 8443, 8009)
| where InitiatingProcessFileName =~ "java" or LocalPort in (8080, 8443, 8009)
| summarize ConnectionCount = count(), DistinctRemoteIPs = dcount(RemoteIP) by RemoteIP, DeviceName, LocalPort, bin(TimeGenerated, 5m)
| where ConnectionCount > 100
| order by ConnectionCount desc

// Hunt 3: Syslog-ingested Tomcat hosts showing JVM restarts or OOM events (possible DoS impact)
Syslog
| where TimeGenerated > ago(24h)
| where Computer has "tomcat" or ProcessName has_any ("java", "tomcat", "catalina")
| where SyslogMessage has_any ("OutOfMemoryError", "WebSocket", "Upgrade failed", "thread pool", "RejectedExecutionException", "SEVERE")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc

Velociraptor VQL

For DFIR triage on a suspected-compromised Tomcat host, this artifact identifies the Tomcat JVM's child processes, recently written webshell candidates, and live network connections to the service ports — the three things you need to answer "did they get in, and what did they drop?"

-- Triage Tomcat hosts: child processes of the JVM, recent webapp file writes, and active listener connections
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (CommandLine =~ 'catalina|tomcat' AND Name =~ 'java')
   OR getppid(pid=Pid) IN (
       SELECT Pid FROM pslist() WHERE CommandLine =~ 'catalina|tomcat'
   )

-- Identify recently modified JSP/script files in Tomcat webapp directories (webshell candidates)
SELECT FullPath, Size, Mtime, Atime, Ctime
FROM glob(globs=['/usr/share/tomcat*/webapps/**/*.jsp', '/var/lib/tomcat*/webapps/**/*.jsp', '/opt/tomcat*/webapps/**/*.jsp', '/srv/tomcat*/webapps/**/*.jsp'])
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

-- Enumerate established connections to Tomcat service ports for source-IP analysis
SELECT Pid, Name, LocalAddress, LocalPort, RemoteAddress, RemotePort, State
FROM netstat()
WHERE LocalPort IN (8080, 8443, 8009)
  AND State =~ 'ESTAB'

Remediation and Verification Script

Use this Bash script to inventory Tomcat package state, apply the SUSE update, verify the patched version, and confirm service health across your SLES/openSUSE estate.

#!/bin/bash
# SUSE-2026-23985-1 Tomcat patch verification and remediation
# Run with root privileges on SLES / openSUSE hosts

set -euo pipefail

echo "=== [1] Identify installed Tomcat packages ==="
rpm -qa | grep -i tomcat || echo "No tomcat packages found."

echo "=== [2] Check for the pending security update ==="
zypper list-patches --category security | grep -i -E "tomcat|23985" || echo "Advisory not listed via zypper patch feed; check package update directly."

echo "=== [3] Apply the update ==="
# Preferred: apply only the security patch for this advisory
zypper patch --category security --non-interactive || true
# Fallback: update tomcat packages directly
zypper update --non-interactive tomcat tomcat-lib tomcat-webapps tomcat-admin-webapps 2>/dev/null || \
zypper update --non-interactive 'tomcat*' 2>/dev/null || echo "Verify package names for your distribution stream (tomcat vs tomcat10)."

echo "=== [4] Restart Tomcat to load patched classes ==="
systemctl restart tomcat 2>/dev/null || systemctl restart tomcat10 2>/dev/null || echo "Restart Tomcat manually — service name not standard."

echo "=== [5] Verify the patched version and service health ==="
rpm -qa | grep -i tomcat
systemctl is-active tomcat 2>/dev/null || systemctl is-active tomcat10 2>/dev/null
# Confirm listener is back up
ss -tlnp | grep -E ':(8080|8443|8009)' || echo "WARNING: Tomcat listener not detected."

echo "=== [6] Quick posture checks ==="
# Ensure Tomcat is not running as root
ps -o user= -C java | sort -u
# Review catalina logs for WebSocket-related errors since restart
journalctl -u tomcat --since "-30 min" 2>/dev/null | grep -i -E "websocket|SEVERE|OutOfMemory" || echo "No WebSocket errors in recent journal."

echo "=== Done. Reboot is not required for Tomcat package updates, but JVM restart is mandatory. ==="

Two operational notes: first, the JVM restart is not optional — patched classes on disk do nothing until the running JVM reloads them. Second, if you run vendor appliances that embed Tomcat (check /opt, /srv, and vendor install trees), the SUSE system package update will not touch them. Inventory embedded instances separately and open tickets with those vendors.

Remediation Priority

1. Patch internet-facing Tomcat instances within 72 hours. Fifteen CVEs in one advisory, with critical WebSocket issues called out, warrants an emergency change window for anything reachable from untrusted networks.
2. Patch internal and embedded instances within your standard critical-vuln SLA (7–14 days), prioritizing hosts reachable from user segments and anything handling regulated data.
3. Apply defense-in-depth while you patch:
   • Restrict access to Tomcat's AJP connector (port 8009) — it should be bound to localhost or explicitly firewalled. AJP has its own history of critical flaws and should never be network-exposed.
   • If your application does not use WebSockets, disable the WebSocket servlet (org.apache.tomcat.websocket.server.WsSci) in the application's configuration or block Upgrade: websocket headers at the reverse proxy until patching is complete.
   • Enforce connection-rate limiting at your reverse proxy or WAF for WebSocket upgrade requests.
   • Ensure Tomcat runs as an unprivileged dedicated service account with systemd sandboxing (ProtectSystem=strict, NoNewPrivileges=true, PrivateTmp=true).
4. Hunt retroactively. Run the process-spawn and webshell-detection queries above across at least the last 30 days. WebSocket and HTTP parsing flaws are attractive pre-disclosure targets, and a clean patch today doesn't erase a compromise from last week.
5. Verify CISA KEV status for the individual CVEs in this advisory as they are enumerated; KEV-listed flaws carry mandated remediation timelines for federal agencies and should drive equivalent urgency in the private sector.

Reference: SUSE-2026-23985-1 via LinuxSecurity and the corresponding SUSE support channel for your subscription stream.

The Bottom Line

Tomcat advisories bundling double-digit CVE counts are not routine hygiene — they are a snapshot of where attacker research effort is concentrated. WebSocket handling is an increasingly targeted component precisely because it maintains long-lived stateful connections that bypass many of the stateless inspection assumptions baked into perimeter defenses. Patch the package, restart the JVM, verify the listener, and then go hunting. If your team lacks the telemetry or the cycles to do that retrohunt across a large Linux estate, that's exactly the gap a managed detection program should be closing.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub