CVE-2026-43513

What it actually does

The flaw is in Apache Tomcat's LockOutRealm account lockout logic. Because username case is handled inconsistently, an unauthenticated remote attacker can potentially bypass lockout controls by retrying authentication with different capitalization of the same account name. This weakens protections against password guessing, credential stuffing, and brute-force attacks for applications relying on Tomcat container-managed authentication and LockOutRealm. The issue primarily affects confidentiality: if the attacker eventually succeeds with valid credentials, they may access protected application content despite lockout policies that should have slowed or stopped the attack.

Why it matters to the business

Organizations using affected Apache Tomcat versions may have reduced protection against account takeover attempts, especially for internet-facing applications using Tomcat-managed authentication. Attackers can make more authentication attempts than intended, increasing the risk of unauthorized access to sensitive application data. Although this is not currently listed in CISA KEV and no public exploit maturity is reported, it is network-accessible, low-complexity, and affects many Tomcat release lines, so remediation should be prioritized for externally exposed or identity-sensitive applications.

How an attack unfolds

An attacker first identifies a Tomcat-hosted application that uses container-managed authentication with LockOutRealm enabled. They attempt repeated logins against a target username until the normal lockout threshold should prevent further authentication attempts. Due to improper case-sensitivity handling, the attacker then changes the capitalization of the username, such as trying different upper/lowercase variants, and continues authentication attempts that may not be treated as the same locked identity. This allows continued password guessing or credential stuffing beyond the intended lockout limit. If the attacker has a valid password from reuse, phishing, leaks, or successful guessing, they can authenticate and access protected resources.

How to fix it

Upgrade Apache Tomcat to a fixed supported version: 11.0.22 or later, 10.1.55 or later, or 9.0.118 or later. Deployments on Apache Tomcat 8.5.x or 7.0.x should migrate to a supported fixed branch because the affected ranges include 8.5.0 through 8.5.100 and 7.0.0 through 7.0.109. If immediate upgrade is not possible, reduce exposure by placing affected applications behind stronger upstream authentication, enforcing MFA where feasible, applying rate limits at a reverse proxy or WAF, normalizing username case consistently before authentication where application design permits, monitoring and blocking credential-stuffing behavior, and disabling or replacing vulnerable lockout behavior only if an equivalent protective control is in place.

How to confirm the fix worked

Confirm the running Tomcat version is 11.0.22 or later, 10.1.55 or later, or 9.0.118 or later. Verify no affected unsupported Tomcat 8.5.x, 7.0.x, or older installations remain in production. Review server configuration to determine whether LockOutRealm is used in server.xml, context.xml, or inherited configuration. In a controlled test environment, validate that failed login attempts for a username and mixed-case variants are counted consistently and that lockout cannot be bypassed by changing username capitalization. Confirm compensating controls such as MFA, upstream rate limiting, and credential-stuffing detection are active for any systems awaiting upgrade.

Typical attack path

1. Identify an Apache Tomcat-hosted application using container-managed authentication.
2. Select target usernames from public sources, prior breaches, application behavior, or login enumeration.
3. Submit repeated failed login attempts until the configured LockOutRealm threshold would normally lock the account.
4. Retry authentication using case variants of the same username to bypass or avoid the lockout state.
5. Continue password guessing or credential stuffing beyond the intended lockout limit.
6. Authenticate successfully if valid credentials are found or reused.
7. Access protected application data available to the compromised account.

How to detect it

Look for evidence of credential-stuffing or brute-force activity where the same logical username appears with different capitalization. Relevant sources include Tomcat access logs, application authentication logs, Catalina logs, identity-provider logs if Tomcat delegates authentication, reverse proxy logs, WAF logs, and SIEM-normalized authentication events. Hunt for repeated failed authentication attempts against a username, lockout events, and then continued attempts or successful authentication using case variants of that same username from the same source IP, user agent, ASN, or session. Pay particular attention to sequences where a locked account appears to authenticate successfully shortly afterward with different username casing. If access logs include authenticated username fields, compare case-normalized usernames across failures and successes. Also review configuration history for LockOutRealm use and correlate suspicious login activity with access to sensitive application endpoints after authentication.

• org.apache.catalina.realm.LockOutRealm
• LockOutRealm
• <Realm className="org.apache.catalina.realm.LockOutRealm"
• className="org.apache.catalina.realm.LockOutRealm"
• An attempt was made to authenticate the locked user

What your security team should do

• Inventory all Apache Tomcat deployments and identify versions in the affected ranges: 11.0.0-M1 through 11.0.21, 10.1.0-M1 through 10.1.54, 9.0.0.M1 through 9.0.117, 8.5.0 through 8.5.100, and 7.0.0 through 7.0.109.
• Prioritize upgrades for internet-facing Tomcat applications and applications protecting sensitive data or privileged user access.
• Upgrade to Apache Tomcat 11.0.22+, 10.1.55+, or 9.0.118+; migrate unsupported 8.5.x and 7.0.x deployments to a supported fixed branch.
• Search Tomcat configuration for LockOutRealm usage and assess whether applications rely on Tomcat container-managed authentication.
• Enable or tune detection for repeated failed logins followed by successful authentication using case variants of the same username.
• Apply temporary rate limiting, MFA, IP reputation controls, and credential-stuffing protections while upgrades are scheduled.
• Review recent authentication logs for evidence of lockout bypass attempts, especially username case variation during repeated failed login activity.