Apache says a cached successful login can let later logins for the same username succeed with any password. The condition requires DefaultLdapRealm or JndiLdapRealm with authenticationCachingEnabled set to true, which is not the default.Apache rates the flaw Critical and fixes it in Shiro 3.0.1. Teams can use a vulnerability intelligence platform to track the update alongside configuration exposure, while verifying the LDAP setting in each application.
What it allows
How Does CVE-2026-129349 Bypass LDAP Authentication?
A successful LDAP login normally verifies the password through a directory bind. With authentication caching enabled, Shiro can instead reuse the cached authentication information and skip that bind on a later login.
Apache says DefaultLdapRealm installs AllowAllCredentialsMatcher by default in affected releases. That matcher accepts the submitted credentials when the cached entry is used. An attacker who knows a valid username can then authenticate after that user's first successful login, even with another password.
The first successful login and the nondefault cache setting matter. This is not a claim that every Shiro LDAP deployment accepts arbitrary passwords. Apache identifies JndiLdapRealm as also within the affected configuration.
Which Deployments Need Priority Review?
Start with Shiro through 3.0.0 where DefaultLdapRealm or JndiLdapRealm has authentication caching enabled. Apache rates the flaw Critical and recommends upgrading to 3.0.1 or later.
Where that configuration was active, review authentication records for repeated attempts against valid usernames. Investigate suspicious sessions through the normal incident process.
Who is affected
Which Shiro Versions and Settings Are Affected by CVE-2026-129349?
Apache lists all Shiro versions through 3.0.0 as affected when an application uses DefaultLdapRealm or JndiLdapRealm with authenticationCachingEnabled=true. The setting is not enabled by default. Version alone does not establish exposure without that LDAP configuration.
Inspect each application's Shiro dependency and LDAP authentication configuration. Confirm the concrete deployed Shiro version, including the version packaged inside the application. The Apache notice gives a single upper boundary, so this profile does not assign separate fixed ranges to older release lines.
How Should Teams Contain and Verify the Fix?
Upgrade affected deployments to Apache Shiro 3.0.1 or later, as Apache directs. After deployment, verify the running shiro-core version and confirm the application still uses the intended LDAP authentication flow.
If an immediate upgrade is unavailable, Apache says to disable authentication caching on the LDAP component. Its other alternative is a credentials matcher, such as SimpleCredentialsMatcher, that verifies credentials against cached authentication information.
Review login records for repeated attempts against valid usernames where the affected configuration was active. This is a Brandefense investigation step, not a claim of observed abuse. Record the fix and validation in the patch management process.
This flaw differs from Shiro CVE-2026-129347, which concerns empty stored credentials. CVE-2026-74763 instead concerns authorization annotations in class and interface hierarchies. The vulnerability intelligence glossary explains how to track distinct flaws without treating them as one issue.
Timeline
What to do
-
Find the affected LDAP configuration
Inventory applications using Shiro through 3.0.0. Confirm whether DefaultLdapRealm or JndiLdapRealm has authenticationCachingEnabled=true. Prioritize those installations for remediation.
-
Upgrade and verify the running version
Deploy Apache Shiro 3.0.1 or later. Verify the shiro-core version actually loaded by each application after restart or redeployment, then confirm normal LDAP authentication.
-
Use Apache's interim alternatives if needed
Disable authentication caching on the LDAP component, or configure a credentials matcher that checks cached authentication information. Validate the chosen setting before restoring normal access.
-
Review relevant authentication activity
As a Brandefense precaution, examine login records from affected installations for unusual repeated attempts against valid usernames. Investigate any suspicious sessions through the normal incident process.
What Brandefense can do
- Scan your domain in Brandefense Atlas, free
Atlas checks public sources for leaked credentials, phishing domains, dark web mentions and data sales, then gives your domain a risk grade. Free, no sign-up.
- Vulnerability intelligence platform
Brandefense Vulnerability Intelligence follows which vulnerabilities attackers are using, so your team can patch what is under attack first.
Frequently Asked Questions
Does CVE-2026-129349 affect default Shiro LDAP settings?
Apache says authenticationCachingEnabled=true is required and is not the default. Check the application's LDAP configuration before treating a deployment as exposed.
Which version fixes CVE-2026-129349?
Apache identifies Shiro 3.0.1 or later as the fix. Verify the version loaded by the deployed application after upgrading.
Why can a different password work after the first login?
Apache says cached authentication skips the LDAP bind. DefaultLdapRealm's default AllowAllCredentialsMatcher then accepts credentials for the cached user in affected configurations.
Is this the same flaw as CVE-2026-129347 or CVE-2026-74763?
No. Those Apache reports concern empty stored credentials and authorization annotation enforcement, respectively. CVE-2026-129349 concerns LDAP authentication caching.
Sources
- Apache Shiro Security ReportsApache Software Foundation
- CVE-2026-129349 oss-sec NoticeApache Software Foundation via oss-sec
- Known Exploited Vulnerabilities CatalogCybersecurity and Infrastructure Security Agency
