CVE-2026-54225
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Apache CXF is an open-source services framework, maintained by the Apache Software Foundation, for building and consuming web services in Java. It implements the JAX-WS and JAX-RS APIs and supports SOAP, the WS-* standards, RESTful HTTP, and OAuth 2.0 over transports such as HTTP and JMS. Its modules are published as Maven artifacts under org.apache.cxf.
A Denial of Service (DoS) vulnerability (CVE-2026-54225) has been identified in the attachment handling of cxf-core, which allows attackers to exhaust server disk space by sending arbitrarily large MIME attachments, because the attachment-max-size property has no default, so attachments are not size-limited unless a limit is configured.
Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.
This issue affects all versions prior to 3.6.12, versions 4.0.0 through 4.1.7, and versions 4.2.0 through 4.2.2 of Apache CXF.
Details
Module Info
- Product: Apache CXF
- Affected packages:
org.apache.cxf:cxf-core - Affected versions: <3.6.12, >=4.0.0 <4.1.8, >=4.2.0 <4.2.3
- GitHub repository: https://github.com/apache/cxf
- Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-core
- Package manager: Maven
- Fixed in:
- OSS Apache CXF 3.6.12, 4.1.8, 4.2.3
- NES for Apache CXF v3.5.13, v3.4.12
Vulnerability Info
This High-severity vulnerability is found in the org.apache.cxf:cxf-core package in all versions prior to 3.6.12, versions 4.0.0 through 4.1.7, and versions 4.2.0 through 4.2.2 of Apache CXF.
When a CXF endpoint receives a multipart MIME message, such as a SOAP with Attachments or MTOM request, or a JAX-RS multipart request, AttachmentDeserializer copies each attachment into a CachedOutputStream. Content that exceeds the in-memory threshold is written to temporary files on disk. AttachmentUtil.setStreamedAttachmentProperties configures that stream, but it applies a maximum size only when the attachment-max-size contextual property has been set:
Object maxSize = message.getContextualProperty(AttachmentDeserializer.ATTACHMENT_MAX_SIZE);
if (maxSize != null) {
if (maxSize instanceof Number) {
long size = ((Number) maxSize).longValue();
if (size >= 0) {
bos.setMaxSize(size);
} else {
LOG.warning("Max size value overflowed long. Do not set max size!");
}
} else if (maxSize instanceof String) {
try {
bos.setMaxSize(Long.parseLong((String) maxSize));
} catch (NumberFormatException e) {
throw new IOException("Provided threshold String is not a number", e);
}
} else {
throw new IOException("The value set as " + AttachmentDeserializer.ATTACHMENT_MAX_SIZE
+ " should be either an instance of Number or String");
}
}
In a default deployment the property is unset, so setMaxSize is never called and the cache stream accepts an attachment of any length. An unauthenticated remote attacker can send one or more very large attachments to any endpoint that accepts MIME content. Once the in-memory threshold is exceeded, CXF keeps writing the attachment data to temporary files until the disk is exhausted, making the service unavailable to legitimate users.
Mitigation
Only recent versions of Apache CXF receive community support. Older lines are End-of-Life and will not receive public updates to address this issue.
Users of the affected components should apply one of the following mitigations:
- Upgrade to a currently supported Apache CXF release line (3.6.x or later) that contains the fix.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.