CVE-2026-58301: Apache Shiro SSRF Vulnerability

CVE-2026-58301 Overview

CVE-2026-58301 is a Server-Side Request Forgery (SSRF) vulnerability in Apache Shiro when deployed with the Jakarta EE integration module. A low-privileged authenticated user can craft an HTTP request that forces the server to initiate a connection to an attacker-controlled URL and transmit attacker-controlled data. The flaw is tracked under CWE-918 and affects Apache Shiro versions 2.x through 3.0.0.

The issue resides in Shiro's form resubmission logic within the Jakarta EE integration, which does not sufficiently restrict the destination host and port when replaying requests. Deployments that do not use the Jakarta EE integration module are not affected.

Critical Impact
An authenticated attacker can pivot the vulnerable server to reach internal services, exfiltrate data to attacker-controlled endpoints, and interact with metadata services in cloud environments.

Affected Products

Apache Shiro 2.0.0 through 3.0.0 (Jakarta EE integration module only)
Applications using org.apache.shiro:shiro-jakarta-ee dependency
Java web applications relying on Shiro form resubmission behavior

Discovery Timeline

2026-08-31 - CVE-2026-58301 published to NVD
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-58301

Vulnerability Analysis

Apache Shiro is a widely used Java security framework providing authentication, authorization, cryptography, and session management. The Jakarta EE integration module ships form resubmission functionality that reconstructs and replays HTTP requests interrupted by an authentication challenge.

When a user is redirected to authenticate mid-request, Shiro stores the original request and later resubmits it. In vulnerable versions, the destination of that resubmission can be influenced by request-controlled fields, allowing an authenticated user to target an arbitrary URL. Because the server issues the outbound request itself, the attacker gains access to network destinations reachable by the application server but not by the client.

Exploitation requires low privileges and user interaction to trigger the resubmission flow, which limits mass exploitation but preserves value for adversaries with a foothold. The impact aligns with typical SSRF outcomes: internal service reconnaissance, interaction with cloud instance metadata endpoints, and outbound exfiltration of the resubmitted form payload.

Root Cause

The root cause is missing validation of the host and port used during form resubmission in the Jakarta EE integration module. Shiro trusted request-derived values when constructing the outbound connection URL, without enforcing an allowlist of permitted destinations.

Attack Vector

The attack is network-based and requires an authenticated low-privileged session. An attacker submits a form that triggers Shiro's authentication and resubmission workflow, manipulating parameters so that the server reconnects to an attacker-controlled host. The server then transmits attacker-controlled form data to that destination, completing the SSRF primitive.

No verified public exploit or proof-of-concept has been published. See the Apache thread discussion and the Openwall OSS Security update for vendor-provided technical details.

Detection Methods for CVE-2026-58301

Indicators of Compromise

Outbound HTTP or HTTPS connections from Java application servers to unexpected external hosts, originating from Shiro's resubmission code path.
Application logs showing form resubmission events targeting hosts outside the deployment's normal service topology.
Connections from application servers to cloud metadata endpoints such as 169.254.169.254 that do not correspond to legitimate SDK activity.

Detection Strategies

Inventory running Java applications for the shiro-jakarta-ee module at versions 2.x through 3.0.0 using software composition analysis.
Correlate authenticated user sessions with subsequent outbound connections from the application server to detect SSRF pivots.
Baseline egress destinations for application servers and alert on new external hosts contacted after authentication redirects.

Monitoring Recommendations

Enable verbose logging on the Shiro filter chain and forward events to a centralized data lake for correlation.
Monitor egress firewall logs for connections initiated by JVM processes to non-allowlisted hosts and ports.
Track use of the org.apache.shiro.form-resubmit-host and org.apache.shiro.form-resubmit-port system properties across environments to confirm mitigation coverage.

How to Mitigate CVE-2026-58301

Immediate Actions Required

Upgrade Apache Shiro to version 3.0.1 or later, which contains the fix for the Jakarta EE integration module.
If immediate upgrade is not possible, set the org.apache.shiro.form-resubmit-host and org.apache.shiro.form-resubmit-port system properties to constrain the resubmission destination.
Restrict outbound network access from application servers to only the hosts and ports required for business function.
Audit application logs for prior form resubmission activity targeting unexpected destinations.

Patch Information

The Apache Shiro project addressed CVE-2026-58301 in version 3.0.1. Refer to the Apache Shiro security advisory thread for release notes and the Openwall OSS Security update for coordinated disclosure details.

Workarounds

Define org.apache.shiro.form-resubmit-host as a String system property pinned to the application's own hostname.
Define org.apache.shiro.form-resubmit-port as an Integer system property pinned to the application's listening port.
Enforce egress filtering at the network layer to block application servers from reaching internal management interfaces and cloud metadata endpoints.

bash

# Configuration example: restrict Shiro form resubmission via JVM system properties
java \
  -Dorg.apache.shiro.form-resubmit-host=app.internal.example.com \
  -Dorg.apache.shiro.form-resubmit-port=8443 \
  -jar your-application.jar