HTTP Response Splitting and Open Redirect in Apache Juneau
CVE-2026-73117 affects Apache Juneau REST server through version 9.2.0. Response header values and redirect targets are passed to the servlet container without validation; header sanitization is available only through the opt-in setSafeHeaders(), and sendRedirect() accepts arbitrary targets. Applications that derive response header values from request data can permit CRLF injection and HTTP response splitting if the servlet container does not reject CR/LF characters. Applications that derive redirect targets from request data can permit redirects to arbitrary external sites. Exposure depends on application code because the framework does not itself construct headers or redirect targets from request data.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Remote attackers can inject additional HTTP response header lines in affected applications when the servlet container accepts CR/LF characters. Independently, attacker-controlled redirect targets can cause applications to redirect users to arbitrary external sites. The impact depends on how application code incorporates untrusted request data and, for header injection, the servlet container's validation behavior.
If you can’t patch tonight, do this now.
Enable setSafeHeaders() on affected versions, or reject CR/LF characters before passing values to response headers. Avoid using untrusted request data directly in headers or redirect targets, and validate redirect destinations against an allow-list of trusted locations. Servlet-container rejection of CR/LF can prevent header injection but does not address open redirects.
Patch, then assume compromise.
Upgrade juneau-rest-server and any shaded or aggregate artifacts embedding it to Apache Juneau 9.2.1, which sanitizes response header values by default. Do not disable this protection with setUnsafeHeaders(). Applications constructing redirect targets from request data must explicitly replace sendRedirect() with RestResponse.sendSafeRedirect(String,String...), restricting destinations to relative paths or allow-listed hosts. Upgrading alone does not remediate unsafe application redirects.
No public exploits tracked yet. Mallory keeps watching.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.