GHSA-mvqp-q37c-wf9j is a high-severity (CVSS 7.5) CWE-74 vulnerability in io.ratpack:ratpack-core. O3 Security confirms whether GHSA-mvqp-q37c-wf9j is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
io.ratpack:ratpack-core vulnerable to Improper Neutralization of Special Elements in Output ('Injection')
Real-World Exposure
io.ratpack:ratpack-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
Versions of Ratpack 0.9.1 through and including 1.7.4 are vulnerable to HTTP Response Splitting, if untrusted and unsanitized data is used to populate the headers of an HTTP response. An attacker can utilize this vulnerability to have the server issue any HTTP response they specify.
If your application uses arbitrary user input as the value of a response header it is vulnerable. If your application does not use arbitrary values as response header values, it is not vulnerable.
Previously, Ratpack did not validate response header values. Now, adding a header value that contains the header value termination characters (CRLF) produces a runtime exception. Since there is no mechanism for escaping or encoding the termination characters in a String, a runtime exception is necessary.
As potentially dangerous values now cause runtime exceptions, it is a good idea to continue to validate and sanitize any user-supplied values being used as response headers.
We would like to thank Jonathan Leitschuh for reporting this vulnerability.
Vulnerable Example
The following example server uses a query parameter value as a response header, without validating or sanitizing it.
RatpackServer startedServer = RatpackServer.start(server -> {
server.handlers(chain -> chain.all(ctx -> {
// User supplied query parameter
String header = ctx.getRequest().getQueryParams().get("header");
// User supplied data used to populate a header value.
ctx.header("the-header", header)
.render("OK!");
}));
});
Sending a request to the server with the following value for the header query param would allow the execution of arbitrary Javascript.
Content-Type: text/html
X-XSS-Protection: 0
<script>alert(document.domain)</script>
Impact
- Cross-User Defacement
- Cache Poisoning
- Cross-Site Scripting
- Page Hijacking
Patches
This vulnerability has been patched in Ratpack version 1.7.5.
Root Cause
The root cause was due to using the netty DefaultHttpHeaders object with verification disabled.
This vulnerability is now more clearly documented in the Netty documentation: https://github.com/netty/netty/pull/9646
Workarounds
The workaround for this vulnerability is to either not use arbitrary input as response header values or validate such values before being used to ensure they don't contain a carriage return and/or line feed characters.
References
- CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
- Fix commit: https://github.com/ratpack/ratpack/commit/efb910d38a96494256f36675ef0e5061097dd77d
For more information
If you have any questions or comments about this advisory:
- Open an issue in ratpack/ratpack
- Ask in our Slack channel
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.ratpack:ratpack-core | all versions | 1.7.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.ratpack:ratpack-core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update io.ratpack:ratpack-core to 1.7.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mvqp-q37c-wf9j is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-mvqp-q37c-wf9j is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-mvqp-q37c-wf9j. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-mvqp-q37c-wf9j in your dependencies?
O3 detects GHSA-mvqp-q37c-wf9j across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.