CVE-2026-33306 in bcrypt-ruby
Summary
by MITRE • 03/24/2026
bcrypt-ruby is a Ruby binding for the OpenBSD bcrypt() password hashing algorithm. Prior to version 3.1.22, 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. This problem has been fixed in version 3.1.22. As a workaround, set the cost to something less than 31.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/30/2026
The vulnerability described in CVE-2026-33306 affects the bcrypt-ruby gem, specifically its Java implementation within JRuby environments. This security flaw stems from an integer overflow condition that fundamentally undermines the cryptographic strength of password hashing operations. The vulnerability manifests when applications utilize the maximum cost parameter value of 31, which is the highest permissible setting for the bcrypt algorithm's work factor. The underlying issue resides in the BCrypt.java implementation where the key-strengthening round count is calculated using a signed 32-bit integer data type. When the cost parameter reaches its maximum value of 31, the mathematical computation results in a signed integer overflow that transforms the intended large positive value into a negative number.
The operational impact of this vulnerability is severe and potentially catastrophic for security-conscious applications. When the integer overflow occurs, the strengthening loop that should execute 2^31 times instead runs zero iterations, effectively eliminating the core security benefit of bcrypt's iterative hashing process. This transformation reduces the cryptographic strength from exponential complexity to near-constant time computation, making password hashes significantly more vulnerable to brute force attacks and rainbow table generation. The resulting hash values maintain their valid format ($2a$31$...) and will successfully validate through standard verification functions like checkpw, making the weakness completely invisible to applications and users. This characteristic renders the vulnerability particularly dangerous as it operates silently without alerting administrators or developers to the compromised security posture.
The technical flaw represents a classic integer overflow vulnerability that maps to CWE-190, which specifically addresses integer overflow conditions that can lead to unexpected behavior in cryptographic implementations. This vulnerability also aligns with ATT&CK technique T1212, which covers exploitation of cryptographic libraries and the manipulation of cryptographic parameters to weaken security. The vulnerability affects only JRuby implementations of bcrypt-ruby, as the native Ruby version does not exhibit this specific integer overflow behavior due to different underlying implementations. Security researchers identified that the issue is triggered exclusively when applications explicitly set the cost parameter to 31 or when verifying password hashes that were generated with cost=31. The fix implemented in version 3.1.22 resolves this by ensuring proper handling of the round count calculation and preventing the signed integer overflow condition. Organizations should immediately upgrade to version 3.1.22 or implement the workaround of reducing the cost parameter below 31 to maintain adequate cryptographic security. The vulnerability demonstrates the critical importance of proper integer handling in cryptographic implementations, as even seemingly minor implementation details can completely compromise security assurances provided by well-established cryptographic primitives.