How severe is CVE-2021-29481?

CVE-2021-29481 has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by CVE-2021-29481?

CVE-2021-29481 affects the following packages: io.ratpack:ratpack-session (Maven). Ecosystems affected: Maven.

How do I fix CVE-2021-29481?

Update io.ratpack:ratpack-session to 1.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2021-29481 is resolved across your whole dependency graph.

How do I detect CVE-2021-29481 in my Maven dependencies?

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

How do I mitigate CVE-2021-29481 if there is no patch (or I can't update yet)?

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.

Is CVE-2021-29481 actively exploited in the wild?

No public exploit code has been indexed for CVE-2021-29481 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2021-29481?

CVE-2021-29481 has an EPSS (Exploit Prediction Scoring System) score of 0.5%, placing it in the 40th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2021-29481?

CVE-2021-29481 is classified as CWE-312 (CWE-312). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2021-29481 published, and has it been updated?

CVE-2021-29481 was published on June 29, 2021 and was last updated on October 20, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

☕

☕ Maven

Not in CISA KEV

HIGH severity

CVE-2021-29481 — ratpack-session

HIGHFix: ratpack/ratpack#1590

CVE-2021-29481 is a high-severity (CVSS 7.5) CWE-312 vulnerability in io.ratpack:ratpack-session. A fix is available for io.ratpack:ratpack-session — see the affected versions and patch details below.

Unencrypted storage of client side sessions

Also known asGHSA-phj8-4cq3-794g

Published

Jun 29, 2021

Updated

Oct 20, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Nov 2, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗

0.5%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs40th percentile — riskier than 40% of all scored CVEsHighest risk

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

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected

☕io.ratpack:ratpack-session

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

Impact

The default configuration of client side sessions results in unencrypted, but signed, data being set as cookie values. This means that if something sensitive goes into the session, it could be read by something with access to the cookies.

Note: the documentation does point this out and encourage users to add an encryption key, but it is not mandatory.

For this to be a vulnerability, some kind of sensitive data would need to be stored in the session and the session cookie would have to leak. For example, the cookies are not configured with httpOnly and an adjacent XSS vulnerability within the site allowed capture of the cookies.

The proposed change is to change the default behaviour to use a randomly generated encryption key. This would mean that sessions do not survive app restarts, but this is already the behaviour given the random signing key.

Patches

As of version 1.9.0, a securely randomly generated signing key is used.

Workarounds

Supply an encryption key, as per the documentation recommendation.

References

https://github.com/ratpack/ratpack/pull/1590

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`io.ratpack:ratpack-session`	all versions	1.9.0`io.ratpack:ratpack-session:1.9.0`

Affected Products

1 product · 1 configurations

Application

ratpackratpack_project

< 1.9.0

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.ratpack:ratpack-session, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update io.ratpack:ratpack-session to 1.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2021-29481 is resolved across your whole dependency graph.
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

### Impact The default configuration of client side sessions results in unencrypted, but signed, data being set as cookie values. This means that if something sensitive goes into the session, it could be read by something with access to the cookies. Note: the documentation does point this out and encourage users to add an encryption key, but it is not mandatory. For this to be a vulnerability, some kind of sensitive data would need to be stored in the session and the session cookie would have to leak. For example, the cookies are not configured with httpOnly and an adjacent XSS vulnerabilit