CVE-2026-66713: Apache Axis2/Java RCE Vulnerability

CVE-2026-66713 Overview

CVE-2026-66713 is a deserialization of untrusted data vulnerability [CWE-502] in the Tribes-based clustering component of Apache Axis2/Java through version 2.0.0 running on Apache Tomcat. An unauthenticated remote attacker with network access to the clustering port can execute arbitrary code by delivering a crafted serialized Java object to the cluster channel. The malicious payload is deserialized in org.apache.axis2.clustering.tribes.Axis2ChannelListener#messageReceived, triggering code execution in the context of the Axis2 process. The clustering feature is disabled by default, so only deployments that explicitly enable Tribes clustering are exposed.

Critical Impact
Unauthenticated remote code execution against Apache Axis2/Java servers with Tribes clustering enabled, delivered via a crafted serialized Java object to the cluster channel.

Affected Products

Apache Axis2/Java through version 2.0.0
Apache Axis2/Java deployments running on Apache Tomcat with Tribes clustering enabled
The axis2-clustering module

Discovery Timeline

2026-07-28 - CVE-2026-66713 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-66713

Vulnerability Analysis

Apache Axis2/Java ships an optional clustering module built on Apache Tribes, a group communication framework that exchanges Java-serialized messages between cluster members over a TCP channel. When clustering is enabled, Axis2ChannelListener registers to receive inbound cluster messages and processes them in its messageReceived handler. That handler passes attacker-controlled bytes to Java object deserialization without validating the payload origin, sender identity, or class allowlist.

Any host that can reach the cluster port can therefore submit a serialized gadget chain that executes on the receiver during object reconstruction. This is a canonical Java deserialization RCE pattern: exploitation does not require authentication, does not require a valid cluster membership, and does not require any application-level Axis2 request. The fix in version 2.0.1 removes the clustering feature entirely rather than attempting to sanitize input, which reflects the difficulty of safely deserializing arbitrary Java objects in a distributed context.

Root Cause

The root cause is unsafe deserialization of untrusted network input in org.apache.axis2.clustering.tribes.Axis2ChannelListener#messageReceived. The listener treats bytes arriving on the Tribes channel as trusted intra-cluster traffic and reconstructs them into Java objects using standard ObjectInputStream semantics. Because the Java class path of an Axis2/Tomcat deployment typically includes gadget-friendly libraries, attackers can craft serialized graphs whose deserialization side effects lead to arbitrary command execution.

Attack Vector

An attacker needs network reachability to the Tribes clustering port on the Axis2 server. No credentials, no Axis2 web service call, and no user interaction are required. The attacker connects to the cluster channel, sends a crafted serialized Java object, and the vulnerable listener deserializes it and triggers gadget execution. Deployments that expose the clustering port to untrusted networks are directly exploitable; internal-only deployments remain exposed to lateral movement from any compromised host on the same segment.

java

// Patch excerpt: modules/adb/src/org/apache/axis2/rpc/receivers/RPCInOnlyMessageReceiver.java
// AXIS2-6097 Remove Clustering feature
                        methodElement,inMessage);

            }
-            replicateState(inMessage);
        } catch (InvocationTargetException e) {
            Throwable cause = e.getCause();
            if (cause != null) {

Source: Apache Axis2 Java Core commit e6f53b2

The upstream fix also removes the axis2-clustering dependency from the build:

text

// Patch excerpt: apidocs/pom.xml
             <version>${project.version}</version>
             <classifier>sources</classifier>
         </dependency>
-        <dependency>
-            <groupId>${project.groupId}</groupId>
-            <artifactId>axis2-clustering</artifactId>
-            <version>${project.version}</version>
-        </dependency>

Source: Apache Axis2 Java Core commit e6f53b2

Detection Methods for CVE-2026-66713

Indicators of Compromise

Inbound TCP connections to the Tribes clustering port from hosts that are not authorized cluster members.
Java exceptions or stack traces referencing org.apache.axis2.clustering.tribes.Axis2ChannelListener or ObjectInputStream.readObject in Axis2 or Tomcat logs.
Unexpected child processes spawned by the Tomcat or Axis2 JVM, such as shells, curl, wget, or scripting interpreters.
Presence of the axis2-clustering JAR on Axis2 servers combined with a non-default axis2.xml that enables the <cluster> element.

Detection Strategies

Inventory Axis2/Java deployments and flag any instance running version 2.0.0 or earlier with clustering enabled in axis2.xml.
Alert on network connections to the configured Tribes port originating outside the documented cluster member list.
Monitor Tomcat JVMs for deserialization gadget behavior, including unexpected process execution, outbound connections, or file writes originating from the Axis2 process.

Monitoring Recommendations

Capture and retain JVM process ancestry and command lines for hosts running Axis2 on Tomcat to support post-exploitation triage.
Enable verbose logging around Axis2ChannelListener and Tribes channel events until the upgrade to 2.0.1 is complete.
Feed Axis2, Tomcat, and network flow telemetry into a centralized data lake so cluster-port traffic can be correlated with process activity across hosts.

How to Mitigate CVE-2026-66713

Immediate Actions Required

Upgrade Apache Axis2/Java to version 2.0.1, which removes the clustering feature and eliminates the vulnerable code path.
If an immediate upgrade is not possible, disable Tribes clustering in axis2.xml by removing or commenting the <cluster> configuration and restart Tomcat.
Restrict network access to the Tribes clustering port using host firewalls or network ACLs so that only authorized cluster members can reach it.
Audit exposed Axis2 servers for prior compromise, focusing on unexpected JVM child processes and outbound connections.

Patch Information

The Apache Software Foundation fixed this issue in Apache Axis2/Java 2.0.1 by removing the clustering feature entirely, as tracked in issue AXIS2-6097. The upstream commit removes the axis2-clustering module dependency and the replicateState invocation in RPCInOnlyMessageReceiver. Details are available in the Apache Axis2 Java Core commit e6f53b2, the Apache announcement thread, and the OpenWall oss-security discussion.

Workarounds

Disable Tribes clustering in Axis2 configuration until version 2.0.1 is deployed.
Block inbound traffic to the Tribes clustering port from any host outside the trusted cluster membership.
Where clustering must remain enabled temporarily, terminate the cluster channel on a dedicated management VLAN with strict segmentation.

bash

# Example: block external access to the default Tribes cluster port on Linux
# Adjust the port to match your <receiver> configuration in axis2.xml
iptables -A INPUT -p tcp --dport 4000 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 4000 -j DROP

# Verify no unauthorized listeners are reachable
ss -ltnp | grep -E '4000|java'