What is the CVSS score of CVE-2026-66909?

CVE-2026-66909 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.7%.

Which versions of Apache CXF are affected by CVE-2026-66909?

Apache CXF versions widely deployed in enterprise Java environments contain a critical deserialization flaw in their JMS messaging transport enabling unauthorized remote code execution.. A patch is available.

How to fix or mitigate CVE-2026-66909?

Within 24 hours, identify all systems running Apache CXF versions 3.6.11, 4.1.7, or 4.2.2 and earlier with JMS transport enabled; document which have deserialization gadget libraries (commons-collections, ROME) on the classpath. Within 7 days, implement network segmentation restricting JMS destination access to trusted publishers only, disable JMS transport in CXF configuration where operationally feasible, and remove or isolate gadget libraries from affected systems. Within 30 days, monitor Apache CXF release notes for patched versions (4.2.3, 4.1.8, 3.6.12), test patches in non-production, and deploy immediately upon vendor availability.

Apache CXF CVE-2026-66909

EUVD-2026-53854 CRITICAL

Deserialization of Untrusted Data (CWE-502)

2026-08-06 apache

GHSA-gvw8-rcrx-9fxx

RCE Denial Of Service Apache Java Deserialization Red Hat Apache Cxf Apache Software Foundation

9.8

CVSS 3.1 · Vendor: apache

Severity by source

Vendor (apache) PRIMARY

9.8 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

7.5 HIGH

Network vector via JMS broker; AC:H because RCE requires a gadget chain on classpath; PR:L because JMS destination access typically requires some broker-level credential.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

8.1 HIGH

qualitative

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch available

Aug 06, 2026 - 12:01 EUVD

Analysis Generated

Aug 06, 2026 - 11:36 vuln.today

CVE Published

Aug 06, 2026 - 10:23 cve.org

HIGH

DescriptionCVE.org

Apache CXF's JMS transport deserializes the body of any inbound JMS ObjectMessage using native Java deserialization, with no type restrictions in place. Any attacker able to place a message on the service's JMS destination can submit a malicious serialized object, leading to denial of service or, if a suitable gadget class is on the classpath, remote code execution. The fix disables ObjectMessage deserialization by default, with a configuration switch to re-enable it if needed. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

Articles & Coverage 1

News Critical RCE in Apache CXF JMS Transport (Java) - CVE-2026-66909 Aug 06, 2026

AnalysisAI

Unsafe deserialization in Apache CXF's JMS transport allows any party able to publish to the service's JMS destination to achieve denial of service or, where a compatible deserialization gadget chain is present on the application classpath, remote code execution within the CXF process. All Apache CXF versions prior to 4.2.3, 4.1.8, and 3.6.12 are affected when the JMS transport is in use. No public exploit code or CISA KEV listing has been identified at time of analysis, though the vulnerability class (CWE-502 with unrestricted ObjectInputStream) is well-understood and tooling such as ysoserial makes it routinely exploitable wherever gadget libraries are present.

Technical ContextAI

Apache CXF is an enterprise Java web services framework supporting SOAP, REST, and message-broker transports including JMS (Java Message Service). The JMS transport enables CXF services to consume messages from queues or topics on brokers such as ActiveMQ or IBM MQ. The root cause is CWE-502 (Deserialization of Untrusted Data): CXF's JMS message handler invokes native Java ObjectInputStream.readObject() on the body of any inbound JMS ObjectMessage with no type allowlist or ObjectInputFilter applied. This classical anti-pattern becomes critical when attacker-controlled serialized payloads trigger 'gadget chains' - sequences of deserialization callbacks in third-party library classes (e.g., Apache Commons Collections, Spring Framework, Groovy) that collectively produce arbitrary code execution. The fix disables ObjectMessage deserialization by default, offering a configuration opt-in. The affected CPE cpe:2.3:a:apache_software_foundation:apache_cxf:*:*:*:*:*:*:*:* spans all maintained release lines prior to the patched versions across the 3.6.x, 4.1.x, and 4.2.x branches.

RemediationAI

The primary remediation is to upgrade Apache CXF to version 4.2.3, 4.1.8, or 3.6.12, which disable ObjectMessage deserialization by default; the fix introduces a configuration switch to re-enable it only if operationally required. Details are in the Apache advisory at https://lists.apache.org/thread/lr5d4tg6tf7j29jmw8wt242oowonjqpx. If immediate upgrade is not feasible, compensating controls include: (1) restricting write access to the CXF JMS destination at the broker level using access control lists (ACLs) - this prevents unauthorized parties from placing messages, though it shifts trust to the broker configuration and does not protect against compromised internal senders; (2) configuring a Java serialization filter (ObjectInputFilter via JVM property jdk.serialFilter or programmatic API, available from JDK 9+) to block known gadget classes - effective against known chains but may require ongoing maintenance as new gadget classes are discovered; (3) auditing and removing unnecessary gadget-prone libraries (e.g., Commons Collections, older Spring versions) from the application classpath to eliminate RCE elevation, though DoS remains possible; and (4) placing the JMS broker behind a network boundary accessible only to trusted application tiers. None of these workarounds are as effective or low-risk as patching.