CVE-2026-78383

Overview

Apache Tomcat is an open-source implementation of the Jakarta Servlet, Jakarta Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Annotations, and Jakarta Authentication specifications. It serves Java web applications either as a standalone servlet container and HTTP server or embedded inside an application through the tomcat-embed-core artifact. Its Catalina servlet container (org.apache.tomcat:tomcat-catalina) supplies the request-processing pipeline, including Valves such as RewriteValve, along with connectors, realms, and session management.

A Denial of Service (DoS) vulnerability (CVE-2026-78383) has been identified in the Apache Tomcat AJP connector, which allows unauthenticated attackers to pin AJP processing threads and exhaust the connector's thread pool by sending requests that announce a request body and then never supply one.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects the AJP connector of Apache Tomcat.

Details

Module Info

• Product: Apache Tomcat
• Affected packages: tomcat-coyote, tomcat-embed-core
• Affected versions: >=7.0.0 <=7.0.109, >=8.5.0 <=8.5.100, >=9.0.0.M1 <9.0.122, >=10.1.0-M1 <10.1.60, >=11.0.0-M1 <11.0.26
• GitHub repository: https://github.com/apache/tomcat
• Published packages: https://central.sonatype.com/artifact/org.apache.tomcat/tomcat-coyote, https://central.sonatype.com/artifact/org.apache.tomcat.embed/tomcat-embed-core
• Package manager: Maven
• Fixed in:
• NES for Apache Tomcat 8.5.100-tomcat-8.5.112
• Apache Tomcat 11.0.26, 10.1.60, 9.0.122 (OSS)

Vulnerability Info

This High-severity vulnerability is found in the org.apache.tomcat:tomcat-coyote package in the 8.5.x line of Apache Tomcat, in the org.apache.coyote.ajp AJP connector implementation.

AJP is the binary protocol Tomcat speaks to a reverse proxy such as mod_jk or mod_proxy_ajp. A request body does not travel with the forward-request packet: the proxy sends the headers first, and Tomcat must ask for each body chunk with a separate blocking read. When AjpProcessor finalizes a response, it first tries to drain any body packet the application never read, so that the next request on the persistent connection does not begin mid-body:

@Override
protected final void finishResponse() throws IOException {
    if (responseFinished) {
        return;
    }

    responseFinished = true;

    // Swallow the unread body packet if present
    if (waitingForBodyMessage || first && request.getContentLengthLong() > 0) {
        refillReadBuffer(true);
    }

    // Add the end message
    if (getErrorState().isError()) {
        socketWrapper.write(true, endAndCloseMessageArray, 0, endAndCloseMessageArray.length);
    } else {
        socketWrapper.write(true, endMessageArray, 0, endMessageArray.length);
    }
    socketWrapper.flush(true);
}

The swallow block runs unconditionally, before the error state is consulted. Both of its guards are driven by attacker-controlled request metadata: request.getContentLengthLong() comes straight from the forwarded Content-Length header, and waitingForBodyMessage is set whenever Tomcat has already asked the proxy for more body data. A client that declares a non-empty body and then sends none satisfies the guard, so refillReadBuffer(true) performs a blocking read for a body packet that will never arrive.

Because the error branch is only reached after that read, a response that has already failed still blocks here instead of writing the end-and-close message and releasing the connection. The AJP processing thread stays parked on the read until the connection times out or the proxy gives up. Each such request consumes one thread from the connector's pool, and a handful of concurrent requests is enough to saturate the pool and make the server unavailable to legitimate traffic, with no authentication required. The remedy is to drain the unread body only on the non-error path, so an errored response finalizes immediately.

This vulnerability was introduced in 2011 with Apache Tomcat 7.0.21.

Mitigation

Only recent versions of Apache Tomcat are community-supported. The community support version will not receive any updates to address this issue. For more information, see here.

Users of the affected components should apply one of the following mitigations:

• Remove the examples web application, which upstream identifies as a readily reachable trigger for this issue.
• Upgrade to a patched version of Apache Tomcat.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Apache Tomcat security team (finder)