CVE-2026-39324

What it actually does

Rack::Session::Cookie versions 2.0.0 through versions before 2.1.2 mishandle failed decryption when configured with secrets:. Instead of rejecting a session cookie that cannot be decrypted with the configured secret, the code falls back to a default decoder and may accept attacker-supplied serialized session data. Because Rack session data is commonly used to store authentication and authorization state, this can allow unauthenticated remote attackers to forge or modify session contents, potentially impersonate users, elevate privileges, or alter application state without knowing the application’s session secret.

Why it matters to the business

Applications that rely on affected Rack session cookies may allow attackers to bypass login controls or assume privileged application roles using only network access. This can lead to account takeover, unauthorized data access, fraudulent transactions, administrative abuse, and loss of trust in application integrity. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the CVSS severity is critical because exploitation requires no authentication, no user interaction, and can directly affect confidentiality, integrity, and availability.

How an attack unfolds

An attacker identifies a Rack-based application using Rack::Session::Cookie with the vulnerable rack-session package and secrets: configuration. The attacker sends an HTTP request containing a crafted session cookie that intentionally fails normal encrypted-cookie decryption. In vulnerable versions, the decryption failure is not treated as a hard rejection; the implementation falls back to a default decoding path. If the crafted cookie is decoded as session data, the application may load attacker-controlled session keys and values. Depending on how the application stores identity, roles, CSRF state, feature flags, or workflow state in the session, the attacker may be able to create an authenticated session, impersonate another user, set elevated privileges, or manipulate protected application behavior.

How to fix it

Upgrade rack-session to version 2.1.2 or later wherever Rack::Session::Cookie is used. Because the package may be pulled in transitively by Ruby frameworks or middleware, review Gemfile.lock, dependency lockfiles, container images, and deployed artifacts for rack-session versions 2.0.0 through 2.1.1. After upgrading, redeploy all affected applications and restart application processes so the fixed library is loaded. As a defense-in-depth measure, invalidate existing session cookies by rotating session secrets or changing the session cookie signing/encryption configuration, especially for applications storing authentication or authorization state in the session. Avoid placing high-trust authorization decisions solely in client-side session data; validate privilege and identity server-side where possible. If immediate upgrade is not possible, temporarily reduce exposure by forcing reauthentication, shortening session lifetime, increasing monitoring for anomalous session behavior, and restricting access to sensitive administrative routes.

How to confirm the fix worked

Confirm that deployed applications load rack-session 2.1.2 or later, not only that source manifests were updated. Validate with dependency tooling such as bundle list, bundle info rack-session, Gemfile.lock review, SBOM scans, container image scans, and runtime package inventory. Test affected applications by ensuring malformed or undecryptable session cookies are rejected and result in a new anonymous session or an error path, not accepted as session state. Review CI/CD and image build pipelines to ensure older cached gems are not reintroduced. Confirm application restarts occurred after patching. If session secrets were rotated, verify old cookies are no longer accepted and users are required to obtain fresh sessions.

Typical attack path

1. Identify a Rack/Ruby web application that uses cookie-backed sessions via Rack::Session::Cookie.
2. Confirm the application is using rack-session versions 2.0.0 through before 2.1.2 and a secrets: configuration, directly or through a framework dependency.
3. Craft a session cookie that fails encrypted-cookie decryption but remains acceptable to the fallback decoder.
4. Send the crafted cookie in HTTP requests to the target application.
5. Observe whether the application accepts attacker-controlled session values, such as authentication or authorization-related fields.
6. Use the accepted forged session to access protected routes, impersonate users, elevate privileges, or alter application state.

How to detect it

Retrospective detection should focus on application, web access, authentication, and authorization logs because exploitation occurs through HTTP cookies and may not create a distinctive system-level artifact. Look for requests containing unusually large, malformed, or high-entropy session cookies followed by successful access to authenticated routes without a normal login event. Correlate session identifiers, user identifiers, IP addresses, user agents, and timestamps to find sessions that appear to change identity, role, or privilege unexpectedly. Review logs for administrative actions, account changes, data exports, or sensitive route access where there is no preceding successful authentication event. Investigate spikes in 400/500 responses or session deserialization/decoding errors followed by successful authenticated requests from the same source. If application logging captures cookie decoding exceptions, search around those events for subsequent successful requests. Compare known legitimate session lifecycle events, such as login, logout, MFA completion, and session renewal, against protected-resource access. Network telemetry may show repeated requests with modified Cookie headers, but there is no reliable universal payload signature for this issue. Host forensics should verify deployed gem versions and application restarts, but exploitation itself is unlikely to leave file, process, or registry artifacts unless followed by application-level abuse.

What your security team should do

• Prioritize patching internet-facing and high-privilege Rack/Ruby applications using Rack::Session::Cookie, especially administrative portals, customer portals, and applications storing identity or roles in sessions.
• Upgrade rack-session to 2.1.2 or later across source repositories, lockfiles, base images, and deployed containers.
• Rotate session secrets or otherwise invalidate existing session cookies after upgrade to reduce risk from any previously forged or captured session state.
• Search application logs for suspicious session anomalies, such as sudden privilege changes, unexpected access to protected routes, repeated requests with malformed cookies, or user identity changes without corresponding login events.
• Review application code for reliance on client-side session values for authorization decisions and move critical privilege checks server-side where feasible.
• Add dependency scanning policy to block rack-session versions 2.0.0 through 2.1.1 from future builds.
• Because no KEV listing, ransomware use, or mature public exploit is currently reported, treat this as urgent based on critical technical severity rather than confirmed exploitation in the wild.