Three Apache Shiro Advisories Need Different Checks

Apache Shiro November 2026 advisories describe three different security conditions in authentication and authorization. Apache rates the LDAP authentication cache issue critical, but it requires a nondefault cache setting. The empty credential issue requires accounts with empty stored credentials. The authorization issue depends on both the integration module and annotation placement.

Teams should inventory the deployed Shiro modules and settings before prioritizing tests. An upgrade to 3.0.2 or later addresses all three issues, while 3.0.1 fixes only the LDAP cache issue among them. Apache’s Shiro security reports provide the affected conditions and mitigations.

Apache Shiro November 2026 Advisories at a Glance

Advisory	Affected condition	Impact	Fixed version
CVE-2026-129349	DefaultLdapRealm or JndiLdapRealm with authenticationCachingEnabled true, through 3.0.0	Subsequent authentication may accept any password after a successful login	3.0.1 or later
CVE-2026-129347	Accounts with empty stored credentials, through 3.0.1	Empty submitted password may match an empty stored credential	3.0.2 or later
CVE-2026-74763	Named integration modules and inherited annotations, through 3.0.1	Intended role or permission checks may be skipped	3.0.2 or later

The table is an exposure triage aid, not a claim that every Shiro application has all three flaws. Apache’s mailing list assigns CVSS 4.0 scores of 9.1, 2.3 and 6.3 in table order. The notices provide no CVSS 3.1 scores. The vulnerability intelligence platform is relevant when teams need to connect this advisory context to their asset inventory and remediation queue.

Why the LDAP Cache Issue Is the First Configuration Check

For CVE-2026-129349, Apache says a successful first login populates the authentication cache. A later cached authentication skips the LDAP bind, while the default AllowAllCredentialsMatcher accepts the submitted credentials. A person who knows a valid username could then authenticate with any password. This is a conditional authentication bypass, not a default behavior of every LDAP deployment.

Apache limits this condition to DefaultLdapRealm or JndiLdapRealm with authenticationCachingEnabled set to true, through Shiro 3.0.0. Authentication caching is disabled by default. Confirm the deployed LDAP component, the setting, and the actual library version together. Upgrade to 3.0.1 or later, or disable authentication caching until the upgrade is complete.

Apache also describes a credentials matcher that checks against cached authentication information as an alternative. If caching must remain enabled, test that the configured matcher actually rejects an incorrect password after a legitimate login. Keep that test in a controlled environment and review authentication events for unexpected successful sign-ins. The patch management process should record both the deployed version and this configuration check.

What Makes the Two 3.0.2 Fixes Different

CVE-2026-129347 is about stored credential state, not LDAP caching. Apache says DefaultPasswordService and SimpleCredentialsMatcher could accept an empty submitted password when an account has an empty stored credential. It affects versions through 3.0.1 only where such accounts exist. Upgrade to 3.0.2 or later, reject empty passwords, and remove empty stored credentials.

CVE-2026-74763 instead concerns authorization annotations such as @RequiresRoles and @RequiresPermissions. Apache says interface annotations were not enforced with shiro-guice, shiro-aspectj, shiro-cdi or shiro-jakarta-ee. Class or superclass annotations could also be missed with shiro-guice or shiro-aspectj. An unauthorized caller could reach a method the application intended to protect.

The Shiro advisory names versions through 3.0.1, with impact determined by the module and annotation location. The oss-sec notice lists shiro-cdi and shiro-jakarta-ee from 2.0.0-alpha-0, while the other two modules have broader affected ranges. Apache says 3.0.2 makes the annotation closest to the invoked method take precedence. Until then, place authorization annotations directly on each protected implementing method.

A Verification Sequence for Application Owners

• Inventory dependenciesRecord the Shiro core and integration module versions deployed in each application.
• Check LDAP cachingIdentify DefaultLdapRealm or JndiLdapRealm and confirm whether authenticationCachingEnabled is true.
• Inspect credential storageFind accounts with empty stored credentials and enforce rejection of empty passwords.
• Trace protected methodsReview interface, class and superclass annotations in the named integration modules.
• Upgrade and retestDeploy 3.0.2 or later, then verify failed sign-ins and denied method calls in a controlled test.

This sequence is our operational reading of Apache’s three separate mitigations. A 3.0.1 deployment resolves the cache bypass, but remains inside the affected range for the other two advisories. Test the application behavior after deployment, especially when authorization relies on inherited annotations. The vulnerability intelligence overview explains how to keep the advisory tied to a verifiable exposure decision.

Brandefense Blackhole counted 2,151 dark chat posts matching the broad term “Apache” from 16 August to 14 November 2026. The unit is matching posts, not incidents or affected Shiro installations. This broad count can guide monitoring priorities, but it cannot establish exploitation of these three CVEs. Prioritize the vendor’s configuration conditions and application tests over keyword volume.

Scope of This Analysis

We compared Apache Shiro’s security reports with its three oss-sec announcements dated 14 November 2026. Our table and check order combine the vendor’s conditions into one defender workflow. The Blackhole count is a separate, broad Apache keyword measurement and may include unrelated projects. It does not change Apache’s affected version boundaries.