GEODE-10559: Upgrade Apache Shiro to 2.1.0 (CVE-2026-23903 remediation)

[JinwooHwang]

Summary

This PR upgrades Apache Shiro from 1.13.0 to 2.1.0 to remediate CVE-2026-23903. The upgrade required API migrations where Shiro moved/removed common exception types and some providers. The changes update production code, tests, and build configuration to use Shiro 2.1.0 and restore a clean build and test pass.

Jira: GEODE-10559
CVE: CVE-2026-23903

Key Changes

• Dependency: Bumped shiro.version to 2.1.0 in the dependency constraints.
• Production code: Updated IntegratedSecurityService and SecurityManagerProvider to catch and use the specific Shiro exceptions available in 2.1.0 (e.g., AuthenticationException, AuthorizationException, ConfigurationException) instead of the removed/relocated ShiroException.
• Tests: Refactored several tests to replace removed Shiro classes with appropriate available replacements and restored test methods that had been impacted by the migration.
• Formatting & build: Applied Spotless fixes and validated the Gradle build and full test suite.

Files Modified (high level)

• build-tools/geode-dependency-management/.../DependencyConstraints.groovy — shiro.version -> 2.1.0
• geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
• geode-core/src/main/java/org/apache/geode/internal/security/SecurityManagerProvider.java
• geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerShiroAcceptListTest.java
• geode-core/src/test/java/org/apache/geode/internal/security/IntegratedSecurityServiceTest.java

Migration Notes

• Shiro 2.1.0 removed or relocated some common exception classes (notably ShiroException). Where code previously caught or referenced the generic ShiroException, it has been updated to catch the more specific exceptions that match actual failure modes:

  • Authentication flows -> org.apache.shiro.authc.AuthenticationException
  • Authorization flows -> org.apache.shiro.authz.AuthorizationException
  • Configuration/initialization issues -> org.apache.shiro.config.ConfigurationException

• Tests were updated to assert against these available exceptions where the original, removed types were referenced. No tests were removed; tests that had been accidentally deleted were restored and corrected.

Testing performed

• Ran Spotless formatting checks and applied fixes (spotlessApply).
• Ran ./gradlew compileTestJava successfully.
• Ran the full test suite: ./gradlew test — BUILD SUCCESSFUL. All modified modules passed unit tests.

Risk and Compatibility

• This is a dependency upgrade that changes exception types used in codepaths interacting with Shiro. The changes are scoped to error handling and configuration of the security integration — behavior outside those flows is unchanged.
• Backwards compatibility note: Consumers of Geode code that relied on catching the generic ShiroException (if any external code did so) may need to adjust to the more specific exceptions. Internal code now uses specific Shiro exceptions aligned with the 2.1.0 API.

Release notes (suggested)

• Upgraded Apache Shiro to 2.1.0 to remediate CVE-2026-23903. Internal security integration updated to use Shiro's 2.1.0 APIs and exception types.

Rollback / mitigation

• To rollback, revert the dependency constraint bump and the small set of API changes in IntegratedSecurityService and SecurityManagerProvider and restore the test updates. A rollback branch or tag should be prepared if needed.

Checklist

• Dependency updated to 2.1.0
• Production code migrated to Shiro 2.1.0 API
• Tests updated and restored where necessary
• Spotless formatting applied
• Full test suite run and passed

Reviewers / Suggested reviewers

• Core security and integration owners
• Build/CI maintainers

If you want, I can also add a short changelog entry and create a rollback tag. Which should I do next?

For all changes, please confirm:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
• Has your PR been rebased against the latest commit within the target branch (typically develop)?
• Is your initial contribution a single, squashed commit?
• Does gradlew build run cleanly?
• Have you written or updated unit tests to verify your changes?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?