Open Redirect in admin servlets via request.getRequestURI() in sendRedirect

Openfire Plugins
1

Hello,

During a security scan (SAST) on our Openfire-based deployment, we identified a potential open redirect issue (CWE-601) in the admin/plugin layer.

Affected code pattern:
response.sendRedirect(request.getRequestURI() + …)

Reported locations:

  1. org.jivesoftware.admin.servlet.SystemCacheDetailsServlet (doPost)
  2. org.jivesoftware.admin.servlet.SystemPropertiesServlet (doPost)
  3. org.jivesoftware.openfire.container.PluginServlet (CSRF failure handling)

Concern:
Using request.getRequestURI() as the redirect target may allow manipulation of the redirect destination in some deployments, which could be abused for phishing against admin console users.

Scanner recommendation:
Use fixed internal redirect paths or validate/allowlist redirect targets instead of raw request URI.

We checked the public Openfire source (including v5.1.0) and the same pattern appears to still be present in these files.

Questions for the community/maintainers:

  1. Is this considered a valid security issue for Openfire?
  2. Is there an recommended official fix or configuration mitigation?
  3. Is there an existing Jira ticket for this?

Environment:

  • Openfire 4.7.x based deployment
  • Admin console

Thank you.

2

Openfire 4.7.0 is ancient. Try with 5.1.0

3

Thank you for the suggestion to upgrade.

We reviewed the latest Openfire release (v5.1.0) and master branch source for the same pattern reported by our scanner:

  • SystemCacheDetailsServlet.doPost → sendRedirect(request.getRequestURI() + …)
  • SystemPropertiesServlet.doPost → sendRedirect(request.getRequestURI() + …)
  • PluginServlet (CSRF failure) → sendRedirect(request.getRequestURI())

The pattern still appears present in v5.1.0, so upgrading alone may not address CWE-601 / open redirect for these admin redirects.

Could you confirm:

  1. Whether this is tracked as a separate security issue in Jira ?
  2. Whether a fix is planned for a future release?
  3. What the recommended mitigation is until then (fixed redirect path vs allowlist)?

We understand upgrading is still recommended for other security fixes; we want clarity on this specific finding.

Thanks.

4

Thanks for raising this. If you believe this rises to the level of a genuine security vulnerability, please report it by email to security@ (our website domain) so it can be handled outside of a public forum and tracked appropriately.

Before we can assess whether this warrants a fix, it would help to have some concrete details that go beyond the static analysis finding:

  1. Proof-of-concept request - Can you share an actual HTTP request (e.g. curl command or raw request headers) that results in a Location response header pointing to an external host? The exploitability hinges on whether request.getRequestURI() can be made to return a value that causes sendRedirect() to redirect off-host (which is non-trivial given how servlet containers typically normalise request paths).
  2. Observed Location header-— What does the server actually respond with? A scanner flagging a code pattern is not the same as confirming a redirect to an external destination. Sharing the raw response (with the Location: header) from a test request would make the finding much easier to evaluate.
  3. CSRF handler path - The PluginServlet case is the most interesting of the three, since it fires on a CSRF failure. Have you been able to trigger that code path with a crafted URI, and if so, where does the redirect actually land?

We take security reports seriously, but being able to distinguish a theoretical scanner finding from a demonstrable vulnerability helps us prioritise and respond appropriately. The more concrete the evidence, the faster we can act.