ruby-jwt is a Ruby implementation of the RFC 7519 OAuth JSON Web Token standard. Prior to 2.10.3 and 3.2.0, JWT.decode(token, '', true, algorithm: 'HS256') accepts an attacker-forged token because OpenSSL::HMAC.digest('SHA256', '', payload) returns a valid digest under an empty key and no empty-key precondition exists in the HMAC algorithm. The same path is reached when a keyfinder block or key_finder: argument returns an empty string, nil, or an array containing nil for an unknown key, affecting HS256, HS384, and HS512 verification through JWT.decode and JWT::EncodedToken#verify_signature!. This issue is fixed in versions 2.10.3 and 3.2.0.
Security readout for executives and security teams
Plain-English summary
Ruby applications using vulnerable ruby-jwt versions may accept forged HMAC-signed JWTs when verification uses an empty or missing key. If JWTs protect login sessions, API access, or authorization decisions, attackers could impersonate users or gain unauthorized access.
Executive priority
Treat as urgent for Ruby systems where JWTs control access. Prioritize internet-facing APIs, identity services, admin portals, and multi-tenant applications using the ruby-jwt gem with HMAC algorithms.
Technical view
Before ruby-jwt 2.10.3 and 3.2.0, HS256, HS384, and HS512 verification could succeed when the HMAC key was empty, nil, or returned that way by key lookup. Affected paths include JWT.decode and JWT::EncodedToken#verify_signature!.
Likely exposure
Exposure is likely in Ruby services using jwt versions below 2.10.3, or 3.x versions before 3.2.0, especially where HMAC JWT keys come from keyfinder logic or unknown key IDs.
Exploitation context
The source bundle reports no CISA KEV listing and provides no cited evidence of active exploitation. The issue is still high impact because it is network-reachable, unauthenticated, low complexity, and affects authentication integrity.
Researcher notes
Focus triage on HS256, HS384, and HS512 verification paths. The root issue is missing empty-key precondition enforcement around HMAC verification, not a named affected product beyond the ruby-jwt gem identified in the sources.
Mitigation direction
Upgrade ruby-jwt to 2.10.3 or 3.2.0.
Audit Gemfile.lock and dependency manifests for vulnerable jwt versions.
Ensure HMAC JWT secrets are never empty or nil.
Make key lookup failures reject tokens explicitly.
Check vendor guidance for any additional hardening advice.
Validation and detection
Confirm deployed services load ruby-jwt 2.10.3 or 3.2.0 or later.
Search code for JWT.decode and JWT::EncodedToken#verify_signature! usage.
Review keyfinder or key_finder logic for empty, nil, or nil-containing returns.
Verify unknown key IDs are rejected, not mapped to empty keys.
Review authentication logs for unusual JWT validation or key lookup failures.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-1391: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Authentication and credential weaknesses can make valid-account abuse and credential telemetry useful review starting points. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
6Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-1391 · source CWE mapping
Use of Weak Credentials
Use of Weak Credentials represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Improper Authentication represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Inadequate Encryption Strength represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.