← Back to Feed CACHED · 2026-08-05 12:14:36 · CACHE_KEY CVE-2026-34486
CVE-2026-34486 · CWE-311 · Disclosed 2026-04-09

Missing Encryption of Sensitive Data vulnerability in Apache Tomcat due to the fix for CVE-2026-29146…

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

Apache fixed a lock on the back door, but the fix left the door propped open with a brick

CVE-2026-34486 is a regression introduced by the fix for CVE-2026-29146 (a padding oracle in the Tribes EncryptInterceptor). The patch switched encryption modes but inadvertently caused the EncryptInterceptor to fail open — when decryption fails, the message is accepted and processed anyway instead of being dropped. An attacker who can reach the Tribes receiver port (default TCP/4000) can send a crafted Java deserialization payload that bypasses encryption entirely, achieving unauthenticated remote code execution. Affected versions are *exactly one release per branch*: 9.0.116, 10.1.53, and 11.0.20. Fixed in 9.0.117, 10.1.54, and 11.0.21 respectively.

The vendor rated this Important / HIGH (7.5) with a confidentiality-only CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), which undersells the real impact — public PoCs demonstrate full RCE, not just data leakage. However, the 7.5 is partially justified by the heavy prerequisite stack: Tribes clustering must be enabled, EncryptInterceptor must be configured, port 4000 must be reachable, and deserialization gadgets must exist on the classpath. The biggest mitigant is the *absurdly narrow version window* — only organizations that patched CVE-2026-29146 but stopped one version short are exposed. Despite that, CISA added this to the KEV on August 4, 2026 after a Chinese threat actor was caught autonomously scanning and exploiting it across 460+ targets.

"KEV-listed RCE regression hits only one Tomcat version per branch — narrow but actively hunted"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify Tomcat Tribes listener

The attacker scans for TCP/4000 (default Tribes receiver port) on internet-facing or internal network segments. The port responds to Tribes protocol handshakes, confirming a clustered Tomcat deployment. Automated scanners like the Hermes Agent framework observed in the wild can enumerate this at scale.
Conditions required:
  • Target runs Tomcat 9.0.116, 10.1.53, or 11.0.20
  • Tomcat Tribes clustering is enabled
  • TCP/4000 (or custom Tribes port) is network-reachable
Where this breaks in practice:
  • Tribes clustering is an opt-in feature; most Tomcat deployments are standalone
  • Port 4000 is rarely exposed to the internet; typically bound to a backend VLAN
  • Only one version per branch is affected — the regression window is days to weeks
Detection/coverage: Shodan/Censys queries for Tribes protocol on TCP/4000; GreyNoise may tag scanning activity
STEP 02

Confirm EncryptInterceptor fail-open

The attacker sends an unencrypted Tribes message to the receiver. In a patched or unaffected version, the EncryptInterceptor would reject the message. In the vulnerable version, the interceptor fails open and passes the plaintext message through for processing. No authentication or key material is required.
Conditions required:
  • EncryptInterceptor is configured in server.xml (otherwise there is no encryption to bypass — but also no deserialization gate)
Where this breaks in practice:
  • If EncryptInterceptor was never configured, messages were always plaintext — but this also means the cluster was already exposed to deserialization attacks regardless of this CVE
Detection/coverage: Network IDS signatures can detect unencrypted Tribes protocol messages when EncryptInterceptor should be active
STEP 03

Send deserialization payload

The attacker crafts a serialized Java object using a gadget chain (e.g., Commons Collections 6 / CC6 as used in the striga-ai PoC) and sends it as a Tribes cluster message. The Tomcat Tribes receiver deserializes the payload without encryption validation. This achieves arbitrary code execution as the Tomcat process user.
Conditions required:
  • Vulnerable deserialization gadget libraries on the classpath (e.g., commons-collections, commons-beanutils)
  • Tomcat process has sufficient OS privileges for attacker's objective
Where this breaks in practice:
  • Modern Tomcat versions have reduced default gadget surface
  • JEP 290 deserialization filters may block some gadget chains if configured
  • Application-specific classpaths vary — not all deployments include exploitable gadgets
Detection/coverage: EDR/HIDS can detect unexpected child processes spawned by the Tomcat JVM; RASP solutions can intercept dangerous deserialization patterns
STEP 04

Post-exploitation

With code execution as the Tomcat user, the attacker pivots laterally. In the observed campaign, the knaithe/KnYuan actor used autonomous AI-driven tooling (DeepSeek via Hermes Agent) to chain exploitation across multiple targets. The Tomcat process often has access to database credentials, internal APIs, and session data.
Conditions required:
  • Successful RCE from step 3
Where this breaks in practice:
  • Container-isolated Tomcat deployments limit lateral movement
  • Network segmentation between app tier and data tier constrains blast radius
Detection/coverage: Behavioral EDR, container runtime security, and anomalous outbound connection monitoring
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationActive. CISA added CVE-2026-34486 to the KEV catalog on August 4, 2026. Chinese-speaking threat actor *knaithe/KnYuan* (Zhuhai, China) exploited this across 460+ targets using the Hermes Agent framework with DeepSeek AI as an autonomous operator. THN report
Proof of ConceptPublic. Multiple PoCs: striga-ai/CVE-2026-34486 (original researcher Bartlomiej Dmitruk), 404-src/CVE-2026-34486. Both demonstrate CC6 gadget chain → RCE via TCP/4000.
EPSS0.42627 — top 1% of all CVEs by exploitation probability. Extremely high signal.
KEV StatusListed August 4, 2026. CISA remediation deadline for FCEB agencies: August 7, 2026 (2-day window).
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5) — vendor vector covers confidentiality loss only. Real-world PoCs demonstrate integrity+availability impact via RCE, suggesting the true vector is closer to 9.8.
Affected VersionsExactly one version per branch: 9.0.116, 10.1.53, 11.0.20. These are the releases that contained the incomplete fix for CVE-2026-29146.
Fixed Versions9.0.117, 10.1.54, 11.0.21 — released April 4, 2026. Distro backports: check RHEL (Bugzilla #2457027), Debian, Ubuntu trackers.
Exposure SurfaceTribes clustering runs on TCP/4000 by default. This port is rarely internet-facing — most clusters communicate over backend VLANs. No published Shodan/Censys counts, but the narrow version window limits the exposed population significantly.
Disclosure TimelineReported to Apache Security Team: March 26, 2026. Public disclosure: April 9, 2026. KEV listing: August 4, 2026 (~4 months post-patch).
ReporterBartlomiej Dmitruk from striga.ai
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.0/10)

The single most decisive factor is the active KEV listing with confirmed nation-state exploitation, which overrides the narrow version window and clustering prerequisite that would otherwise push this toward MEDIUM. The fail-open-to-RCE chain requires no authentication, and public PoCs make exploitation trivial for any attacker who can reach TCP/4000.

HIGH Vulnerability mechanics and affected version range
HIGH Active exploitation confirmed via CISA KEV
MEDIUM Proportion of Tomcat deployments running Tribes clustering

Why this verdict

  • KEV override: CISA added this to the KEV on August 4, 2026 with a 2-day remediation deadline for federal agencies. Active exploitation by a named threat actor (knaithe/KnYuan) using AI-augmented autonomous scanning across 460+ targets eliminates any theoretical-only risk argument.
  • Unauthenticated RCE with public PoC: Despite the vendor's C:H-only CVSS vector, the striga-ai and 404-src PoCs demonstrate full code execution via CC6 deserialization gadgets. The real impact is RCE, not just information disclosure.
  • Narrow version window (downward pressure): Only one version per branch (9.0.116, 10.1.53, 11.0.20) is affected. Organizations that skipped CVE-2026-29146's patch or already upgraded past it are not vulnerable. This dramatically shrinks the exposed population.
  • Clustering prerequisite (downward pressure): Tribes clustering is an opt-in configuration. The majority of Tomcat deployments are standalone or use external session stores (Redis, Memcached). The fraction running Tribes with EncryptInterceptor is small — likely single-digit percentages of all Tomcat installs.
  • Role multiplier: Tomcat instances in clustered configurations tend to be production application servers (typical role: line-of-business tier). In high-value roles — e.g., Tomcat fronting identity services, internal APIs with database credentials, or CI/CD artifact serving — RCE gives the attacker a pivot into backend data tiers. This is a *host-to-tenant* blast radius in most deployments, occasionally *tenant-to-domain* where the Tomcat service account has AD credentials. The clustering use-case itself signals production-grade deployment, making the affected population higher-value on average than a random Tomcat instance.

Why not higher?

Despite the KEV listing and RCE impact, CRITICAL is not warranted because the affected population is *extraordinarily narrow* — exactly one version per branch, requiring opt-in Tribes clustering with EncryptInterceptor, reachable port 4000, and classpath gadgets. Tomcat is not a canonically high-value-role component (it is not a domain controller, hypervisor, identity provider, or security agent). The blast radius is host-to-tenant, not fleet-scale.

Why not lower?

Active exploitation confirmed by CISA KEV with a named threat actor and 460+ observed targets makes anything below HIGH indefensible. The EPSS score of 0.43 (top 1%) independently corroborates real-world weaponization. The attack is unauthenticated and requires no user interaction, with multiple public PoCs lowering the barrier to entry for copycat attackers.

05 · Compensating Control

What to do — in priority order.

  1. Block TCP/4000 at the network boundary immediately — Firewall rules or security group changes to ensure the Tribes receiver port is only reachable from other cluster members on a dedicated VLAN. This is the single fastest mitigation — deploy within hours given the KEV listing. Even without this CVE, Tribes ports should never be internet-facing.
  2. Apply the vendor patch (9.0.117 / 10.1.54 / 11.0.21) — The definitive fix. These versions restore proper EncryptInterceptor enforcement. Given the KEV listing, patch immediately — do not wait for a maintenance window. The patch has been available since April 4, 2026.
  3. Configure JEP 290 deserialization filters — Add -Djdk.serialFilter to restrict deserialization to known-safe classes. This blocks the CC6 gadget chain used in public PoCs. Deploy within the noisgate mitigation SLA of 30 days as a defense-in-depth layer even after patching.
  4. Audit classpath for unnecessary gadget libraries — Remove or update commons-collections, commons-beanutils, and other known deserialization gadget sources from the Tomcat classpath if not required by your application. Reduces the exploitability of this and future deserialization flaws.
  5. Monitor for anomalous Tomcat child processes — EDR rules or auditd policies to alert on the Tomcat JVM spawning shells, curl, wget, or other unexpected child processes. Detects post-exploitation activity even if the initial exploit lands.
What doesn't work
  • WAF / reverse proxy in front of HTTP ports — this vulnerability targets the Tribes clustering port (TCP/4000), not the HTTP/HTTPS ports (8080/8443). WAF rules have zero visibility into Tribes protocol traffic.
  • TLS termination at the load balancer — TLS on the HTTP listener does not encrypt Tribes cluster communication, which uses a separate channel and protocol.
  • Upgrading to a newer Tomcat major version without checking the specific patch level — e.g., moving from 9.x to 10.x does not help if you land on 10.1.53, which is the affected version in that branch.
06 · Verification

Crowdsourced verification payload.

Run this script on each Tomcat host to check the installed version against the three affected releases. Execute as any user with read access to the Tomcat installation directory. Example: bash check_cve_2026_34486.sh /opt/tomcat

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_34486.sh — Detect CVE-2026-34486 (Tomcat EncryptInterceptor bypass)
# Usage: bash check_cve_2026_34486.sh [CATALINA_HOME]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

CATALINA_HOME="${1:-${CATALINA_HOME:-/opt/tomcat}}"
VERSION_FILE="$CATALINA_HOME/lib/catalina.jar"

if [ ! -f "$VERSION_FILE" ]; then
  echo "UNKNOWN — catalina.jar not found at $CATALINA_HOME/lib/catalina.jar"
  exit 2
fi

# Extract version from ServerInfo.properties inside catalina.jar
VERSION=$(unzip -p "$VERSION_FILE" org/apache/catalina/util/ServerInfo.properties 2>/dev/null | grep 'server.number=' | cut -d= -f2 | tr -d '[:space:]')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not extract version from catalina.jar"
  exit 2
fi

echo "Detected Tomcat version: $VERSION"

# Check against the three affected versions
case "$VERSION" in
  9.0.116|10.1.53|11.0.20)
    echo "VULNERABLE — $VERSION is affected by CVE-2026-34486"
    # Additionally check if Tribes clustering is configured
    SERVER_XML="$CATALINA_HOME/conf/server.xml"
    if [ -f "$SERVER_XML" ]; then
      if grep -qi 'Cluster' "$SERVER_XML" && grep -qi 'EncryptInterceptor' "$SERVER_XML"; then
        echo "WARNING — Tribes clustering with EncryptInterceptor is configured. RCE is possible if port 4000 is reachable."
      elif grep -qi 'Cluster' "$SERVER_XML"; then
        echo "NOTE — Clustering enabled but EncryptInterceptor not found. Cluster was already unencrypted (pre-existing risk)."
      else
        echo "NOTE — Clustering does not appear enabled in server.xml. Exploitation requires Tribes clustering."
      fi
    fi
    exit 1
    ;;
  *)
    echo "PATCHED — $VERSION is not one of the three affected releases (9.0.116, 10.1.53, 11.0.20)"
    exit 0
    ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
This is a KEV-listed, actively exploited vulnerability — act now, not Monday. Although only three specific Tomcat versions are affected (9.0.116, 10.1.53, 11.0.20), CISA's August 4 KEV listing with a 2-day federal deadline signals urgency. If you run Tribes clustering on any of these versions, treat this as an emergency: block TCP/4000 from untrusted networks within hours and patch to 9.0.117 / 10.1.54 / 11.0.21 immediately. The patch has been available since April — if you haven't applied it in four months, close that gap today. For the majority of shops running standalone Tomcat on unaffected versions, verify your version with the script above, document that you are not affected, and move on. Per the noisgate mitigation SLA for HIGH, compensating controls should be in place within 30 days and the noisgate remediation SLA requires patching within 180 days — but the active KEV listing overrides both timelines to *patch or mitigate immediately, within hours*.

Sources

  1. Apache Tomcat 11 Security Advisories
  2. Apache Tomcat 9 Security Advisories
  3. The Hacker News — CISA Flags Tomcat Flaw as Actively Exploited
  4. striga-ai PoC — CVE-2026-34486
  5. Field Effect — Public Exploit Code for Tomcat Clustering Flaw
  6. Red Hat Bugzilla — CVE-2026-34486
  7. CyberSecurity News — Tomcat EncryptInterceptor Bypass
  8. HeroDevs — Apache Tomcat CVE Round-Up April 2026
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.