CVE-2026-101296: Apache Tomcat: JNDIRealm bind credential validation fails open for non-GSSAPI SASL mechanisms

Q: Which deployments are exposed to this issue?

Deployments using Apache Tomcat's JNDI realm with a non-GSSAPI SASL authentication mechanism are exposed. The issue affects the listed supported Tomcat version ranges and also known affected EOL 8.5.x and 7.0.x releases; other unsupported versions may also be affected.

Q: What does an attacker need to exploit the vulnerability?

An attacker needs to attempt authentication against a Tomcat deployment whose JNDI realm is configured for a non-GSSAPI SASL mechanism. Under that configuration, authentication may succeed without the correct password.

Q: Is a default Tomcat installation affected?

The issue is conditional on configuring the JNDI realm with a non-GSSAPI SASL authentication mechanism. The provided information does not establish that this is enabled in a default installation.

Q: What should administrators do to remediate the issue?

Upgrade to Apache Tomcat 11.0.27, 10.1.61, or 9.0.123, depending on the release line in use. Users of affected end-of-life 8.5.x or 7.0.x versions should move to a supported fixed release line.

Published Oct 20, 2026

Updated

A missing critical step in authentication vulnerability in Apache Tomcat when the JNDI realm was configured with with a non GSSAPI SASL authentication mechanism allowed attackers to authenticate without providing the correct password.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.26, from 10.1.0-M1 through 10.1.60, from 9.0.0.M1 through 9.0.122.

The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109. Other unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.27, 10.1.61 or 9.0.123, which fix the issue.

Affected Software

1 affected component

Apache Tomcat>=11.0.0-M1<=11.0.26, >=10.1.0-M1<=10.1.60, >=9.0.0.M1<=9.0.122, >=8.5.0<=8.5.100, >=7.0.0<=7.0.109

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade Apache Tomcat to a version that resolves this vulnerability.
Fixed in 11.0.27
Upgrade
Upgrade Apache Tomcat to a version that resolves this vulnerability.
Fixed in 10.1.61
Upgrade
Upgrade Apache Tomcat to a version that resolves this vulnerability.
Fixed in 9.0.123

Event History

Oct 20, 2026

CVE Published

via MITRE·01:45 PM

Data Sourced

via MITRE·01:45 PM

DescriptionWeakness

Data Sourced

via NVD·02:16 PM

DescriptionWeakness

Frequently Asked Questions

Which deployments are exposed to this issue?

Deployments using Apache Tomcat's JNDI realm with a non-GSSAPI SASL authentication mechanism are exposed. The issue affects the listed supported Tomcat version ranges and also known affected EOL 8.5.x and 7.0.x releases; other unsupported versions may also be affected.

What does an attacker need to exploit the vulnerability?

An attacker needs to attempt authentication against a Tomcat deployment whose JNDI realm is configured for a non-GSSAPI SASL mechanism. Under that configuration, authentication may succeed without the correct password.

Is a default Tomcat installation affected?

The issue is conditional on configuring the JNDI realm with a non-GSSAPI SASL authentication mechanism. The provided information does not establish that this is enabled in a default installation.

What should administrators do to remediate the issue?

Upgrade to Apache Tomcat 11.0.27, 10.1.61, or 9.0.123, depending on the release line in use. Users of affected end-of-life 8.5.x or 7.0.x versions should move to a supported fixed release line.

CVE-2026-101296: Apache Tomcat: JNDIRealm bind credential validation fails open for non-GSSAPI SASL mechanisms

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are exposed to this issue?

What does an attacker need to exploit the vulnerability?

Is a default Tomcat installation affected?

What should administrators do to remediate the issue?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to this issue?

What does an attacker need to exploit the vulnerability?

Is a default Tomcat installation affected?

What should administrators do to remediate the issue?