CVE-2026-34486 — Apache Tomcat Tribes EncryptInterceptor Fail-Open

Attacker objective: unauthenticated code execution as the Tomcat service account on a clustered Java application server, then hands-on-keyboard expansion — reverse shells, a lightweight Linux dropper, tunnelling tooling and persistence.

Root cause (get this right, it drives every detection below): the February 2026 fix for CVE-2026-29146 — a padding-oracle weakness in the Tribes EncryptInterceptor — restructured the encryption manager and, in doing so, moved the super.messageReceived(msg) call from inside the try/catch that handles decryption to outside it. Before the change a decryption failure threw, the catch block logged it, and the message was dropped. After the change the failure is logged and the original attacker-controlled bytes are forwarded up the chain anyway, into a bare ObjectInputStream.readObject() with no class filtering. Fail-closed became fail-open. Anyone who can reach the Tribes receiver (default TCP/4000, no authentication) can send a raw unencrypted serialized Java gadget payload; with Commons Collections 3.x or a comparable gadget library on the classpath — routine in Spring and Hibernate applications — that payload runs commands as the Tomcat user.

The only local trace is a single SEVERE: Failed to decrypt message line. No deserialization error is raised. That log line is the single highest-value native artefact in this pack.

Am I even exposed? This is the question that matters most here, and it is genuinely narrow. The Tribes receiver only listens when clustering is enabled, and the vulnerable path only exists when EncryptInterceptor is configured in the channel. A single-node Tomcat is not affected at all. Exactly three builds carry the regression: 11.0.20, 10.1.53 and 9.0.116. Scoping exposure is cheaper and more decisive than any of the behavioural queries below — do section 7 first, then hunt.

Highest-value defensive angle: a Java/Tomcat process spawning a shell or interpreter. Deserialization RCE has no distinctive payload on the wire that endpoint telemetry sees, but the child process it creates is unmistakable — a JVM serving HTTP has no business executing /bin/sh, curl or cmd.exe. Queries Q1 and Q2 carry most of the detection weight in this pack.

Defender priority for 2026-08-07: the CISA KEV federal remediation deadline is today. Patch to 11.0.21 / 10.1.54 / 9.0.117 or later on any of the three affected builds; if you cannot patch this hour, block TCP/4000 at the network edge and between Kubernetes namespaces, because the receiver requires no authentication and a public PoC has been circulating since mid-April 2026.

Ten sources were fetched and snapshotted verbatim on 2026-08-07 into Tomcat-Tribes-CVE-2026-34486-Hunt-sources/. Every claim in this pack traces to one of them.

Honest note on the severity disagreement. Apache, NVD and Red Hat all frame this as a confidentiality issue — an encryption bypass, CVSS 7.5, C:H/I:N/A:N. The unauthenticated-RCE framing comes from the mechanism analysis (Cyber Kendra) plus observed exploitation (Unit 42's "Java deserialization reverse shell attempts"). Both are true and they are not in conflict: the CVE as scored is a protection-mechanism bypass, and the practical consequence of that bypass on a classpath carrying deserialization gadgets is code execution. CISA-ADP itself scored it 9.8 then walked it back to 7.5 within 24 hours. Treat the RCE path as real but conditional on gadget availability, and say so to stakeholders rather than quoting a single number.

Prompt-injection check: none of the ten fetched pages contained instructions directed at an automated reader — no attempts to redirect fetching, alter these instructions, or steer indicator selection. The Unit 42 article quotes an attacker's LLM session verbatim (for example "Search for larger-scale vulns"); those quotes are reported attacker output being analysed, not instructions to this pipeline, and were treated as data.

Hunt hypotheses (ordered by fidelity)

Attack chain

This pack ships zero atomic indicators, and that is the correct outcome. No hash, IP address or domain tied to the CVE-2026-34486 exploitation vector appears in any of the ten sources snapshotted for this pack. Unit 42 published no infrastructure for the Tomcat vector (their indicators cover the actor's own AI-tooling proxies, which never appear victim-side). The SNOWLIGHT sample hashes sit behind SOCRadar's 403, so they were not retrieved and are not reproduced here on faith. Everything below is behavioural and is what the queries in section 8 actually key on.

Be honest about hit likelihood. The population of hosts that satisfy every exposure condition — one of exactly three builds, clustering on, EncryptInterceptor configured, port 4000 reachable — is small in most estates. A clean hunt here is the expected result and is not evidence the hunt was ineffective. The value of this pack is disproportionately in section 7 (scoping) rather than in a query firing.

Run these first. They answer "am I exposed?" in minutes and cost nothing, and N1 is the highest-fidelity artefact in the entire pack.

N1 · The exploitation artefact in catalina.out

Failed decryption is logged at SEVERE and then the message is forwarded anyway. This line is present for both failed and successful exploitation, and it should be extremely rare in a healthy cluster (a genuine key mismatch produces it too, which is itself worth knowing about).

grep -rn "Failed to decrypt message" /opt/tomcat/logs/ /var/log/tomcat*/ 2>/dev/null

# Ship it to the SIEM as a standing rule. Any occurrence on a build of
# 11.0.20, 10.1.53 or 9.0.116 is an exploitation attempt until proven otherwise.
# On a patched build the same line means a real key/config mismatch -- still
# worth a ticket, but not an incident.

N2 · Exposure scoping — is the Tribes receiver even listening?

# Linux: who is bound to 4000, and is it a JVM?
ss -lntp | grep -w 4000
lsof -nP -iTCP:4000 -sTCP:LISTEN

# Windows:
netstat -ano | findstr ":4000"

N3 · Configuration scoping — clustering and EncryptInterceptor

# Is a Cluster configured at all? No Cluster element = not affected.
grep -rn "Cluster" /opt/tomcat/conf/server.xml

# Is EncryptInterceptor in the channel? This is the vulnerable component.
grep -rn "EncryptInterceptor" /opt/tomcat/conf/server.xml

# Which build is running? Only 11.0.20, 10.1.53 and 9.0.116 are affected.
/opt/tomcat/bin/version.sh | grep -i "server number"

N4 · Webshell sweep under the Tomcat tree

# JSP/JSPX written in the last 30 days outside a known release window.
find /opt/tomcat/webapps /opt/tomcat/work/Catalina -type f \
     \( -name "*.jsp" -o -name "*.jspx" -o -name "*.war" \) -mtime -30 -ls

# Files owned by the tomcat account in unexpected places.
find /tmp /dev/shm /var/tmp -user tomcat -type f -ls 2>/dev/null

N5 · Kubernetes east-west exposure

Cyber Kendra's analysis is explicit that in a namespace with no NetworkPolicy, any pod can reach port 4000 on every Tomcat node. Confirm whether a default-deny policy exists before assuming the cluster port is internal.

kubectl get networkpolicy --all-namespaces
kubectl get pods -n YOUR_NAMESPACE -o wide
# Absence of any NetworkPolicy in a namespace running clustered Tomcat means
# the Tribes receiver is reachable by every workload in that namespace.

N6 · Persistence review on any host that scoped in

crontab -l -u tomcat
ls -la /etc/cron.d/ /etc/cron.daily/
systemctl list-unit-files --state=enabled | tail -40
cat /home/tomcat/.ssh/authorized_keys 2>/dev/null
stat /home/tomcat/.ssh/authorized_keys 2>/dev/null

No query below carries an in-query time filter. Set the window in the Falcon console instead — @timestamp compared against an expression does not parse in CQL, and a broken first line silently kills the whole query.

// HUNT: Tomcat/Java parent spawning a shell or interpreter (Linux)
// MITRE: T1190, T1059.004, T1105 | CONF: high  FP: medium  COST: low
// REQUIRES: Falcon Linux sensor, process execution telemetry
// FALSE POSITIVES: Jenkins/GitLab runners, Ansible deploys, JMX health checks that fork
// TUNING: exclude build and packaging hosts by aid, then exclude FileName=/^(sh|bash)$/i
// TUNING: where CommandLine matches your own deployment wrapper script name
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(java|javaw|jsvc|catalina\.sh|tomcat)$/i
| FileName=/^(sh|bash|dash|zsh|ksh|curl|wget|python3?|perl|ruby|nc|ncat|socat|busybox)$/i
| table([ComputerName, aid, UserName, ParentBaseFileName, FileName, CommandLine, ProcessStartTime])

// HUNT: java.exe / javaw.exe spawning a Windows command shell or script host
// MITRE: T1190, T1059.001, T1059.003 | CONF: high  FP: medium  COST: low
// REQUIRES: Falcon Windows sensor, process execution telemetry
// FALSE POSITIVES: Java/JRE installers, Jenkins agent JVMs, Tomcat service wrapper restarts
// TUNING: exclude ParentCommandLine matching your agent jar path and your patching tool,
// TUNING: and drop certutil/bitsadmin from FileName if a legacy deploy job uses them
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(java|javaw|jsvc|tomcat\d*|tomcat\d*w)(\.exe)?$/i
| FileName=/^(cmd|powershell|pwsh|wscript|cscript|mshta|certutil|bitsadmin|curl)(\.exe)?$/i
| table([ComputerName, aid, UserName, ParentBaseFileName, FileName, CommandLine, ParentCommandLine])

// HUNT: Inbound connection accepted on the Tribes receiver port (TCP/4000)
// MITRE: T1190, T1210 | CONF: medium  FP: medium  COST: medium
// REQUIRES: Falcon network telemetry (NetworkReceiveAcceptIP4)
// FALSE POSITIVES: legitimate cluster peers inside RFC1918, load-balancer health checks
// TUNING: the cidr exclusion below is a first pass. Once you know your node set,
// TUNING: replace it with an explicit allowlist of your own cluster node addresses,
// TUNING: because a compromised peer inside RFC1918 is exactly what this must still catch.
#event_simpleName=/^NetworkReceiveAcceptIP4$/
| LocalPort = 4000
| !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "169.254.0.0/16", "100.64.0.0/10"])
| groupBy([ComputerName, aid, LocalAddressIP4, LocalPort, RemoteAddressIP4], function=count(as=Accepts))

// HUNT: EXPOSURE SCOPING -- hosts with a listener bound on the Tribes receiver port
// MITRE: T1190 (scoping) | CONF: medium  FP: low  COST: low
// REQUIRES: Falcon network telemetry (NetworkListenIP4)
// FALSE POSITIVES: non-Tomcat services that also bind 4000
// TUNING: confirm ContextBaseFileName is a JVM before treating a row as a Tomcat cluster node
#event_simpleName=/^NetworkListenIP4$/
| LocalPort = 4000
| groupBy([ComputerName, aid, LocalAddressIP4, LocalPort, ContextBaseFileName], function=count(as=Binds))

// HUNT: EXPOSURE SCOPING -- running Tomcat JVMs and their install paths
// MITRE: T1190 (scoping) | CONF: medium  FP: medium  COST: medium
// REQUIRES: Falcon process telemetry on all platforms
// FALSE POSITIVES: embedded Tomcat in Spring Boot fat jars, non-Tomcat JVMs on a shared classpath
// TUNING: to jump straight to the affected builds, append this stage --
// TUNING:   | CommandLine=/apache-tomcat-(11\.0\.20|10\.1\.53|9\.0\.116)/i
// TUNING: only those three builds carry the regression; 8.5 and earlier lack the component
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(java|javaw|jsvc)(\.exe)?$/i
| CommandLine=/(catalina\.home|catalina\.base|org\.apache\.catalina\.startup\.Bootstrap)/i
| groupBy([ComputerName, aid, UserName, FileName, CommandLine], function=count(as=Starts))

// HUNT: executable or JAR written under a Tomcat webapps / work / install path
// MITRE: T1505.003, T1105 | CONF: medium  FP: medium  COST: low
// REQUIRES: file-write telemetry (ELFFileWritten, JarFileWritten, PeFileWritten)
// FALSE POSITIVES: WAR deployment, JSP precompilation into work/Catalina, patching runs
// TUNING: exclude ContextBaseFileName of your deployment tooling (ansible, mvn, unzip, rsync)
// TUNING: and suppress the query entirely during scheduled release windows
#event_simpleName=/^(ELFFileWritten|JarFileWritten|PeFileWritten|NewExecutableWritten)$/
| TargetFileName=/(tomcat|catalina|webapps|work\/Catalina)/i
| table([ComputerName, aid, UserName, TargetFileName, ContextBaseFileName, SHA256HashData])

// HUNT: SNOWLIGHT-style dropper -- ELF binary written to a world-writable temp path
// MITRE: T1105, T1059.004 | CONF: medium  FP: medium  COST: low
// REQUIRES: Falcon Linux sensor, ELFFileWritten telemetry
// FALSE POSITIVES: dpkg/rpm/dnf/apt unpacking, containerd image extraction, self-extracting installers
// TUNING: exclude ContextBaseFileName=/^(dpkg|rpm|yum|dnf|apt|apt-get|containerd|dockerd|snapd)$/i
// TUNING: then rank what remains by shortest file lifetime -- a self-deleting binary is the signal
#event_simpleName=/^ELFFileWritten$/
| TargetFileName=/^\/(tmp|dev\/shm|var\/tmp|run\/shm)\//
| table([ComputerName, aid, UserName, TargetFileName, ContextBaseFileName, SHA256HashData])

// HUNT: chmod/chattr against a world-writable temp path (dropper being armed)
// MITRE: T1222.002 | CONF: medium  FP: medium  COST: low
// REQUIRES: Falcon Linux sensor, process execution telemetry
// FALSE POSITIVES: installer and build scripts chmod'ing their own extracted temp files
// TUNING: intersect with the host list from Q4/Q5 -- outside the Tomcat cluster this is pure noise
// TUNING: and exclude ParentBaseFileName of your configuration-management agent
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(chmod|chattr)$/i
| CommandLine=/\/(tmp|dev\/shm|var\/tmp|run\/shm)\//
| table([ComputerName, aid, UserName, ParentBaseFileName, FileName, CommandLine])

// HUNT: persistence written by a Tomcat-owned process -- cron, systemd unit, authorized_keys
// MITRE: T1053.003, T1543.002, T1098.004 | CONF: high  FP: low  COST: low
// REQUIRES: Falcon Linux sensor, process execution telemetry with UserName resolution
// FALSE POSITIVES: configuration management (Ansible, Puppet, Chef) running as the service account
// TUNING: exclude ParentBaseFileName of your config-management agent; if that agent legitimately
// TUNING: manages tomcat cron entries, scope this query to authorized_keys and systemd only
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| UserName=/^(tomcat\d*|catalina|jboss|www-data)$/i
| CommandLine=/(crontab|systemctl\s+enable|systemctl\s+daemon-reload|authorized_keys|\/etc\/cron|\/etc\/systemd\/system)/i
| table([ComputerName, aid, UserName, ParentBaseFileName, FileName, CommandLine, ProcessStartTime])

// HUNT: tunnelling / reverse-shell tooling executed on a Tomcat host
// MITRE: T1572, T1090, T1059.004 | CONF: medium  FP: high  COST: medium
// REQUIRES: Falcon process execution telemetry
// FALSE POSITIVES: sanctioned admin tunnels, jump-host workflows, monitoring agents using socat
// TUNING: MANDATORY -- scope to the aid list produced by Q4/Q5 before triaging, and allowlist
// TUNING: your break-glass jump hosts by aid. Estate-wide this query is noise, not detection.
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(frpc|frps|chisel|ngrok|gost|socat|nc|ncat|netcat|iox|ew|stowaway)$/i
| CommandLine=/(-R\s|-L\s|-e\s*\/bin\/|reverse|remote_port|server_addr|listen)/i
| table([ComputerName, aid, UserName, ParentBaseFileName, FileName, CommandLine])

Three queries are clean enough to promote to a Custom IOA. The rest stay Investigate-only.

Investigate-only (do not promote)

• Q3, Q4, Q5 — scoping and inventory queries. They are meant to produce rows, not alerts. Q4 in particular should be run once and turned into an asset list.
• Q6, Q7, Q8 — medium FP by nature; useful as correlation legs inside an investigation, not as standalone triggers. Their value is the intersection with Q1 on the same host in the same window.
• Q10 — high FP. Never promote. Scope to the Q4/Q5 host list and run it manually during an investigation.

Deployment path: Falcon console → Endpoint security → Custom IOA rule groups → new Process Creation rule group scoped to a host group containing only the assets Q4 and Q5 identified. Scoping the IOA to the Tomcat cluster rather than the whole estate is what keeps Q1 and Q2 at a workable alert volume.

Read before importing. The CSV block below contains placeholders only. This threat is IOC-light in public reporting and no atomic indicator for the Tomcat vector appears in any source snapshot saved for this pack. Do not import placeholder rows, and do not populate them from an uncited blog — replace them only with indicators you recover from your own incident or from a vendor report you have read yourself.

type,value,action,severity,expiration,description,tags
# BEHAVIOUR-LED PACK. No atomic indicator for CVE-2026-34486 exploitation is
# published in any source snapshotted on 2026-08-07. The rows below are shaped
# placeholders so the import format is ready when you have real values.
# Delete any row you cannot source. Never import a REPLACE_WITH value.
sha256,REPLACE_WITH_DROPPER_SHA256,detect,critical,2027-02-07,SNOWLIGHT-class dropper recovered from your own incident,cve:CVE-2026-34486
sha256,REPLACE_WITH_WEBSHELL_SHA256,detect,critical,2027-02-07,Webshell recovered from webapps or work/Catalina,cve:CVE-2026-34486
ipv4,REPLACE_WITH_TRIBES_SCANNER_IP,hunt,high,2026-11-07,Source seen connecting to TCP/4000 from outside the cluster node set,cve:CVE-2026-34486
domain,REPLACE_WITH_C2_DOMAIN,detect,high,2027-02-07,C2 recovered from a compromised Tomcat host,cve:CVE-2026-34486

BEHAVIOUR  parent=java|javaw|jsvc|catalina.sh  child=sh|bash|curl|wget|python|perl|nc
BEHAVIOUR  parent=java.exe|javaw.exe          child=cmd.exe|powershell.exe|wscript.exe
BEHAVIOUR  accepted inbound TCP/4000 from a source outside the cluster node set
BEHAVIOUR  ELF written to /tmp, /dev/shm, /var/tmp then chmod +x then executed then deleted
BEHAVIOUR  JSP / JAR written under webapps/ or work/Catalina outside a release window
BEHAVIOUR  user=tomcat* running crontab, systemctl enable, or editing authorized_keys
BEHAVIOUR  tunnelling binary (frpc, chisel, gost, socat, ncat) on a host that binds 4000
LOGSTRING  "SEVERE: Failed to decrypt message" in catalina.out  -- the exploitation artefact
CONFIG     server.xml contains both a Cluster element and EncryptInterceptor
VERSION    Apache Tomcat 11.0.20 or 10.1.53 or 9.0.116  -- the only affected builds

MALWARE   SNOWLIGHT           lightweight C-based Linux dropper / loader
TOOL      GoCobaltStrike      cracked Chinese Cobalt Strike derivative
TOOL      (unnamed)           two tunnelling tools on the adversary staging server
ACTOR     knaithe / KnYuan    Chinese-speaking operator, Zhuhai; DeepSeek via Hermes Agent
ACTOR     (unattributed)      China-nexus SNOWLIGHT operator, 100+ countries, Apr-Jun 2026
FRAMEWORK Hermes Agent        autonomous orchestration with Telegram-based C2

# No hashes, IPs or domains are listed here on purpose. The SNOWLIGHT sample
# details sit behind a source that returned HTTP 403 and were never retrieved.
# Family names are safe to record; unverified indicators are not.

# 1. Which build?   Affected: 11.0.20, 10.1.53, 9.0.116   Fixed: 11.0.21, 10.1.54, 9.0.117
/opt/tomcat/bin/version.sh | grep -i "server number"

# 2. Clustering on?  No Cluster element means you are NOT affected.
grep -c "Cluster" /opt/tomcat/conf/server.xml

# 3. EncryptInterceptor configured?  This is the vulnerable component.
grep -c "EncryptInterceptor" /opt/tomcat/conf/server.xml

# 4. Receiver listening?
ss -lntp | grep -w 4000

# 5. Exploitation artefact present?
grep -c "Failed to decrypt message" /opt/tomcat/logs/catalina.out

# Any host answering yes to 1+2+3 is in scope. Patch to 11.0.21 / 10.1.54 /
# 9.0.117 or later. Going to 11.0.25 / 10.1.58 / 9.0.121 also clears the
# July 2026 Tomcat issues in the same maintenance window.

Playbook 1 — Emergency network containment of the Tribes receiver (Linux)

Prerequisites: root or sudo on the Tomcat host; the address list of your legitimate cluster peers; a maintenance note filed, because a wrong peer list breaks session replication. Reboot required: no. Rollback: stated inline at each step.

# STEP 1 -- record the current state so rollback is exact.
sudo iptables-save > /root/iptables.backup.2026-08-07
# Rollback for the whole playbook: sudo iptables-restore < /root/iptables.backup.2026-08-07

# STEP 2 -- allow only your own cluster peers to reach 4000.
# Replace PEER_ADDR with each real node address, one rule per peer.
sudo iptables -A INPUT -p tcp --dport 4000 -s PEER_ADDR -j ACCEPT

# STEP 3 -- drop everything else to 4000.
sudo iptables -A INPUT -p tcp --dport 4000 -j DROP
# Rollback: sudo iptables -D INPUT -p tcp --dport 4000 -j DROP

# STEP 4 -- verify the cluster still replicates before you walk away.
sudo iptables -L INPUT -n --line-numbers | grep 4000
grep -i "member added\|memberDisappeared" /opt/tomcat/logs/catalina.out | tail -20
# If peers start disappearing, the peer list in STEP 2 is wrong. Roll back
# STEP 3 immediately, fix the list, then re-apply.

Playbook 2 — Patch to a fixed build (Linux, package or tarball)

Prerequisites: a tested rollback artefact (the current Tomcat directory or package version pinned); a maintenance window; confirmation from Q4/Q5 that this host is genuinely in scope. Reboot required: no — a Tomcat service restart only. Rollback: restore the saved directory and restart, detailed below.

# STEP 1 -- confirm the running build is one of the three affected.
/opt/tomcat/bin/version.sh | grep -i "server number"
# Affected: 11.0.20, 10.1.53, 9.0.116. Anything else -- stop, you are not in scope.

# STEP 2 -- snapshot the current install and config. This IS the rollback artefact.
sudo systemctl stop tomcat
sudo tar czf /root/tomcat-preupgrade-2026-08-07.tgz /opt/tomcat

# STEP 3 -- deploy the fixed build.
#   Minimum:   11.0.21 / 10.1.54 / 9.0.117
#   Preferred: 11.0.25 / 10.1.58 / 9.0.121  (also clears the July 2026 issues)
# Use your package manager where the distro ships Tomcat, otherwise unpack the
# release tarball alongside and repoint the symlink.

# STEP 4 -- restore conf/ and start.
sudo systemctl start tomcat
/opt/tomcat/bin/version.sh | grep -i "server number"
grep -i "server startup" /opt/tomcat/logs/catalina.out | tail -3

# Rollback: sudo systemctl stop tomcat
#           sudo rm -rf /opt/tomcat
#           sudo tar xzf /root/tomcat-preupgrade-2026-08-07.tgz -C /
#           sudo systemctl start tomcat

Playbook 3 — Default-deny NetworkPolicy for a clustered Tomcat namespace

Prerequisites: a CNI that enforces NetworkPolicy (Calico, Cilium, or equivalent — with a non-enforcing CNI this manifest applies cleanly and does nothing); the pod label selector for your Tomcat deployment; apply to a non-production namespace first. Reboot required: no. Rollback: kubectl delete networkpolicy for both objects, shown below.

# STEP 1 -- confirm the namespace currently has NO policy (this is the exposure).
kubectl get networkpolicy -n YOUR_NAMESPACE

# STEP 2 -- default-deny all ingress in the namespace.
cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: YOUR_NAMESPACE
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
EOF

# STEP 3 -- allow 4000 ONLY between the Tomcat pods themselves.
cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-tribes-intra-cluster
  namespace: YOUR_NAMESPACE
spec:
  podSelector:
    matchLabels: {app: tomcat}
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels: {app: tomcat}
      ports:
        - protocol: TCP
          port: 4000
EOF

# STEP 4 -- verify replication survived.
kubectl logs -n YOUR_NAMESPACE -l app=tomcat --tail=50 | grep -i member

# Rollback: kubectl delete networkpolicy allow-tribes-intra-cluster -n YOUR_NAMESPACE
#           kubectl delete networkpolicy default-deny-ingress -n YOUR_NAMESPACE
# Delete the allow policy FIRST is wrong -- delete default-deny first if the
# app is down, since that is the object that can black-hole traffic.

Playbook 4 — JVM-wide deserialization filter (defence in depth)

Prerequisites: a JDK supporting JEP 290 serialization filtering (JDK 9 or later, and backported into later 8u releases); a non-production node; an inventory of the classes your application legitimately deserializes. Reboot required: no — a Tomcat restart only. Rollback: remove the line from setenv.sh and restart, shown below.

# STEP 1 -- start in REPORT-ONLY posture on a test node. Do not go straight to
# a blocking filter in production; an over-tight filter breaks session
# replication in a way that looks like a network fault.
sudo cp /opt/tomcat/bin/setenv.sh /root/setenv.sh.backup.2026-08-07

# STEP 2 -- add a conservative reject-list filter. Start by rejecting the
# best-known gadget packages, keeping everything else allowed.
echo 'CATALINA_OPTS="$CATALINA_OPTS -Djdk.serialFilter=!org.apache.commons.collections.functors.*;!org.apache.commons.collections4.functors.*;!com.sun.org.apache.xalan.**;*"' \
  | sudo tee -a /opt/tomcat/bin/setenv.sh

# STEP 3 -- restart and soak for a full business cycle on the test node.
sudo systemctl restart tomcat
grep -i "serialfilter\|filter status: REJECTED" /opt/tomcat/logs/catalina.out | tail -20

# STEP 4 -- only after a clean soak, tighten toward an allowlist of the classes
# your application actually needs, and roll to the rest of the cluster one node
# at a time.

# Rollback: sudo cp /root/setenv.sh.backup.2026-08-07 /opt/tomcat/bin/setenv.sh
#           sudo systemctl restart tomcat

Do not skip phase 0. On most estates it will conclude that nothing is in scope, and that conclusion — documented, with the query output attached — is a legitimate and complete answer to the KEV deadline. Running phases 1 through 5 against hosts that were never clustered burns the response budget on hosts that were never reachable.

Validation gates summary. Four of the twelve rows above are outright gaps and three more are partial, which is an honest reflection of a vulnerability whose exploitation leaves almost nothing on the endpoint until the payload runs. The pack's strength is concentrated in the post-exploitation rows (T1059.*, T1053/T1543/T1098) where coverage is genuinely good, and in the scoping queries that tell you whether any of it applies. Work section 11's gates in order before promoting anything: telemetry ready, log ingest, benign baseline, then the two safe positive tests. A pack that fires nothing on an estate with no clustered Tomcat has not failed — it has answered the question.

Defensive content only. This pack deliberately contains no exploit code and no link to any proof-of-concept repository. Public PoCs for this CVE exist and are offensive tooling; they were not fetched, run or reproduced. The mechanism is described at the level needed to build detections and nothing further.