Rack::Session fixes secretless session cookie forgery fallback
TL;DR — rack-session can accept attacker-crafted session cookies without secrets when decryption fails, enabling unauthenticated session manipulation and potential unauthorized access.
What happened
Rack::Session is a session management implementation for Ruby’s Rack ecosystem, commonly used to persist web session state (often via cookies).
CVE-2026-39324 describes a Critical issue in Rack::Session::Cookie when configured with secrets:: if cookie decryption fails, the implementation falls back to a default decoder instead of rejecting the cookie. Per the CVE record, this allows an unauthenticated attacker to submit a crafted session cookie that is accepted as valid session data without knowledge of any configured secret, enabling session content manipulation and potentially unauthorized access.
| Item | Source value |
|---|---|
| Affected package | rack-session |
| Affected versions | >= 2.0.0, < 2.1.2 |
| Severity | CVSS v4.0 9.3 (Critical) |
| CVSS v4.0 vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
Session-cookie acceptance bugs are high-impact because they sit directly on the authentication boundary: a single “fallback” path can nullify the confidentiality/integrity guarantees teams assume from cookie encryption/signing.
Who is impacted
- Applications using
rack-sessionversions>= 2.0.0, < 2.1.2. - Deployments using
Rack::Session::Cookiewithsecrets:configured (the vulnerable decrypt-failure path described in the CVE). - Any service where session state influences authorization decisions (roles, account IDs, feature flags) and is loaded from the cookie.
What to do now
- Follow vendor remediation guidance and apply the latest patched release available at the time of writing.
"This vulnerability is fixed in 2.1.2."
- Inventory where
rack-sessionis deployed (Gemfiles, lockfiles, container images, deployed artifacts) and prioritize internet-facing apps. - Treat this as potential session-integrity exposure:
- expire/invalidate existing sessions as operationally feasible
- rotate any secrets/keys used for session protection if you suspect abuse
- review logs for anomalous
Cookieheaders and unexpected session-state transitions tied to unauthenticated requests
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.