CVE-2026-33306
MEDIUM
GHSA-f27w-vcwj-c954
CVSS Vector
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3Description
### Impact An integer overflow in the Java BCrypt implementation for JRuby can cause zero iterations in the strengthening loop. Impacted applications must be setting the cost to 31 to see this happen. The JRuby implementation of bcrypt-ruby (`BCrypt.java`) computes the key-strengthening round count as a signed 32-bit integer. When `cost=31` (the maximum allowed by the gem), signed integer overflow causes the round count to become negative, and the strengthening loop executes **zero iterations**. This collapses bcrypt from 2^31 rounds of exponential key-strengthening to effectively constant-time computation - only the initial EksBlowfish key setup and final 64x encryption phase remain. The resulting hash looks valid (`$2a$31$...`) and verifies correctly via `checkpw`, making the weakness invisible to the application. This issue is triggered only when cost=31 is used or when verifying a `$2a$31$` hash. ### Patches This problem has been fixed in version 3.1.22 ### Workarounds Set the cost to something less than 31.
Analysis
JRuby's BCrypt implementation suffers from a signed integer overflow when the cost parameter is set to 31, causing the key-strengthening loop to execute zero iterations and reducing password hashing to a negligible computational cost. Applications using bcrypt-ruby with cost=31 generate seemingly valid hashes that verify correctly but provide virtually no protection against brute-force attacks. …
Sign in for full analysis, threat intelligence, and remediation guidance.
Remediation
Within 30 days: Identify affected systems and apply vendor patches as part of regular patch cycle. Monitor vendor channels for patch availability.
Sign in for detailed remediation steps.
Priority Score
Share
External POC / Exploit Code
Leaving vuln.today