CVE-2026-57819

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-57819) has been identified in the JAX-RS frontend of Apache CXF (cxf-rt-frontend-jaxrs), which allows attackers to exhaust server CPU and memory by sending requests that contain a very large number of form or multipart parameters. CXF only limits the number of form parameters when the maxFormParameterCount option is set, and the option has no default value.

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 of Apache CXF before 3.6.12, versions 4.0.0 up to (but not including) 4.1.8, and versions 4.2.0 up to (but not including) 4.2.3, including the End-of-Life 3.4.x and 3.5.x lines.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-frontend-jaxrs
• 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-rt-frontend-jaxrs
• Package manager: Maven
• Fixed in:
• OSS Apache CXF 3.6.12, 4.1.8, 4.2.3
• NES for Apache CXF 3.4.10-cxf-3.4.12
• NES for Apache CXF 3.5.11-cxf-3.5.13

Vulnerability Info

This High-severity vulnerability is found in the cxf-rt-frontend-jaxrs package in all versions before 3.6.12, versions 4.0.0 up to (but not including) 4.1.8, and versions 4.2.0 up to (but not including) 4.2.3 of Apache CXF.

When a JAX-RS resource consumes application/x-www-form-urlencoded or multipart/form-data content (for example through @FormParam, Form, or MultivaluedMap parameters), the org.apache.cxf.jaxrs.utils.FormUtils class splits the request body into parameters and then calls checkNumberOfParts to enforce a limit. That check only reads the maxFormParameterCount contextual property. If the property is not configured, which is the default, the method returns early and no limit applies:

public static void populateMapFromString(MultivaluedMap<String, String> params,
                                         Message m,
                                         String postBody,
                                         String enc,
                                         boolean decode) {
    if (StringUtils.isEmpty(postBody)) {
        return;
    }
    String[] parts = postBody.split("&");
    checkNumberOfParts(m, parts.length);
    for (String part : parts) {
        ...


public static void populateMapFromMultipart(MultivaluedMap<String, String> params,
                                            MultipartBody body,
                                            Message m,
                                            boolean decode) {
    List<Attachment> atts = body.getAllAttachments();
    checkNumberOfParts(m, atts.size());
    ...


private static void checkNumberOfParts(Message m, int numberOfParts) {
    if (m == null || m.getExchange() == null || m.getExchange().getInMessage() == null) {
        return;
    }
    String maxPartsCountProp = (String)m.getExchange()
        .getInMessage().getContextualProperty(MAX_FORM_PARAM_COUNT);
    if (maxPartsCountProp == null) {
        return;
    }
    try {
        int maxPartsCount = Integer.parseInt(maxPartsCountProp);
        if (maxPartsCount != -1 && numberOfParts >= maxPartsCount) {
            throw new WebApplicationException(413);
        }
    } catch (NumberFormatException ex) {
        throw ExceptionUtils.toInternalServerErrorException(ex, null);
    }
}

An unauthenticated remote attacker can send a POST request with a very large number of form fields (for example a=1&a=1&... repeated many times) or multipart parts to any form-consuming JAX-RS endpoint. CXF decodes every parameter and stores it in a map. Because the parameter count is never capped by default, repeated requests of this kind can use up CPU and heap and make the service unavailable to legitimate users. Deployments that set maxFormParameterCount explicitly are protected by the configured limit.

This vulnerability was introduced in 2008 with Apache CXF 2.1.

Mitigation

Only recent versions of Apache CXF are community-supported. The affected 3.4.x and 3.5.x 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.