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.
CVE-2026-33306 is an integer overflow vulnerability in bcrypt-ruby's JRuby implementation that causes zero iterations in the password strengthening loop when cost is set to 31, effectively reducing bcrypt from 2^31 rounds to constant-time computation. This makes password hashes significantly weaker while appearing valid, allowing attackers to crack passwords more easily.
يحتوي تطبيق JRuby لـ bcrypt-ruby على خلل تجاوز عدد صحيح موقّع يحول عدد التكرارات إلى قيمة سالبة عند استخدام cost=31، مما يؤدي إلى تخطي حلقة التقوية بالكامل. تبدو بصمات كلمات المرور الناتجة صحيحة وتتحقق بشكل صحيح، لكنها توفر حماية ضعيفة جداً ضد هجمات كسر كلمات المرور.
A critical integer overflow flaw in bcrypt-ruby for JRuby causes the password strengthening algorithm to skip all iterations when using maximum cost value 31, reducing cryptographic strength from exponential rounds to basic encryption. Affected applications using JRuby with bcrypt cost=31 produce weak hashes that appear valid but are vulnerable to rapid password cracking.
Upgrade bcrypt-ruby to version 3.1.22 or later immediately. Review all password hashes generated with cost=31 on JRuby implementations and force password resets for affected users. Audit authentication logs for suspicious access patterns. Implement cost values below 31 if using JRuby, or migrate to the native C implementation.
قم بترقية bcrypt-ruby إلى الإصدار 3.1.22 أو أحدث فوراً. راجع جميع بصمات كلمات المرور المُنشأة بـ cost=31 على تطبيقات JRuby وأجبر إعادة تعيين كلمات المرور للمستخدمين المتأثرين. تدقيق سجلات المصادقة للأنماط المريبة. استخدم قيم cost أقل من 31 إذا كنت تستخدم JRuby أو انتقل إلى التطبيق الأصلي C.