CVE-2026-33306
Integer Overflow in bcrypt-ruby JRuby Causes Zero Iterations
Publication date: 2026-03-24
Last updated on: 2026-03-30
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| bcrypt-ruby_project | bcrypt-ruby | to 3.1.22 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-190 | The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33306 is an integer overflow vulnerability in the Java BCrypt implementation used by the JRuby bcrypt-ruby gem versions up to 3.1.21. When the cost parameter is set to 31, the maximum allowed, the calculation of the key-strengthening round count overflows a signed 32-bit integer, resulting in a negative value.
This causes the key-strengthening loop to execute zero iterations instead of the intended 2^31 rounds, effectively reducing the computational cost from exponential to near constant time. Despite this, the generated hash retains a valid format and passes verification, making the vulnerability difficult to detect during normal use.
The issue only occurs when the cost is exactly 31 or when verifying hashes with cost 31. It was fixed in version 3.1.22 of bcrypt-ruby. A workaround is to use a cost value less than 31.
How can this vulnerability impact me? :
This vulnerability can significantly weaken the security of password hashing when the cost parameter is set to 31. Instead of performing the intended exponential number of key-strengthening rounds, the hashing process executes zero strengthening iterations, making it much faster and easier for attackers to perform brute-force or dictionary attacks.
Because the resulting hash appears valid and verifies correctly, applications may not detect the weakened hashing, potentially exposing user passwords to compromise.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability occurs only when the bcrypt-ruby gem is used with the cost parameter set to 31, or when verifying hashes with cost 31 (formatted as $2a$31$...). The resulting hash looks valid and verifies correctly, making the weakness invisible during normal operation.'}, {'type': 'paragraph', 'content': 'To detect this vulnerability on your system, you should check if any bcrypt hashes use the cost factor 31. This can be done by searching for bcrypt hashes starting with "$2a$31$" in your stored password hashes or logs.'}, {'type': 'paragraph', 'content': 'Example command to find such hashes in a file containing password hashes:'}, {'type': 'list_item', 'content': "grep '^\\$2a\\$31\\$' /path/to/password_hashes_file"}, {'type': 'paragraph', 'content': 'If you find hashes with cost 31, your system may be affected if it uses the vulnerable bcrypt-ruby version (≤ 3.1.21) on JRuby.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The vulnerability has been fixed in bcrypt-ruby version 3.1.22. The immediate mitigation steps are:
- Upgrade the bcrypt-ruby gem to version 3.1.22 or later.
- If upgrading immediately is not possible, configure your application to use a cost parameter less than 31 when generating or verifying bcrypt hashes.
These steps prevent the integer overflow that causes the key-strengthening loop to execute zero iterations, restoring the intended security level of bcrypt.