Vulnerability Directory | CVE-2026-43514

Overview

Apache Tomcat is an open-source implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Annotations, and Jakarta Authentication specifications, providing a pure Java HTTP web server environment for running Java code. It is one of the most widely used Java application servers.

A low-severity vulnerability (CVE-2026-43514) has been identified in the AJP connector of Apache Tomcat. When an AJP connector is configured with a shared secret, the per-request comparison of the client-supplied secret against the configured value executes in non-constant time, allowing an attacker positioned on the local network to mount a timing side-channel attack and progressively recover the AJP secret.

Per OWASP: Information Exposure is the intentional or unintentional disclosure of information to an actor that is not explicitly authorized to have access to that information. In this case, a timing side channel in the secret comparison routine leaks the AJP secret one byte at a time to a network-adjacent observer.

This issue affects versions 8.5.0 through 8.5.100, 9.0.0.M1 through 9.0.117, 10.1.0-M1 through 10.1.54, and 11.0.0-M1 through 11.0.21 of Apache Tomcat.

‍

Details

Module Info

Product: Apache Tomcat
Affected packages: tomcat-catalina, tomcat-coyote, tomcat-util, tomcat-embed-core
Affected versions: >=8.5.0 <=8.5.100, >=9.0.0.M1 <=9.0.117, >=10.1.0-M1 <=10.1.54, >=11.0.0-M1 <=11.0.21
GitHub repository: https://github.com/apache/tomcat
Published packages:
Package manager: Maven
Fixed in:
NES for Apache Tomcat
Apache Tomcat 11.0.22, 10.1.55, 9.0.118 (OSS)

Vulnerability Info

The AJP connector authenticates incoming connections from a reverse proxy (typically mod_jk or mod_proxy_ajp) using a shared secret configured on both ends. In AjpProcessor.prepareRequest(), the per-request comparison of the client-supplied secret bytes against the configured value used the standard MessageBytes.equals(String) routine:

requestHeaderMessage.getBytes(tmpMB);
if (secret != null && !secret.isEmpty()) {
    secretPresentInRequest = true;
    if (!tmpMB.equals(secret)) {
        response.setStatus(403);
        setErrorState(ErrorState.CLOSE_CLEAN, null);
    }
}

MessageBytes.equals(String) walks the bytes pairwise and returns false at the first mismatch. The position of the first differing byte is observable in the time between the request arriving on the wire and the 403 response being returned, which gives a local-network attacker a per-byte timing oracle over the configured secret.

The fix introduces a new utility class org.apache.tomcat.util.security.ConstantTime and switches the AJP secret check to use it. The new comparator always walks the full length of both inputs and accumulates the result, eliminating the early-exit timing signal:

requestHeaderMessage.getBytes(tmpMB);
if (secret != null && !secret.isEmpty()) {
    secretPresentInRequest = true;
    if (!ConstantTime.equals(tmpMB.getByteChunk(), secret)) {
        response.setStatus(403);
        setErrorState(ErrorState.CLOSE_CLEAN, null);
    }
}

The same change deprecates DigestCredentialHandlerBase.equals(String, String, boolean) and DigestCredentialHandlerBase.equals(byte[], byte[]) in favour of the new ConstantTime.equals(...) overloads, consolidating all security-sensitive comparisons in Tomcat onto a single hardened implementation adapted from java.security.MessageDigest#isEqual.

Exploitation requires the attacker to sit on the local network reachable by the AJP listener and to be able to send many AJP requests while measuring response timing. AJP is intended for use between a front-end reverse proxy and Tomcat, so a correctly deployed connector is not exposed to the public internet; the vulnerability is rated Low on that basis.

‍

Mitigation

Only recent versions of Apache Tomcat are community-supported. Older versions (8.5.x and earlier) will not receive any updates to address this issue. NES for Tomcat includes an update to 8.5.x to address this issue. For more information, see here.

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