Axis2 CVE-2026-66713 Rates 9.8 But Only Hits a Default-Off Feature

On July 28, 2026, a vulnerability tracked as CVE-2026-66713 was published for Apache Axis2/Java, the Java toolkit used to build SOAP-style web services. The score shown on the US vulnerability database NVD is 9.8 out of 10 (Critical). That band means an attacker needs no login and no password, and can run any program of their choosing on the server.

On the number alone, this is as bad as it gets. But the advisory published by the Apache Software Foundation spells out the precondition very clearly: it only applies if a feature called "Tribes clustering" is turned on, and that feature ships turned off. The severity Apache itself wrote on the record was "low".

So there are two kinds of readers here: those who should genuinely go pale at 9.8, and those who can check one line in a configuration file and move on. This article starts with how to work out which group you are in, then covers what actually happens if you are affected, which release fixes it, and why "9.8" and "low" ended up sitting side by side.

What was published, and what numbers came with it

CVE-2026-66713: data arriving on the cluster channel is turned straight into running code

Apache Axis2/Java has a "clustering" feature that lets several servers run the same service and keep their state in sync. The transport underneath it was Tribes, a library that came from Tomcat.

Axis2 took messages arriving over Tribes and rebuilt them into objects using Java serialization. The entry point for that rebuild is org.apache.axis2.clustering.tribes.Axis2ChannelListener#messageReceived. Because nothing validated the incoming payload there, an attacker who sends a crafted object gets their own code executed during the rebuild. That is the whole of CVE-2026-66713. The CVE record says the same thing, and names the required position: "an unauthenticated remote attacker with network access to the clustering port".

The entry point is not the HTTP SOAP endpoint that clients talk to. It is the separate port that servers use to talk to each other, and that shapes the whole character of this flaw. If clustering is not running, that port is not open in the first place.

Automated sweeps find it first, people arrive after

The people who pick this up first are volume intruders who mechanically hammer every server on the internet and only put a human on the boxes that answered back. Not targeted, sophisticated crews. Their job is to start running a probe for a CVE number the day after it is published. A flaw like this one, where a specific port is either open or not and the response tells you which, suits that mechanical sweeping rather well.

On a server whose cluster listener answered back, the routine that follows is to install their own way back in, make sure they can keep operating that server, and then sell that access to a different attacker. If the buyer runs ransomware, the server becomes a foothold for pushing deeper into the internal network. If the buyer trades in data, the first move is lifting the database credentials the server holds.

When a server carrying the integrations between business systems is taken over, what people notice depends on where they sit. For the staff and business partners who use the system, it surfaces as work stopping or records being altered. For the people who run it, it means the full privileges of the host Axis2 runs on now belong to somebody else. Axis2 usually sits where it talks directly to core databases, so losing it is not "one web server was compromised". Which is exactly why the check in the next section is worth doing first.

Are you affected, and where do you look

The check ends at one place in the Axis2 configuration file axis2.xml. The path depends on how you deployed: for the common case of a WAR dropped into Tomcat it is WEB-INF/conf/axis2.xml, and for a standalone install conf/axis2.xml. Inside it, find the <clustering> element.

What the shipped file looks like can be confirmed in axis2.xml in the Axis2 repository. It is this one line.

<clustering class="org.apache.axis2.clustering.tribes.TribesClusteringAgent" enable="false">

All you need to read is enable at the end. If it is still enable="false", CVE-2026-66713 does not apply to you. You are affected if it has been changed to enable="true", or if the whole <clustering> block was uncommented and brought to life.

We also checked how far back that default goes. In the 1.7.9, 1.8.2 and 2.0.0 tags, the same line reads enable="false" every time. So even 1.7.9, released back in 2018, shipped with it off. Unless somebody deliberately switched it on, you are not exposed.

If it was switched on, these parameters inside the same <clustering> block describe where the door is from an attacker's point of view.

Building a real cluster means changing localMemberHost to the server's actual address, so the risk genuinely rises only when clustering is enabled and port 4000 is reachable from somewhere it should not be. Once both are true, 9.8 is a statement about your environment. If the port is confined to the local host or a closed segment, the urgency drops accordingly.

Why "9.8" and the vendor's "low" appear side by side

It looks like two opposite verdicts on the same flaw, so here is the breakdown. Mistaking where each number came from is how you end up weighing this wrong.

CVSS is a tool for measuring how much breaks once an attack succeeds. The odds of the preconditions lining up are not part of the formula. Feed in "unauthenticated remote arbitrary code execution" and you get 9.8, whether or not the feature ships disabled. So this 9.8 is a ceiling on the damage if it lands, not a measure of how likely you are to be hit.

Apache wrote "low" because their judgement includes the operational reality that the precondition is a feature nobody gets by default. The part worth being careful about is that "low" does not mean "mild even if it applies to you". Where the conditions are met, the advisory is explicit that this reaches unauthenticated code execution. Read it as two things being true at once: most people are out of scope, and for those in scope it is about as bad as a flaw gets.

CISA also attached a second, separate assessment called SSVC, which reads "Exploitation: none / Automatable: yes / Technical Impact: total". As of July 28, the official view is that nobody has been seen exploiting it. Flaws that do start being exploited land in the CISA KEV list, so whether this appears there is the thing to watch.

This pattern of "scanners say 9.8, the vendor says low" is not unusual for Apache projects. The same gap opened up on Apache Tomcat in the same period. Making it a habit to go back to the assigner's own wording whenever you see a score will save you a lot of wasted alarm.

Affected versions and the release that fixes it

The affected range is "through 2.0.0", meaning every release before 2.0.1. The fix is 2.0.1, and both the Maven Central publication record and the Axis2 download page put it at May 17, 2026. In other words, the fixed release had already been out for more than two months when the advisory appeared.

You can read the fix itself in the commit on GitHub. The message is "AXIS2-6097 Remove Clustering feature". It touches 115 files, adds 6 lines and deletes 10,692. Nobody added validation to the unsafe rebuild path; the clustering feature was thrown out wholesale. The 2.0.1 release notes list the same item under "Removed Features".

The date is worth a look too: this commit was written on September 9, 2025, more than ten months before the CVE was published. It was not written as a security fix. It looks like housekeeping — dropping a feature that could no longer be maintained — which a later vulnerability report turned into the official remedy. Either way, having the fixed release out ahead of disclosure is plainly good news for users.

Why "just move to 2.0.1" is not a small job

An affected range of "through 2.0.0" with a single fix at "2.0.1" is an awkward shape for anyone still running the old line. There is no fix release for the 1.x series.

According to the 2.0.1 release notes, this line requires OpenJDK 17 as a minimum (supporting 17, 21 and 25). The previous release, per the 2.0.0 release notes, was the javax-to-jakarta namespace migration, and it moved the target environment up to Tomcat 11 and WildFly 32. On top of that, 2.0.1 also dropped WSDL 2.0, the OSGi module and JiBX data binding.

Seen from an in-house system running 1.8.2 (whose final release was July 2022) or 1.7.x on Java 8, "move to 2.0.1" is not patching — it is a migration project. The Java version, the package renames and the Tomcat upgrade all move together.

Which is precisely why the check comes first. If the setting is still enable="false", nothing about this CVE requires you to start that migration this week. If clustering is enabled, the order is the other way around: disable the setting and close port 4000 now, rather than waiting for a migration. If you genuinely need the capability, plan to provide it outside Axis2 — Tomcat's own clustering, or distribution at the load balancer. With the feature gone from Axis2, that is where the permanent answer lives.

Dependency scanners may not catch this one

One operational caveat. The flaw does have a GitHub advisory, GHSA-fhh8-qfj4-g948, filed on July 28 and shown as Critical 9.8. But the same page reads "Affected versions: Unknown" and "Patched versions: Unknown", and states outright that Dependabot alerts are not supported because no package from a supported ecosystem is attached.

NVD is in the same position: as of July 28 the status is "Awaiting Analysis" and the CPE version ranges are unregistered. "My dependency scanner is quiet, so I am fine" does not hold for this CVE. Whether org.apache.axis2 appears in your pom.xml is something you have to check yourself. Cases where registration lags and the flaw falls straight through automated detection are hard to catch without a deliberate habit of tracking dependencies, which is an argument for keeping a separate mechanism for watching open source dependencies. Once the ranges are registered the automation should catch up, so that is another thing to recheck later.

Nothing filed at JVN or JPCERT/CC

As of July 29, 2026, within the scope of our checks, no Japanese public body has said anything about CVE-2026-66713.

That Tomcat issue — resource exhaustion via the WebSocket chat sample — did make it into JVN. It affects Tomcat 11.0.0-M20 through 11.0.24, 10.1.24 through 10.1.57 and 9.0.89 through 9.0.120, with fixes in 11.0.25, 10.1.58 and 9.0.121. Tomcat's own security page also notes that anyone who followed the guidance to remove the examples web application is unaffected. We cover the detail on our page collecting Tomcat vulnerabilities, so we leave it at a mention here.

Axis2 going unnoticed in Japan probably comes down to how hard its real-world footprint is to see, as discussed below. The flip side is that nobody outside your organisation is going to tell you whether Axis2 is running in your systems.

The same Java rebuild problem keeps producing flaws

CWE-502 covers the case where a program takes data off the network and reconstructs it into objects without questioning what is inside. Java serialization runs class initialisation logic during that reconstruction, which leaves room for an attacker's code to run when a crafted payload arrives. People have been pointing this out for nearly twenty years, and new numbers keep being issued.

Recently there was Apache MINA's CVE-2026-47065, in a library widely used as the foundation for Java network handling. That one bypassed an allow-list defence, and the history of plugging the same hole three times shows how stubborn this family is.

On the same day as this Axis2 advisory, July 28, 2026, IBM published CVE-2026-14512: pre-authentication unsafe deserialization in WebSphere Application Server 9.0 and 8.5 traditional, which IBM itself scored 9.8. That one has no such conditional; it sits before authentication. If you track IBM products in parallel, our IBM vulnerability roundup is worth a look too.

Staying with Apache RPC and web service implementations, Apache Thrift's vulnerabilities and the Apache HTTP Server DoS via HTTP/2 handling have been moving in the same window. Products that expose a server-to-server listener written in Java are all being combed through in turn right now. Cases like Netty, found at the foundation layer, belong to the same current.

How much is Axis2 actually still used

To be straight about it: nobody picks Axis2 for a new project today. It spread widely as the Java implementation of choice in the mid-to-late 2000s, when SOAP web services were the standard way to wire systems together. Public APIs then moved to REST and JSON, and the name barely comes up in new work.

What is running, though, is still running. Internal systems built back then, and integration layers assembled around core platforms in finance, manufacturing and the public sector, quite often still keep their SOAP interfaces. The release history tells the story: the last 1.7 release in 2018, the last 1.8 release in July 2022, and then the 2.0 line from 2025 onward. You can see the outline of a product that stood still for a long time and was then heavily rebuilt.

In terms of name recognition it is orders of magnitude below Tomcat or WebSphere, and the number of people searching for "Axis2 vulnerability" will not be large. But the danger with software like this is the obscurity itself. It is running today inside an integration server somebody built ten years ago, the engineer who built it has moved on, and nobody holds the configuration in their head. With neither JVN nor the press making noise, the only thing that will surface it is your own inventory.

One more thing: Axis2 is not only used on its own, it is also embedded inside other products. The string wso2.carbon.domain sitting in the default clustering configuration is a leftover from another product family that used Axis2 as its engine. "I never installed Axis2" is not the same as "it is not there", so it is worth going as far as the dependency list.

What is not public yet

This article does not fill those gaps with guesses. We will add them once they are known.

The steps, including when you cannot move to 2.0.1

Start by opening axis2.xml on every host running Axis2 and reading the enable attribute on <clustering>. If it says false, there is no emergency response for this CVE. Version upgrades can stay on the normal schedule.

If it says true, work out whether clustering is genuinely in use. If it is on but unused, set it back to false and restart Axis2; that closes the hole. If it is in use, check where TCP port 4000 (or whatever you set localMemberPort to) is reachable from. Nothing outside the cluster nodes needs to reach it, so restricting the source with a firewall or security group is the measure that pays off before any migration does.

Then put the move to 2.0.1 on the plan. As covered above, it drags the Java and Tomcat versions along with it, so estimate honestly. Deciding where the clustering role will live instead is the real substance of that migration.

Finally, even in environments you believe do not use Axis2, take one look for org.apache.axis2 in the dependency list. With no package range on the GitHub advisory, automated detection is not something you can lean on here.

Frequently asked questions

It says 9.8. Should I take the service down right now?

Check <clustering enable="..."> in axis2.xml first. If it is false, this flaw is not a reason to stop the service. The 9.8 measures how much damage a successful attack does; it says nothing about the odds of the precondition being met.

I do not remember enabling clustering. Do I still need to check?

Yes, to be sure. Configuration files get edited by the integrator who built the system, or by operators who joined later. The most plausible pattern is that it was switched on during a build ten years ago as part of load distribution and nobody has touched it since.

I am on 1.8.2. Will there be a 1.8.3-style fix?

The only fix named in primary sources is 2.0.1. Neither the advisory nor the release notes mention a backport to the 1.x line. Given that the resolution was to delete the feature outright in 2.0.1, a dedicated 1.x fix looks unlikely (that last part is our own reading, not a stated fact).

Does moving to 2.0.1 mean losing clustering?

Yes. 2.0.1 removes the clustering feature, and the <clustering> element is gone from axis2.xml entirely. Any setup that depends on it needs a design change to provide the same role outside Axis2.

Should I upgrade Tomcat at the same time?

This flaw is on the Axis2 side and updating Tomcat will not fix it. That said, CVE-2026-66299 was published on the Tomcat side on the same July 28, so it is worth checking separately as part of routine updates.

Summary

CVE-2026-66713 has been filed against Apache Axis2/Java through 2.0.0: arbitrary code execution without authentication. NVD shows 9.8 (Critical), but that score came from CISA, while Apache's own wording is "low". The precondition is that Tribes clustering, which ships disabled, has been turned on — and checking that takes one line of axis2.xml.

The fix, 2.0.1, was already out on May 17, 2026, more than two months before the advisory, and it resolves the issue by removing the clustering feature altogether. The underlying commit dates from September 2025 and was not written as a security fix. But 2.0.1 is an OpenJDK 17, jakarta-namespace release, so upgrading from an older environment is migration-project sized.

EPSS has no score, CISA KEV has no entry, and there are no reports of exploitation. Because the GitHub advisory carries no package range, dependency scanning will not flag it. In Japan, neither JVN, JPCERT/CC nor IPA has picked it up, and there is no Japanese-language coverage yet. Which is why any organisation running Axis2 has to take its own inventory. There is no need to panic at 9.8 — but for the small number of environments that meet the condition, that number lands on you exactly as written.

References

• ▸ oss-security - CVE-2026-66713: Apache Axis2/Java: deserialization of untrusted Data (official Apache advisory, July 28, 2026)
• ▸ Apache Mailing List - CVE-2026-66713 announcement thread
• ▸ NVD - CVE-2026-66713 (published July 28, 2026)
• ▸ CVE.org - CVE-2026-66713 record
• ▸ GitHub Advisory Database - GHSA-fhh8-qfj4-g948
• ▸ GitHub - AXIS2-6097 Remove Clustering feature (the fix commit) (September 9, 2025)
• ▸ GitHub - axis2.xml (v2.0.0, default value of the clustering element)
• ▸ Apache Axis2 2.0.1 Release Notes
• ▸ Apache Axis2 2.0.0 Release Notes
• ▸ Apache Axis2 - Releases (2.0.1 published May 17, 2026)
• ▸ Maven Central - org.apache.axis2:axis2 version list
• ▸ CWE-502: Deserialization of Untrusted Data
• ▸ CISA - Known Exploited Vulnerabilities Catalog (not listed as of July 29, 2026)
• ▸ FIRST - EPSS (no score as of July 29, 2026)
• ▸ JVNVU#99139115 - Apache Tomcat DoS in the WebSocket chat example (July 29, 2026)
• ▸ Apache Tomcat 11 vulnerabilities (CVE-2026-66299)
• ▸ IBM Support - CVE-2026-14512 (WebSphere Application Server) (July 28, 2026)