The vulnerability is an integer overflow in the Java BCrypt implementation within the bcrypt‑ruby gem for JRuby. When the cost parameter, which determines the number of key‑strengthening rounds, is set to its maximum value of 31, the signed 32‑bit calculation overflows and the resulting round count becomes negative. The strengthening loop therefore executes zero iterations, collapsing the intended 2^31 rounds into a single, constant‑time computation. As the resulting hash still appears valid and passes verification, the weakness is invisible to the application.

Affected systems are applications that employ the bcrypt‑ruby library prior to release 3.1.22 and configure the cost to 31 or later validate password hashes that begin with \"$2a$31$\". The vendor noted that the issue applies only to JRuby's implementation; native Ruby implementations are unaffected. Any deployment using older gem versions with cost=31 will generate weak hashes.

The CVSS score of 4.5 indicates moderate severity, and the EPSS score of under 1% suggests a low probability of exploitation at this time. The weakness is not listed in the CISA KEV catalog, and no active exploit is known. However, because the flaw allows attackers who can obtain the hash to compute it quickly, the risk escalates for systems that use high cost values and store password hashes locally. The likely vector is offline password cracking, inferred from the nature of the vulnerability; no network exposure is required beyond acquiring the hash.