GHSA-hc33-32vw-rpp9
CRITICALGHSA-hc33-32vw-rpp9 is a critical-severity (CVSS 9.9) Deserialization of Untrusted Data vulnerability in io.ratpack:ratpack-core. O3 Security confirms whether GHSA-hc33-32vw-rpp9 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Remote Code Execution Vulnerability in Session Storage
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
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 arbitrary types. The type must be specified when writing the data and when reading, with data only deserialized when there is an exact type match. However, in the process of deserializing an object of a known/trusted/deserialization-safe type, it may attempt to deserialize unsafe types.
By default Ratpack uses Java's built-in serialization mechanism, though other serialization providers can be used. The exact types of payloads required to enable an exploit depend on the exact serialization mechanism used.
To mitigate this vulnerability, Ratpack now employs a “strict allow-list” when deserializing (and serializing) objects to session data. All concrete types of objects serialized must be explicitly declared as safe. Some standard well known JDK types are registered by default.
Serialization is provided by implementations of SessionSerializer.
Its existing methods have been deprecated, and replaced with a new methods that accept a SessionTypeFilter that can be used to assert whether a type is allowed when serializing and deserializing.
The default serializer implementation has been updated to use this mechanism. Any proprietary implementations should also be updated to consult the type filter before serializing or deserializing data. Warnings will be logged any time an implementation that does not implement the new methods is used.
Upon upgrading to Ratpack 1.9, users of the built-in serialization mechanism will need to change their application to declare all types currently being serialized as being safe. This can be done using the new SessionModule.allowTypes() method. Please see its documentation for details...))
Patches
Ratpack 1.9.0 introduces a strict allow-list mechanism that mitigates this vulnerability when used.
Workarounds
The simplest mitigation for users of earlier versions is to reduce the likelihood of attackers being able to write to the session data store.
Alternatively or additionally, the allow-list mechanism could be manually back ported by providing an alternative implementation of SessionSerializer that uses an allow-list.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.ratpack:ratpack-core | all versions | 1.9.0 |
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.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hc33-32vw-rpp9 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-hc33-32vw-rpp9 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-hc33-32vw-rpp9. 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-hc33-32vw-rpp9 in your dependencies?
O3 detects GHSA-hc33-32vw-rpp9 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.