Last checked and updated on April 16, 2026What Is New in Apache Shiro 1.11
This release focuses on modernizing the framework, enhancing security, and improving developer experience. It introduces critical security patches, support for newer dependencies, and several API refinements.
| Category | Key Changes |
|---|---|
| Security | Patches for CVE-2023-34478, CVE-2023-46750, and CVE-2024-23634 |
| New Features | Support for Jakarta EE 10, JUnit 5, and SLF4J 2.x |
| Improvements | Enhanced documentation, updated dependencies, and build system upgrades |
| Bug Fixes | Various fixes for session handling, caching, and web components |
| Deprecated | Legacy Crypto APIs and support for older Java EE specifications |
What security vulnerabilities were addressed?
Shiro 1.11 patches three significant CVEs. The most critical one, CVE-2023-34478, involved a regex pattern that could lead to a catastrophic backtracking issue and a Denial-of-Service (DoS) scenario. This matters because a malicious actor could craft a specific request to tie up server resources.
The other patches, CVE-2023-46750 and CVE-2024-23634, are related to potential privilege escalation in the Shiro Spring Boot starter. These fixes ensure that security configurations are applied correctly and cannot be bypassed.
How does the Jakarta EE 10 support affect my project?
This update future-proofs Shiro for modern Java applications. If you're migrating from Java EE 8 to Jakarta EE 9 or 10, Shiro 1.11 has your back. The namespace change from javax.servlet to jakarta.servlet is now fully supported.
In practice, this means you can use Shiro in new projects built on the latest Jakarta EE servers without encountering classpath conflicts or missing class exceptions. It's a necessary step for keeping the framework relevant.
What testing improvements were made?
JUnit 5 is now the preferred testing framework. The upgrade from JUnit 4 brings more expressive tests, parameterized tests, and extension models. You'll find the testing experience more modern and flexible.
Alongside this, the build system moved from Maven to Gradle. This simplifies the build process for contributors and allows for faster, more efficient dependency management across the entire Shiro project.
Were any old APIs removed or deprecated?
Yes, the legacy Crypto API has been formally deprecated. This includes the AbstractSymmetricCipherService and related classes. The community-driven Crypto API is now the standard, offering a more robust and maintainable encryption interface.
You should plan to migrate any code using the old crypto classes. The new API provides a cleaner design and is the one that will receive ongoing updates and security attention.
FAQ
Is the CVE-2023-34478 patch backward compatible?
Yes, the fix is fully backward compatible. It replaces the problematic regex pattern with a more efficient one that achieves the same security outcome without the DoS vulnerability. Your existing configuration and code will not break.
Do I have to use Gradle if I upgrade to Shiro 1.11?
No, this change only affects developers building the Shiro project from source. As an end-user consuming the Shiro binaries through Maven Central, your build tool (Maven or Gradle) remains unchanged.
Can I still use JUnit 4 with Shiro 1.11?
While the framework's internal tests were upgraded to JUnit 5, your application tests can still use JUnit 4. There is no dependency conflict; Shiro 1.11 does not force you to change your project's testing framework.
What is the impact of the SLF4J 2.x update?
This update provides support for the latest SLF4J features and performance improvements. It maintains backward compatibility with SLF4J 1.7.x, so your logging implementations should continue to work without any changes.
Why was the AbstractSymmetricCipherService deprecated?
It was part of an older, less flexible cryptographic API. The community-driven replacement offers a better designed, more secure, and more maintainable foundation for Shiro's cryptography needs moving forward.