CVE-2026-129349 json
Apache Shiro: DefaultLdapRealm accepts any password when authentication caching is enabled
published 1h ago modified 29m ago also EUVD-2026-126005
- cvss
- 9.1
- version 4.0, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no EPSS score yet
- public exploits
- 0
- none known
Summary
When authentication caching is enabled on DefaultLdapRealm, after a user logs in successfully once, subsequent logins for that user succeed with any password. A cached authentication skips the LDAP bind, and the AllowAllCredentialsMatcher installed by default in DefaultLdapRealm accepts any credentials, allowing an attacker who knows a valid username to authenticate as that user. This issue affects all Apache Shiro versions through 3.0.0, only when using DefaultLdapRealm (or JndiLdapRealm) with authenticationCachingEnabled set to true, which is not the default.
Mitigation: Upgrade to version 3.0.1 or later, which fixes the issue by no longer installing AllowAllCredentialsMatcher by default. Alternatively, disable authentication caching on the LDAP realm (this is the default), or configure a credentials matcher, such as SimpleCredentialsMatcher, that verifies credentials against the cached authentication info.
Patch / fix
- maven org.apache.shiro:shiro-core 3.0.1
- Apache Software Foundation Apache Shiro 3.0.1
Is CVE-2026-129349 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 4.0 | 9.1 | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/S:N/AU:Y/R:U/V:C/RE:L/U:Red |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| maven | org.apache.shiro:shiro-core | <3.0.1 |
3.0.1 |
Affected products
- Apache Software Foundation Apache Shiro
Classification
- Weakness
-
- CWE-287 Improper Authentication
References
Sources
- CVE List CVE-2026-129349
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.