How severe is GHSA-33qg-7wpp-89cq?

No CVSS score has been assigned to GHSA-33qg-7wpp-89cq yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-33qg-7wpp-89cq?

GHSA-33qg-7wpp-89cq affects the following packages: rack-session (RubyGems). Ecosystems affected: RubyGems.

How do I fix GHSA-33qg-7wpp-89cq?

Update rack-session to 2.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-33qg-7wpp-89cq is resolved across your whole dependency graph.

How do I detect GHSA-33qg-7wpp-89cq in my RubyGems dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rack-session. 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.

How do I mitigate GHSA-33qg-7wpp-89cq if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-33qg-7wpp-89cq?

O3 pinpoints whether GHSA-33qg-7wpp-89cq is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-33qg-7wpp-89cq actively exploited in the wild?

No public exploit code has been indexed for GHSA-33qg-7wpp-89cq 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 type of vulnerability is GHSA-33qg-7wpp-89cq?

GHSA-33qg-7wpp-89cq is classified as Improper Authentication (CWE-287), CWE-345 (CWE-345), Deserialization of Untrusted Data (CWE-502), CWE-565 (CWE-565). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

When was GHSA-33qg-7wpp-89cq published, and has it been updated?

GHSA-33qg-7wpp-89cq was published on April 8, 2026 and was last updated on May 13, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

💎 RubyGems

GHSA-33qg-7wpp-89cq

GHSA-33qg-7wpp-89cq is a Improper Authentication vulnerability in rack-session. O3 Security confirms whether GHSA-33qg-7wpp-89cq is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Rack::Session::Cookie secrets: decrypt failure fallback enables secretless session forgery and Marshal deserialization

Also known asCVE-2026-39324

Published

Apr 8, 2026

Updated

May 13, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

💎rack-session

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.

Description

Rack::Session::Cookie incorrectly handles decryption failures when configured with secrets:. If cookie decryption fails, the implementation falls back to a default decoder instead of rejecting the cookie. This allows an unauthenticated attacker to supply a crafted session cookie that is accepted as valid session data without knowledge of any configured secret.

Because this mechanism is used to load session state, an attacker can manipulate session contents and potentially gain unauthorized access.

Details

When secrets: is configured, Rack::Session::Cookie attempts to decrypt incoming session cookies using one of the configured encryptors. If all decrypt attempts fail, the implementation does not reject the cookie. Instead, it falls back to decoding the cookie using a default coder.

This fallback path processes attacker-controlled cookie data as trusted session state. The behavior is implicit and occurs even when encrypted cookies are expected.

The fallback decoder is applied automatically and does not require the application to opt into a non-encrypted session format. As a result, a client can send a specially crafted cookie value that bypasses the intended integrity protections provided by secrets:.

This issue affects both default configurations and those using alternative serializers for encrypted payloads.

Impact

Any Rack application using Rack::Session::Cookie with secrets: may be affected.

[!NOTE] Rails applications are typically not affected — Rails uses ActionDispatch::Session::CookieStore, which is a separate implementation backed by ActiveSupport::MessageEncryptor and does not share the vulnerable code path.

An unauthenticated attacker can supply a crafted session cookie that is accepted as valid session data. This can lead to authentication bypass or privilege escalation in applications that rely on session values for identity or authorization decisions.

Depending on application behavior and available runtime components, processing of untrusted session data may also expose additional risks.

Mitigation

Update to a patched version ofrack-session that rejects cookies when decryption fails under the secrets: configuration.
- After updating, rotate session secrets to invalidate existing session cookies, since attacker-supplied session data may have been accepted and re-issued prior to the fix.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
💎RubyGems	`rack-session`	≥ 2.0.0&&< 2.1.2	2.1.2

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rack-session. 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 rack-session to 2.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-33qg-7wpp-89cq 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-33qg-7wpp-89cq 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-33qg-7wpp-89cq. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

`Rack::Session::Cookie` incorrectly handles decryption failures when configured with `secrets:`. If cookie decryption fails, the implementation falls back to a default decoder instead of rejecting the cookie. This allows an unauthenticated attacker to supply a crafted session cookie that is accepted as valid session data without knowledge of any configured secret. Because this mechanism is used to load session state, an attacker can manipulate session contents and potentially gain unauthorized access. ## Details When `secrets:` is configured, `Rack::Session::Cookie` attempts to decrypt inco

O3 Security · Impact-Aware SCA

Is GHSA-33qg-7wpp-89cq in your dependencies?

O3 detects GHSA-33qg-7wpp-89cq across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works