Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
☕
☕ Maven
Not in CISA KEV
HIGH severity

io.ratpack:ratpack-core vulnerable to Improper Neutralization of Special Elements in Output ('Injection')GHSA-mvqp-q37c-wf9j

HIGHFix: ratpack/ratpack@c560a8d

GHSA-mvqp-q37c-wf9j is a high-severity (CVSS 7.5) CWE-74 vulnerability in io.ratpack:ratpack-core. A fix is available for io.ratpack:ratpack-core — see the affected versions and patch details below.

Also known asCVE-2019-17513
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
2.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs82th percentile — riskier than 82% of all scored CVEsHighest risk
0.75%1.38%2.02%2.65%1.3%2.2%May 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-mvqp-q37c-wf9j by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
☕io.ratpack:ratpack-core

Real-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.

https://github.com/ratpack/ratpack/blob/af1e8c8590f164d7dd84d4212886fad4ead99080/ratpack-core/src/main/java/ratpack/server/internal/NettyHandlerAdapter.java#L159

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

For more information

If you have any questions or comments about this advisory:

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenio.ratpack:ratpack-coreall versions1.7.5io.ratpack:ratpack-core:1.7.5

Affected Products

1 product · 1 configurations
Application
ratpackratpack_project
< 1.7.5
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.ratpack:ratpack-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. 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.

  3. Workarounds

    Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.

Frequently Asked Questions

## 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](https://www.owasp.org/index.php/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 respo
O3 Security · Impact-Aware SCA

Is GHSA-mvqp-q37c-wf9j in your dependencies?

Find it across Maven, including transitive dependencies.

io.ratpack:ratpack-core vulnerable to Improper…