Loading vulnerability…
CVE-2026-39324 affects Rack::Session versions 2.0.0 through 2.1.1. When Rack::Session::Cookie is configured with secrets, a session-cookie decryption failure is incorrectly handled by falling back to a default decoder rather than rejecting the cookie. An attacker can therefore submit a crafted cookie that is accepted as session state without possessing a configured secret, enabling tampering with server-consumed session contents and possible unauthorized access.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a compact Ruby proof-of-concept for CVE-2026-39324 affecting rack-session <= 2.1.1. It demonstrates that Rack::Session::Cookie configured with secrets: can incorrectly accept an unencrypted Base64(Marshal.dump(...)) cookie when decryption fails, because execution falls back to the default Base64::Marshal decoder instead of rejecting the cookie. Repository structure: README.md documents the vulnerability, root cause, reproduction steps, and mitigation. Under poc/, Gemfile and Gemfile.lock define a minimal Ruby environment using rack-session 2.1.1, rack, rackup, and webrick. The code files are: server.rb, which starts a vulnerable local Rack application on 127.0.0.1:9416 with Rack::Session::Cookie key rack.session and two configured secrets; verify.rb, which performs baseline checks showing that unauthenticated access and a normal non-admin session cannot access /admin; and attack.rb, the actual exploit, which forges a plaintext serialized session cookie and sends it to /admin. Main exploit capability: attack.rb does not need any secret material. It serializes a Ruby hash containing session_id and a chosen user_id, Base64-encodes it, and places it directly into the rack.session cookie. The exploit then issues a GET request to /admin. On a vulnerable target, decrypt attempts fail but the application falls back to Marshal decoding, accepts the attacker-controlled session, resolves user_id=2 as the admin user, and returns HTTP 200 with admin content. This is a web attack vector enabling authentication bypass / privilege escalation via session forgery. The PoC is operational rather than framework-based: it includes a working vulnerable server and a working exploit script, but payload customization is basic and hardcoded around session manipulation. No destructive behavior or fake logic is present.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.