CVE-2016-4437

What Is Apache Shiro?

Apache Shiro is a widely used Java security framework providing authentication, authorization, session management, and cryptography capabilities. It is deployed across thousands of Java web applications — from Spring Boot applications to enterprise Java EE systems — as the security layer handling user login, role-based access control, and session persistence. Shiro's remember-me functionality allows users to persist their login session across browser restarts by storing an encrypted session token in a cookie.

Java deserialization vulnerabilities became one of the most impactful vulnerability classes in enterprise software starting in 2015, following the FoxGlove Security disclosure of Apache Commons Collections gadget chains. Any Java application that deserializes untrusted data — and has exploitable gadget chains on its classpath — is potentially vulnerable to remote code execution via crafted serialized Java objects.

Overview

CVE-2016-4437 (also known as "Shiro-550" in the security community) is a critical deserialization vulnerability in Apache Shiro's remember-me cookie mechanism. Shiro's default configuration uses a hardcoded AES encryption key (kPH+bIxk5D2deZiIxcaaaA== in Base64) to encrypt the remember-me cookie. An unauthenticated attacker who knows this default key can craft a malicious serialized Java object, encrypt it with the default key, and send it as the remember-me cookie. When Shiro decrypts and deserializes the cookie for session validation, it executes the malicious payload — achieving remote code execution without any credentials. Patched in Apache Shiro 1.2.5 (June 2016). CISA added CVE-2016-4437 to the inaugural KEV catalog on November 3, 2021.

Affected Versions

Note: Applications that upgraded to 1.2.5 but did not change from the default key to a randomly generated key may remain vulnerable if the default key has been rotated into custom configuration.

Technical Details

Root Cause: Hardcoded AES Key + Java Deserialization

CVE-2016-4437 combines two weaknesses into a critical exploit chain:

Weakness 1 — Hardcoded encryption key: Apache Shiro's default configuration encrypted the remember-me cookie using AES-128-CBC with a static default key: kPH+bIxk5D2deZiIxcaaaA== (Base64). This key was hardcoded in the Shiro source code and used unchanged by any deployment that did not explicitly configure a custom key.

Weakness 2 — Java deserialization of decrypted cookie content: When Shiro receives a remember-me cookie:

1. It Base64-decodes the cookie value
2. Decrypts it using the AES key
3. Deserializes the decrypted bytes using Java's ObjectInputStream

Because Java deserialization executes code in the process of reconstructing objects, an attacker who controls the encrypted content controls what gets deserialized.

Exploit chain:

1. Generate a malicious serialized Java payload using ysoserial (e.g., CommonsCollections4 gadget chain) targeting any library on the Shiro application's classpath
2. Encrypt the payload with AES-128-CBC using the default key: kPH+bIxk5D2deZiIxcaaaA==
3. Base64-encode the result and set it as the rememberMe cookie value in an HTTP request
4. Send the request to the Shiro-protected application — the application decrypts and deserializes the payload, executing arbitrary OS commands as the application server process user

Why the Default Key Matters

The hardcoded default key converted what would normally be a "deserialize untrusted data" vulnerability (requiring an insider or cookie forgery to exploit) into a zero-credential network-exploitable vulnerability: anyone who knew the default key (which was public in the Shiro source code) could craft the malicious cookie without any prior access.

Attack Characteristics

Discovery

The vulnerability was discovered and reported to the Apache Shiro security team; the JIRA issue SHIRO-550 documented the problem. Apache released Shiro 1.2.5 on June 3, 2016, which generates a random AES key at application startup rather than using a hardcoded default.

Exploitation Context

• "Shiro-550" designation: CVE-2016-4437 is widely known as "Shiro-550" in the Chinese security community, which developed extensive tooling and exploitation techniques around this vulnerability; tools like shiro_tool.jar and shiro-exploit automate key detection and payload delivery
• Recurring Shiro deserialization class: Apache Shiro was affected by multiple deserialization-related vulnerabilities after CVE-2016-4437; CVE-2019-12422 ("Shiro-721") was a related padding oracle attack; the Shiro deserialization attack surface has remained a target for years
• Java deserialization epidemic: CVE-2016-4437 occurred during the peak of Java deserialization vulnerability discovery in 2015–2016; the same gadget chains (Apache Commons Collections) that enabled WebLogic exploitation (CVE-2015-4852) also enabled Shiro exploitation
• Enterprise Java exposure: Shiro is deployed in many enterprise Java applications, including intranet portals and API gateways; the remember-me cookie endpoint is accessible at any Shiro-protected login page
• Inaugural CISA KEV batch: Added November 3, 2021, reflecting continued exploitation against unpatched Shiro deployments

Remediation

1. Upgrade to Apache Shiro 1.2.5 or later — Shiro 1.2.5 forces applications to configure a random AES key rather than using the default. All current Shiro versions (1.x, 2.x) address this requirement.

2. Generate and configure a random AES key — in shiro.ini or Spring configuration, explicitly set securityManager.rememberMeManager.cipherKey to a randomly generated 128-bit or 256-bit key. Do not use the default key (kPH+bIxk5D2deZiIxcaaaA==) or any other publicly known key.

3. Verify no default key is in use — search application configuration for the default Base64-encoded key string; any application still using the default key is vulnerable regardless of Shiro version if the key is explicitly configured.

4. Disable remember-me if not needed — if remember-me functionality is not required, disable it entirely: securityManager.rememberMeManager = org.apache.shiro.mgt.DisabledRememberMeManager.

5. Implement Java deserialization filters — apply Java serialization filters (JEP 290, available in Java 9+, backported to Java 8u121) to restrict which classes can be deserialized; this limits the impact of gadget chain exploitation.

6. Monitor for Shiro exploitation indicators — watch for rememberMe=deleteMe in HTTP responses (Shiro's default response when deserialization fails), which may indicate active exploitation attempts.