CVE-2026-33306: bcrypt-ruby Privilege Escalation Flaw

CVE-2026-33306 Overview

CVE-2026-33306 is an integer overflow vulnerability in the Java BCrypt implementation for JRuby within the bcrypt-ruby gem. The vulnerability occurs when the cost parameter is set to 31, causing the key-strengthening round count to overflow from a positive value to a negative value. This results in zero iterations of the strengthening loop, effectively collapsing bcrypt's exponential key-strengthening from 2^31 rounds to near-constant-time computation.

Critical Impact

Password hashes generated with cost=31 appear valid ($2a$31$...) and verify correctly via checkpw, making the weakness invisible to the application while providing virtually no cryptographic protection.

Affected Products

• bcrypt-ruby versions prior to 3.1.22 (JRuby implementation)
• Applications using JRuby with bcrypt-ruby configured with cost=31
• Systems verifying password hashes with $2a$31$ prefix

Discovery Timeline

• 2026-03-18 - bcrypt-ruby team releases version 3.1.22 with security fix
• 2026-03-24 - CVE-2026-33306 published to NVD
• 2026-03-24 - Last updated in NVD database

Technical Details for CVE-2026-33306

Vulnerability Analysis

This vulnerability stems from the JRuby implementation of bcrypt-ruby (BCrypt.java) computing the key-strengthening round count as a signed 32-bit integer. The bcrypt algorithm uses a cost factor to determine how many rounds of key-strengthening to perform, calculated as 2^cost iterations. When the cost is set to 31 (the maximum allowed), the calculation 1 << 31 in a signed 32-bit integer context produces -2147483648 (negative due to overflow) instead of the intended 2147483648 positive value.

Since the strengthening loop condition checks i < rounds, a negative round count causes the loop to execute zero iterations. Only the initial EksBlowfish key setup and the final 64x encryption phase remain, drastically reducing the computational cost of password hashing and verification.

Root Cause

The root cause is CWE-190 (Integer Overflow or Wraparound). In Java, the int type is a signed 32-bit integer with a maximum value of 2^31 - 1 (2,147,483,647). When computing 1 << 31, the result exceeds this maximum and wraps around to -2147483648. The loop for (i = 0; i < rounds; i++) never executes because 0 < -2147483648 evaluates to false.

Attack Vector

The attack vector is local, requiring an attacker to either:

1. Compromise password hashes from a system using JRuby bcrypt-ruby with cost=31
2. Target verification of existing $2a$31$ hashes

Since the weakened hashes are computationally trivial to brute-force compared to properly strengthened bcrypt hashes, an attacker with access to the hash database could crack passwords in a fraction of the expected time. The vulnerability is particularly insidious because the generated hashes appear valid and verify correctly, leaving no indication to the application that the security guarantee has been compromised.

// Vulnerable code in BCrypt.java
// Source: https://github.com/bcrypt-ruby/bcrypt-ruby/commit/831ce64cb0a9502130fa93a28bfd9527a5fa45c4

 	*/
 	private byte[] crypt_raw(byte password[], byte salt[], int log_rounds,
 							boolean sign_ext_bug, int safety) {
-		int rounds, i, j;
+		long rounds;
+		int i, j;
 		int cdata[] =  bf_crypt_ciphertext.clone();
 		int clen = cdata.length;
 		byte ret[];

 		if (log_rounds < 4 || log_rounds > 31)
 			throw new IllegalArgumentException ("Bad number of rounds");
-		rounds = 1 << log_rounds;
+		rounds = roundsForLogRounds(log_rounds);
 		if (salt.length != BCRYPT_SALT_LEN)
 			throw new IllegalArgumentException ("Bad salt length");

 		init_key();
 		ekskey(salt, password, sign_ext_bug, safety);
-		for (i = 0; i < rounds; i++) {
+		for (long r = 0; r < rounds; r++) {
 			key(password, sign_ext_bug, safety);
 			key(salt, false, safety);
 		}

The fix changes rounds from int to long (64-bit) and uses a dedicated method roundsForLogRounds() to properly compute the round count, ensuring the value remains positive for all valid cost values.

Detection Methods for CVE-2026-33306

Indicators of Compromise

• Password hashes in the database with the $2a$31$ prefix indicate potential exposure
• JRuby applications running bcrypt-ruby versions prior to 3.1.22
• BCrypt configuration explicitly setting cost=31 in authentication modules
• Unusually fast password hashing/verification times when cost is configured as 31

Detection Strategies

• Audit application configuration files for BCrypt cost settings equal to 31
• Query password hash storage for entries beginning with $2a$31$ to identify affected credentials
• Review dependency manifests (Gemfile.lock) for bcrypt-ruby versions below 3.1.22
• Implement timing analysis to detect anomalously fast bcrypt operations

Monitoring Recommendations

• Monitor authentication system logs for bcrypt cost configuration changes
• Set up alerts for bcrypt-ruby gem version changes in deployment pipelines
• Implement hash format validation to flag $2a$31$ hashes during routine security scans
• Track password verification timing to detect potential integer overflow conditions

How to Mitigate CVE-2026-33306

Immediate Actions Required

• Upgrade bcrypt-ruby to version 3.1.22 or later immediately
• Audit existing password hashes for $2a$31$ prefix and force password resets for affected accounts
• Review BCrypt cost configuration and reduce cost to 30 or below as an interim measure
• Inventory all JRuby applications using bcrypt-ruby to assess exposure

Patch Information

The vulnerability has been fixed in bcrypt-ruby version 3.1.22, released on March 18, 2026. The fix modifies the BCrypt.java file to use a long type for the rounds variable instead of int, preventing the integer overflow condition.

Patch resources:

• GitHub Release v3.1.22
• GitHub Security Advisory GHSA-f27w-vcwj-c954
• GitHub Commit Details

Workarounds

• Set the BCrypt cost parameter to a value less than 31 (recommended: 12-14 for production systems)
• Implement application-level validation to reject cost values of 31
• Consider switching to MRI Ruby implementation if JRuby upgrade is not immediately feasible
• Force password resets for any accounts with $2a$31$ hashes

# Configuration example
# In your Ruby application, ensure cost is set below 31
# Example bcrypt configuration:
BCrypt::Engine.cost = 12  # Recommended default cost

# Audit for affected hashes in database:
# SELECT * FROM users WHERE password_hash LIKE '$2a$31$%';