GHSA-C32J-VQHX-RX3X

Vulnerability from github – Published: 2026-05-18 17:24 – Updated: 2026-06-02 22:12
VLAI
Summary
ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351
Details

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:)

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-287",
      "CWE-326"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:24:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "`JWT.decode(token, \u0027\u0027, true, algorithm: \u0027HS256\u0027)` accepts an attacker-forged token.\n`OpenSSL::HMAC.digest(\u0027SHA256\u0027, \u0027\u0027, payload)` returns a valid digest under an empty key, and no `raise\n  InvalidKeyError if key.empty?` precondition exists in the HMAC algorithm.\n\n```\nJWT.decode(token, \"\", true, algorithm: \u0027HS256\u0027)\n  -\u003e JWA::Hmac.verify(verification_key: \"\", ...)\n  -\u003e OpenSSL::HMAC.digest(\u0027SHA256\u0027, \"\", signing_input) == signature\n```\n\nThe same path is reached when a keyfinder block or key_finder: argument returns \"\", nil, or an\narray containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty\narrays, and JWT::JWA::Hmac silently coerces nil to \"\" (signing_key ||= \u0027\u0027) before signing.\n\n```\nJWT.decode(token, nil, true, algorithms: [\u0027HS256\u0027]) { |_h| \"\" }\n  -\u003e find_key returns \"\"               # \"\" \u0026\u0026 !Array(\"\").empty? == true\n  -\u003e JWA::Hmac.verify(verification_key: \"\", ...)\n  -\u003e verifies\n```\nCommon application patterns that produce the unsafe value: `redis.get(\"kid:#{kid}\").to_s`, ORM string columns with `default: \u0027\u0027`, `ENV[\u0027SECRET\u0027] || \u0027\u0027, Hash.new(\u0027\u0027)` 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.\n\nThe existing `enforce_hmac_key_length` option would block this but defaults to false. On OpenSSL \u2265 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.\n\nAffects HS256/HS384/HS512 via both JWT.decode (positional key and block keyfinder) and\n`JWT::EncodedToken#verify_signature!(key_finder:)`",
  "id": "GHSA-c32j-vqhx-rx3x",
  "modified": "2026-06-02T22:12:50Z",
  "published": "2026-05-18T17:24:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/security/advisories/GHSA-c32j-vqhx-rx3x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/issues/724"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/commit/db560b769a07bd9724e77ff505011ac01872106f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jwt/ruby-jwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/releases/tag/v2.10.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/releases/tag/v3.2.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/jwt/CVE-2026-45363.yml"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45363"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…