Raw vector
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-33306 is a medium-severity Integer Overflow or Wraparound (CWE-190) vulnerability in Bcrypt-Ruby Project Bcrypt-Ruby. Its CVSS base score is 4.5 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 13th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-33306 is an integer overflow vulnerability (CWE-190) in the JRuby implementation of the bcrypt-ruby gem, a Ruby binding for the OpenBSD bcrypt password hashing algorithm. In versions prior to 3.1.22, the BCrypt.java code computes the key-strengthening round count as a signed 32-bit integer. When applications set the cost parameter to its maximum value of 31, this triggers a signed integer overflow, resulting in a negative round count and zero iterations in the strengthening loop. Consequently, bcrypt collapses from 2^31 rounds of exponential key strengthening to a constant-time computation, retaining only the initial EksBlowfish key setup and final 64x encryption phase. Affected hashes appear valid (e.g., starting with $2a$31$...) and pass verification via checkpw, rendering the flaw undetectable to applications.
Remote attackers can exploit this vulnerability with no privileges or user interaction required (CVSS 7.5: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Exploitation occurs when verifying or generating hashes with cost=31, allowing attackers to crack passwords significantly faster due to the reduced computational cost. Any application using bcrypt-ruby on JRuby with cost=31 is vulnerable, enabling efficient brute-force or dictionary attacks against stored password hashes.
The bcrypt-ruby security advisory (GHSA-f27w-vcwj-c954), release notes for v3.1.22, and fixing commit (831ce64cb0a9502130fa93a28bfd9527a5fa45c4) confirm the issue is resolved in version 3.1.22. As a workaround, applications should set the cost to a value less than 31.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-14670
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V5.2.6
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (static analysis, fuzzing, unit tests) directly finds integer overflow defects before deployment.
Secure engineering principles require use of safe arithmetic constructs or language features that structurally eliminate integer overflow during calculation.
Input validation enforces bounds on values before arithmetic, stopping the conditions that trigger overflow or wraparound.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require use of safe arithmetic, bounds checks, and testing that prevent integer overflows.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect integer overflows before release.
Secure SDLC mandates input validation and arithmetic checks that prevent integer overflows.
Application security requirements include bounds checking and safe arithmetic to avoid overflow conditions.
Secure architecture principles require defensive coding patterns that mitigate integer wraparound risks.
Secure coding standards explicitly forbid unsafe integer operations and mandate overflow-safe constructs.