CVE-2026-33306: 
Ruby vulnerability analysis and mitigation

CVE-2026-33306 is an integer overflow vulnerability in the Java BCrypt implementation (BCrypt.java) of the bcrypt-ruby gem when running on JRuby. When the bcrypt cost parameter is set to 31 (the maximum allowed value), a signed 32-bit integer overflow causes the key-strengthening loop to execute zero iterations instead of 2^31, effectively reducing bcrypt to near-constant-time computation. The vulnerability affects bcrypt-ruby versions ≤ 3.1.21 and was disclosed on March 18, 2026, with a fix released the same day. It carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 4.5 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is CWE-190 (Integer Overflow or Wraparound). In BCrypt.java, the round count for the key-strengthening phase was computed as 1 << log_rounds using a signed 32-bit int. When log_rounds=31, this left-shift produces a negative value due to signed integer overflow, causing the for loop condition (i < rounds) to be immediately false and executing zero iterations. The fix in commit 831ce64 changes the rounds variable type from int to long and introduces a roundsForLogRounds() helper to safely compute the value, and updates the loop variable accordingly (GitHub Commit). Exploitation requires that an application uses cost=31 when hashing passwords, or that an attacker can submit a $2a$31$... hash for verification — both of which trigger the weakened code path (GitHub Advisory).

The primary impact is a severe weakening of password hashing security for JRuby applications using bcrypt with cost=31. Instead of performing 2^31 key-strengthening iterations, the hash is computed with zero iterations, making it orders of magnitude faster to brute-force. Critically, the resulting hashes appear structurally valid ($2a$31$...) and pass checkpw verification, making the weakness completely invisible to the application and its monitoring. This exposes stored user credentials to significantly accelerated offline brute-force or dictionary attacks if a password database is compromised (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code is known, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.009% (1st percentile), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is limited to scenarios where cost=31 is actively configured, which is an uncommon setting, further reducing the practical attack surface.

1. Identify target: Determine that the target application uses JRuby with the bcrypt-ruby gem (versions ≤ 3.1.21) and has configured bcrypt with cost=31.
2. Obtain password hashes: Gain access to the application's stored password hashes through a database breach, SQL injection, or other data exfiltration technique. Hashes generated with cost=31 on JRuby will have the prefix $2a$31$.
3. Confirm vulnerability: Verify that the hashes were generated on JRuby by confirming the $2a$31$ prefix — these hashes lack the full 2^31 rounds of key strengthening and are computationally equivalent to a much weaker hash.
4. Brute-force offline: Use a standard password cracking tool (e.g., Hashcat, John the Ripper) against the obtained hashes. Because the key-strengthening loop executed zero iterations, cracking speed is dramatically higher than expected for a cost=31 bcrypt hash — approaching the speed of cracking a low-cost bcrypt hash.
5. Credential reuse: Use recovered plaintext passwords to authenticate to the application or attempt credential stuffing against other services (GitHub Advisory, GitHub Commit).

• File System / Configuration: Presence of bcrypt-ruby gem version ≤ 3.1.21 in Gemfile.lock or gem environment on a JRuby application server.
• Database: Password hashes stored with the prefix $2a$31$ — these should be treated as potentially weakened if generated by a JRuby application running an unpatched version.
• Logs: Unusually high volumes of failed authentication attempts or rapid sequential login attempts against accounts, which may indicate offline-cracked credentials being tested.
• Application: Any JRuby application explicitly setting cost: 31 in bcrypt configuration code.

Upgrade bcrypt-ruby to version 3.1.22 or later, which fixes the integer overflow by changing the rounds variable to a long type in BCrypt.java (GitHub Release, GitHub Commit). As an immediate workaround, set the bcrypt cost to any value less than 31 (values of 10–12 are typical for production use). After upgrading, audit your application for any stored $2a$31$ hashes generated on JRuby and consider forcing re-hashing of affected passwords at next user login. IBM has also released patches for affected products including IBM CloudPak for AIOps, IBM Aspera Enterprise WebApps, and IBM Aspera Shares (IBM Advisory).

The vulnerability was published by maintainer tenderlove (Aaron Patterson) via a GitHub Security Advisory on March 18, 2026, the same day the fix was released, indicating responsible coordinated disclosure (GitHub Advisory). Red Hat tracked the issue via Bugzilla and assessed it as medium severity (Red Hat Bugzilla). IBM subsequently issued security bulletins for multiple affected products, indicating broader downstream impact across enterprise software (IBM Advisory). No significant broader media coverage or notable social media discussion has been identified.