CVE-2026-43512
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
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 moderate-severity vulnerability (CVE-2026-43512) has been identified in Apache Tomcat's DIGEST authentication implementation. When DIGEST authentication is configured, the server computes the expected digest for an unknown user by concatenating the literal string "null" (the result of converting a null password to a Java string) into the digest input. An attacker who computes the client-side request digest using the password literal "null" matches the server's calculation and is authenticated as the supplied username, which need not exist in the configured Realm.
Per OWASP: Authorization Bypass occurs when an application fails to correctly enforce authentication or access-control decisions, allowing an unauthenticated or unauthorized user to access protected functionality. In this case, the DIGEST authenticator accepts a digest computed against the password literal "null" for any unknown username, granting access to any DIGEST-protected resource without valid credentials.
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-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 vulnerability is in RealmBase.getDigest(String username, String realmName, String algorithm) in java/org/apache/catalina/realm/RealmBase.java. This method computes the server-side digest A1 used by the DIGEST authenticator to compare against the client's request digest. Before the fix, the method called getPassword(username) without checking for a null return value:
protected String getDigest(String username, String realmName, String algorithm) {
if (hasMessageDigest(algorithm)) {
// Use pre-generated digest
return getPassword(username);
}
String digestValue = username + ":" + realmName + ":" + getPassword(username);
byte[] valueBytes;
try {
valueBytes = digestValue.getBytes(getDigestCharset());
} catch (UnsupportedEncodingException uee) {
throw new IllegalArgumentException(sm.getString("realmBase.invalidDigestEncoding", getDigestEncoding()), uee);
}
return HexUtils.toHexString(ConcurrentMessageDigest.digest(algorithm, valueBytes));
}
When username is not present in the configured Realm, getPassword(username) returns null. Java string concatenation converts null to the four-character string "null", so the server computes MD5("<username>:<realm>:null") and treats that value as the expected digest A1 for the authentication challenge. An attacker who computes the request digest using the password literal "null" produces a matching response and is authenticated as the supplied (non-existent) user.
The fix introduces an early-return when the password lookup fails, so the digest comparison never runs for unknown users. The caller, RealmBase.authenticate(..., algorithm), already returns null when digestA1 is null, so the fix wires the unknown-user case directly into the existing failure path.
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:
- Upgrade to a patched version of Apache Tomcat.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.