Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A user supplied X-Forwarded-Host header can be used to perform cache poisoning of a cache fronting a Ratpack server if the cache key does not include the X-Forwarded-Host header as a cache key. Users are only vulnerable if they do not configure a custom PublicAddress instance. A custom PublicAddress can be specified by using ServerConfigBuilder::publicAddress. For versions prior to 1.9.0, by default, Ratpack utilizes an inferring version of PublicAddress which is vulnerable. Impact This can be used to perform redirect cache poisoning where an attacker can force a cached redirect to redirect to their site instead of the intended redirect location. Patches As of Ratpack 1.9.0, two changes have been made that mitigate this vulnerability: 1. The default PublicAddress implementation no longer infers the address from the request context, instead relying on the configured bind host/port 2. Relative redirects issued by the application are no longer absolutized; they are passed through as-is…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious attacker can achieve Remote Code Execution (RCE) via a maliciously crafted Java deserialization gadget chain leveraged against the Ratpack session store. If your application does not use Ratpack's session mechanism, it is not vulnerable. Details Attackers with the ability to write to session data, can potentially craft payloads that deserialize unsafe objects, leading to the ability to remotely execute arbitrary code. This is known as an “insecure deserialization” vulnerability, or “gadget vulnerability”. Ratpack allows session data to be stored server side in an external system such as a relational database, or client side via user cookies. When using server side storage, the attacker would need to obtain the ability to write to the session data store. When using client side storage, the attacker would need to obtain the secrets used to encrypt and/or sign the session data stored in user cookies. Ratpack's session mechanism allows storing serialized objects, of…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of Ratpack from 0.9.10 through 1.7.5 are vulnerable to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (aka. XSS) in the development error handler. An attacker can utilize this to perform XSS when an exception message contains untrusted data. As a simplistic example: Impact - Cross-Site Scripting Patches This vulnerability has been patched in Ratpack version 1.7.6. Workarounds If you are unable to update your version of Ratpack, we recommend the following workarounds and mitigations. - Ensure that development mode is disabled in production. - Don't use real customer data (ie. untrusted user input) in development. References - Ratpack development mode - Code Patch - a3cbb13 For more information If you have any questions or comments about this advisory: - Open an issue in ratpack/ratpack - Ask in our Slack channel
Recommended action: Upgrade to 1.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.7.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.