|
| 1 | +--- |
| 2 | +gem: bcrypt |
| 3 | +cve: 2026-33306 |
| 4 | +ghsa: f27w-vcwj-c954 |
| 5 | +url: https://github.com/advisories/GHSA-f27w-vcwj-c954 |
| 6 | +title: bcrypt-ruby has an Integer Overflow that Causes Zero |
| 7 | + Key-Strengthening Iterations at Cost=31 on JRuby |
| 8 | +date: 2026-03-19 |
| 9 | +description: | |
| 10 | + ### Impact |
| 11 | +
|
| 12 | + An integer overflow in the Java BCrypt implementation for JRuby can |
| 13 | + cause zero iterations in the strengthening loop. Impacted |
| 14 | + applications must be setting the cost to 31 to see this happen. |
| 15 | +
|
| 16 | + The JRuby implementation of bcrypt-ruby (`BCrypt.java`) computes |
| 17 | + the key-strengthening round count as a signed 32-bit integer. |
| 18 | + When `cost=31` (the maximum allowed by the gem), signed integer |
| 19 | + overflow causes the round count to become negative, and the |
| 20 | + strengthening loop executes **zero iterations**. This collapses |
| 21 | + bcrypt from 2^31 rounds of exponential key-strengthening to |
| 22 | + effectively constant-time computation — only the initial |
| 23 | + EksBlowfish key setup and final 64x encryption phase remain. |
| 24 | +
|
| 25 | + The resulting hash looks valid (`$2a$31$...`) and verifies |
| 26 | + correctly via `checkpw`, making the weakness invisible to the |
| 27 | + application. This issue is triggered only when cost=31 is |
| 28 | + used or when verifying a `$2a$31$` hash. |
| 29 | +
|
| 30 | + ### Patches |
| 31 | +
|
| 32 | + This problem has been fixed in version 3.1.22 |
| 33 | +
|
| 34 | + ### Workarounds |
| 35 | +
|
| 36 | + Set the cost to something less than 31. |
| 37 | +patched_versions: |
| 38 | + - ">= 3.1.22" |
| 39 | +related: |
| 40 | + url: |
| 41 | + - https://github.com/bcrypt-ruby/bcrypt-ruby/security/advisories/GHSA-f27w-vcwj-c954 |
| 42 | + - https://github.com/bcrypt-ruby/bcrypt-ruby/commit/5faa2748331d3edc661c127ef2fbb3afcb6b02a4 |
| 43 | + - https://github.com/advisories/GHSA-f27w-vcwj-c954 |
0 commit comments