What is the CVSS score of CVE-2026-45363?

CVE-2026-45363 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of ruby-jwt are affected by CVE-2026-45363?

The ruby-jwt library (versions prior to 3.2.0) contains an authentication bypass vulnerability allowing remote attackers to forge cryptographic tokens used for API authentication and session…. A patch is available.

How to fix or mitigate CVE-2026-45363?

Within 24 hours: Inventory all Ruby applications using ruby-jwt < 3.2.0 and flag those with empty/nil key patterns for emergency patching. Within 7 days: Upgrade ruby-jwt to version 3.2.0 or later across all affected applications and test in staging environments. Within 30 days: Verify all production deployments are patched to 3.2.0+, eliminate empty/nil key fallback patterns from code, and implement monitoring for token validation failures.

ruby-jwt CVE-2026-45363

CRITICAL

Improper Authentication (CWE-287)

2026-05-18 https://github.com/jwt/ruby-jwt

GHSA-c32j-vqhx-rx3x

Redis Authentication Bypass OpenSSL

9.1

CVSS 3.1 · Vendor: https://github.com/jwt/ruby-jwt

Severity by source

Vendor (https://github.com/jwt/ruby-jwt) PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Primary rating from Vendor (https://github.com/jwt/ruby-jwt) · only source for this CVE.

CVSS VectorVendor: https://github.com/jwt/ruby-jwt

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Re-analysis Queued

Jul 14, 2026 - 22:22 vuln.today

cvss_changed

Severity Changed

Jul 14, 2026 - 22:22 NVD

HIGH CRITICAL

CVSS changed

Jul 14, 2026 - 22:22 NVD

7.4 (HIGH) 9.1 (CRITICAL)

Source Code Evidence Fetched

May 18, 2026 - 18:00 vuln.today

Analysis Generated

May 18, 2026 - 18:00 vuln.today

DescriptionCVE.org

JWT.decode(token, '', true, algorithm: 'HS256') accepts an attacker-forged token. OpenSSL::HMAC.digest('SHA256', '', payload) returns a valid digest under an empty key, and no raise InvalidKeyError if key.empty? precondition exists in the HMAC algorithm.

JWT.decode(token, "", true, algorithm: 'HS256')
  -> JWA::Hmac.verify(verification_key: "", ...)
  -> OpenSSL::HMAC.digest('SHA256', "", signing_input) == signature

The same path is reached when a keyfinder block or key_finder: argument returns "", nil, or an array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty arrays, and JWT::JWA::Hmac silently coerces nil to "" (signing_key ||= '') before signing.

JWT.decode(token, nil, true, algorithms: ['HS256']) { |_h| "" }
  -> find_key returns ""
# "" && !Array("").empty? == true
  -> JWA::Hmac.verify(verification_key: "", ...)
  -> verifies

Common application patterns that produce the unsafe value: redis.get("kid:#{kid}").to_s, ORM string columns with default: '', ENV['SECRET'] || '', Hash.new('') lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.

The existing enforce_hmac_key_length option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.

Affects HS256/HS384/HS512 via both JWT.decode (positional key and block keyfinder) and JWT::EncodedToken#verify_signature!(key_finder:)

AnalysisAI

Authentication bypass in the ruby-jwt gem (versions < 3.2.0) allows remote attackers to forge valid HS256/HS384/HS512 tokens when an application supplies an empty string or nil as the verification key. Because OpenSSL::HMAC.digest happily computes a digest under an empty key and JWT::JWA::Hmac coerces nil to '' without validating, any application whose key lookup degrades to '' (common with Redis misses, ORM string defaults, or ENV['SECRET'] || '' patterns) will accept attacker-signed tokens. No public exploit identified at time of analysis, but the vendor advisory (GHSA-c32j-vqhx-rx3x) and the v3.2.0 patch confirm the issue and the trivial forgery primitive.

Technical ContextAI

ruby-jwt is the canonical Ruby implementation of RFC 7519 JSON Web Tokens, widely used by Rails and Sinatra applications for session and API authentication. The root cause maps to CWE-287 (Improper Authentication): JWT::JWA::Hmac#verify accepted an empty verification key, and signing_key ||= '' silently substituted '' for nil before delegating to OpenSSL::HMAC.digest. On OpenSSL 3.0 the underlying call previously raised an EVP_PKEY_new_mac_key malloc failure, which the library caught and converted to a decode error - an accidental defense - but on OpenSSL ≥ 3.5 that call no longer raises, removing the implicit guard. JWT::Decode#find_key further compounded the issue by rejecting only literal nil and empty arrays, so a keyfinder block returning '' was treated as a valid key. The CPE pkg:rubygems/jwt identifies the affected package, and the fix introduces an ensure_valid_key! helper that rejects non-String and empty keys before any HMAC computation.

RemediationAI

Upgrade the jwt gem to the vendor-released patch version 3.2.0 or later (gem 'jwt', '>= 3.2.0' in the Gemfile, then bundle update jwt); the fix is commit db560b769a07bd9724e77ff505011ac01872106f, which adds an ensure_valid_key! check that rejects non-String and empty keys before any HMAC computation. Until the upgrade can be deployed, enable the existing enforce_hmac_key_length option (off by default) which rejects short keys including '', though this changes behavior for any code that legitimately relied on short keys for testing. Audit all JWT.decode and EncodedToken#verify_signature! call sites to ensure the key source cannot degrade to '' or nil - fix patterns such as redis.get(...).to_s, ENV['SECRET'] || '', ORM string columns with default: '', Hash.new('') lookups, and [primary, fallback]-with-nil arrays by raising on missing keys instead of substituting an empty string. See the GHSA advisory at https://github.com/jwt/ruby-jwt/security/advisories/GHSA-c32j-vqhx-rx3x for full details.