Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1418 vulnerabilities reference this CWE, most recent first.

GHSA-R6X4-923Q-G947

Vulnerability from github – Published: 2026-09-29 23:14 – Updated: 2026-09-29 23:14
VLAI
Summary
PyJWT BOM Bypass
Details

Affected Package

  • Package: PyJWT (pyjwt on PyPI)
  • Repository: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&source=gmail&ust=1781794518474000&sa=E
  • Affected version: 2.13.0
  • Vulnerability class: Algorithm confusion / patch bypass

Root Cause

PyJWT 2.13.0 introduced a guard in HMACAlgorithm.prepare_key() (file jwt/algorithms.py, approximately line 344) to prevent RSA public key material from being used as an HMAC secret — the root cause of CVE-2026-48526.

The guard uses bytes.lstrip() before calling startswith(b"{"):

stripped = key_bytes.lstrip() # strips ASCII whitespace only
if stripped.startswith(b"{"): # JWK detection
 ...
 raise InvalidKeyError("The specified key is an asymmetric key...")

bytes.lstrip() with no argument removes only bytes in the ASCII whitespace set (\x20 \t \n \r \x0b \x0c). A UTF-8 BOM prefix (\xef\xbb\xbf) is not stripped, so stripped.startswith(b"{") returns False for any BOM-prefixed JWK JSON. The JWK detection block is never entered, and the RSA public key bytes are silently accepted as the HMAC-SHA256 secret.

PoC Sketch (pseudocode — not a weaponized payload)

# 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint)
# and prepends a UTF-8 BOM byte sequence before the JSON opening brace.
# 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret.
# 3. Attacker submits the forged token to a verifier that:
# - accepts algorithms=["HS256", "RS256"]
# - holds the same RSA public key as raw bytes (BOM-prefixed key file)
# 4. PyJWT 2.13.0 accepts the token because the BOM causes the JWK
# detection check to be skipped — the RSA JWK bytes become a valid HMAC key.
# Result: arbitrary claims (role, sub, etc.) accepted by the verifier.

Impact

An unauthenticated network attacker who knows the target application's RSA public key — which is public by design and obtainable from a JWKS endpoint or certificate — can forge JWT tokens containing arbitrary claims and have them accepted by a PyJWT 2.13.0 verifier configured with a mixed algorithm set (algorithms=["HS256", "RS256"] or equivalent). The resulting impact is complete authentication and authorization bypass (C:H/I:H). Attack Complexity is High (AC:H) because the attacker must obtain the RSA public key and the verifier must use a mixed-algorithm configuration; no authentication is required (PR:N). This is a patch bypass: users who upgraded to 2.13.0 specifically to remediate CVE-2026-48526 remain vulnerable.

Suggested Fix

Option A (minimal): Replace lstrip() with an explicit strip of known BOM prefixes before the JSON detection check:

# Strip common BOM prefixes in addition to ASCII whitespace
BOM_PREFIXES = (b"\xef\xbb\xbf", b"\xff\xfe", b"\xfe\xff")
stripped = key_bytes
for bom in BOM_PREFIXES:
 if stripped.startswith(bom):
 stripped = stripped[len(bom):]
 break
stripped = stripped.lstrip()

Option B (more robust): Use json.loads() as the detection mechanism instead of a byte-prefix check, so encoding variants and whitespace are handled by the JSON parser:

try:
 test_obj = json.loads(key_bytes.strip())
 if isinstance(test_obj, dict) and "kty" in test_obj:
 raise InvalidKeyError("The specified key is an asymmetric key...")
except (ValueError, UnicodeDecodeError):
 pass

Option B is preferred because it is resilient to any future encoding variant.

Maintainer update — 2026-09-09

We reproduced the reported algorithm-confusion path on PyJWT 2.13.0. When an application passes a raw public RSA JWK as the key and allows both an asymmetric and HMAC algorithm, a forged HS256 token signed with the known public JWK bytes is accepted when the JWK is represented in encodings accepted by Python's JSON decoder. The normal raw-JWK, asymmetric-only, and algorithm-bound PyJWK controls reject the token. This is an application configuration precondition, but the bypass is in PyJWT's own raw-JWK validation guard and is in scope under the PyJWT security policy.

The fix is committed as 180783930de91876bc0d601f826a1f2956057291. HMACAlgorithm.prepare_key() now checks parsed JSON objects for kty across accepted UTF-8/16/32 representations, preserves non-JWK HMAC key bytes, and conservatively rejects deeply nested JSON objects even when parsing reaches the recursion guard. Regression coverage includes BOM and BOM-less encodings, deep non-JWK keys, deep JWK objects, and unpaired-surrogate cases.

The full suite passes with 391 tests and 4 intentional cryptography-environment skips. A fresh Astra/max independent review accepted commit 180783930de91876bc0d601f826a1f2956057291. It independently confirmed encoding/BOM handling, recursion and surrogate behavior, preservation of non-object key compatibility, and the reported test results.

The fix has not been released. The advisory remains High with its existing CVSS 3.1 score of 7.4, and the patched version remains unset pending release planning.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "PyJWT"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.13.0"
            },
            {
              "fixed": "2.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.13.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102272"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:14:00Z",
    "nvd_published_at": "2026-09-28T21:17:15Z",
    "severity": "HIGH"
  },
  "details": "## Affected Package\n\n- **Package**: PyJWT (`pyjwt` on PyPI)\n- **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt\u0026source=gmail\u0026ust=1781794518474000\u0026sa=E\n- **Affected version**: 2.13.0\n- **Vulnerability class**: Algorithm confusion / patch bypass\n\n---\n\n## Root Cause\n\nPyJWT 2.13.0 introduced a guard in `HMACAlgorithm.prepare_key()` (file `jwt/algorithms.py`, approximately line 344) to prevent RSA public key material from being used as an HMAC secret \u2014 the root cause of CVE-2026-48526.\n\nThe guard uses `bytes.lstrip()` before calling `startswith(b\"{\")`:\n\n```python\nstripped = key_bytes.lstrip() # strips ASCII whitespace only\nif stripped.startswith(b\"{\"): # JWK detection\n ...\n raise InvalidKeyError(\"The specified key is an asymmetric key...\")\n```\n\n`bytes.lstrip()` with no argument removes only bytes in the ASCII whitespace set (`\\x20 \\t \\n \\r \\x0b \\x0c`). A UTF-8 BOM prefix (`\\xef\\xbb\\xbf`) is not stripped, so `stripped.startswith(b\"{\")` returns `False` for any BOM-prefixed JWK JSON. The JWK detection block is never entered, and the RSA public key bytes are silently accepted as the HMAC-SHA256 secret.\n\n---\n\n## PoC Sketch (pseudocode \u2014 not a weaponized payload)\n\n```python\n# 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint)\n# and prepends a UTF-8 BOM byte sequence before the JSON opening brace.\n# 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret.\n# 3. Attacker submits the forged token to a verifier that:\n# - accepts algorithms=[\"HS256\", \"RS256\"]\n# - holds the same RSA public key as raw bytes (BOM-prefixed key file)\n# 4. PyJWT 2.13.0 accepts the token because the BOM causes the JWK\n# detection check to be skipped \u2014 the RSA JWK bytes become a valid HMAC key.\n# Result: arbitrary claims (role, sub, etc.) accepted by the verifier.\n```\n\n---\n\n## Impact\n\nAn unauthenticated network attacker who knows the target application\u0027s RSA public key \u2014 which is public by design and obtainable from a JWKS endpoint or certificate \u2014 can forge JWT tokens containing arbitrary claims and have them accepted by a PyJWT 2.13.0 verifier configured with a mixed algorithm set (`algorithms=[\"HS256\", \"RS256\"]` or equivalent). The resulting impact\nis complete authentication and authorization bypass (`C:H/I:H`). Attack Complexity is High (`AC:H`) because the attacker must obtain the RSA public key and the verifier must use a mixed-algorithm configuration; no authentication is required (`PR:N`). This is a patch bypass: users who upgraded to 2.13.0 specifically to remediate CVE-2026-48526 remain vulnerable.\n\n---\n\n## Suggested Fix\n\n**Option A (minimal)**: Replace `lstrip()` with an explicit strip of known\nBOM prefixes before the JSON detection check:\n\n```python\n# Strip common BOM prefixes in addition to ASCII whitespace\nBOM_PREFIXES = (b\"\\xef\\xbb\\xbf\", b\"\\xff\\xfe\", b\"\\xfe\\xff\")\nstripped = key_bytes\nfor bom in BOM_PREFIXES:\n if stripped.startswith(bom):\n stripped = stripped[len(bom):]\n break\nstripped = stripped.lstrip()\n```\n\n**Option B (more robust)**: Use `json.loads()` as the detection mechanism\ninstead of a byte-prefix check, so encoding variants and whitespace are\nhandled by the JSON parser:\n\n```python\ntry:\n test_obj = json.loads(key_bytes.strip())\n if isinstance(test_obj, dict) and \"kty\" in test_obj:\n raise InvalidKeyError(\"The specified key is an asymmetric key...\")\nexcept (ValueError, UnicodeDecodeError):\n pass\n```\n\nOption B is preferred because it is resilient to any future encoding variant.\n\n---\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported algorithm-confusion path on PyJWT 2.13.0. When an application passes a raw public RSA JWK as the key and allows both an asymmetric and HMAC algorithm, a forged HS256 token signed with the known public JWK bytes is accepted when the JWK is represented in encodings accepted by Python\u0027s JSON decoder. The normal raw-JWK, asymmetric-only, and algorithm-bound `PyJWK` controls reject the token. This is an application configuration precondition, but the bypass is in PyJWT\u0027s own raw-JWK validation guard and is in scope under the PyJWT security policy.\n\nThe fix is committed as `180783930de91876bc0d601f826a1f2956057291`. `HMACAlgorithm.prepare_key()` now checks parsed JSON objects for `kty` across accepted UTF-8/16/32 representations, preserves non-JWK HMAC key bytes, and conservatively rejects deeply nested JSON objects even when parsing reaches the recursion guard. Regression coverage includes BOM and BOM-less encodings, deep non-JWK keys, deep JWK objects, and unpaired-surrogate cases.\n\nThe full suite passes with 391 tests and 4 intentional cryptography-environment skips. A fresh Astra/max independent review accepted commit `180783930de91876bc0d601f826a1f2956057291`. It independently confirmed encoding/BOM handling, recursion and surrogate behavior, preservation of non-object key compatibility, and the reported test results.\n\nThe fix has not been released. The advisory remains High with its existing CVSS 3.1 score of 7.4, and the patched version remains unset pending release planning.\n\n## Classification update \u2014 2026-09-10\n\nWe completed the advisory classification review. The proposed CVSS 3.1 vector is `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N` and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.\n\n## Maintainer update \u2014 2026-09-11\n\nThe verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.",
  "id": "GHSA-r6x4-923q-g947",
  "modified": "2026-09-29T23:14:00Z",
  "published": "2026-09-29T23:14:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-r6x4-923q-g947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102272"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/180783930de91876bc0d601f826a1f2956057291"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpadilla/pyjwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
    }
  ],
  "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": "PyJWT BOM Bypass"
}

GHSA-R727-5PF6-47R2

Vulnerability from github – Published: 2026-04-29 00:30 – Updated: 2026-05-06 21:56
VLAI
Summary
Elastic Package Registry has Improper Verification of Cryptographic Signature
Details

Improper Verification of Cryptographic Signature (CWE-347) in Elastic Package Registry could allow an attacker positioned to intercept network traffic, or to otherwise influence the contents served to a self-hosted registry, to substitute a tampered package without the integrity check failing closed.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/elastic/package-registry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.38.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33467"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T21:56:35Z",
    "nvd_published_at": "2026-04-28T22:16:48Z",
    "severity": "MODERATE"
  },
  "details": "Improper Verification of Cryptographic Signature (CWE-347) in Elastic Package Registry could allow an attacker positioned to intercept network traffic, or to otherwise influence the contents served to a self-hosted registry, to substitute a tampered package without the integrity check failing closed.",
  "id": "GHSA-r727-5pf6-47r2",
  "modified": "2026-05-06T21:56:35Z",
  "published": "2026-04-29T00:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33467"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elastic-package-registry-1-38-0-security-update-esa-2026-27/386081"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/elastic/package-registry"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Elastic Package Registry has Improper Verification of Cryptographic Signature "
}

GHSA-R7WH-X6RF-8G63

Vulnerability from github – Published: 2026-09-25 03:31 – Updated: 2026-09-25 03:31
VLAI
Details

MinIO through 7aac2a2 does not verify that every x-amz-* header present on a request also appears in the client-supplied X-Amz-SignedHeaders list. extractSignedHeaders() in cmd/signature-v4-utils.go iterates only the claimed list and never enumerates the headers that actually arrived, and thus a header that arrives unsigned is neither hashed into the canonical request nor rejected. Because cmd/api-router.go dispatches CopyObject on the presence of x-amz-copy-source alone, the holder of a presigned PUT URL scoped to a single object can add that header to the unmodified URL and cause a server-side copy, executed as the signer, of any object the signing key can read. A grant to write one object becomes a read of every bucket that key can reach. Amazon S3 rejects the equivalent request with HTTP 403 AccessDenied. The minio/minio GitHub repository was archived in April 2026; pgsty/silo before 1233254 is also affected.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-97731"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-25T03:16:59Z",
    "severity": "HIGH"
  },
  "details": "MinIO through 7aac2a2 does not verify that every x-amz-* header present on a request also appears in the client-supplied X-Amz-SignedHeaders list. extractSignedHeaders() in cmd/signature-v4-utils.go iterates only the claimed list and never enumerates the headers that actually arrived, and thus a header that arrives unsigned is neither hashed into the canonical request nor rejected. Because cmd/api-router.go dispatches CopyObject on the presence of x-amz-copy-source alone, the holder of a presigned PUT URL scoped to a single object can add that header to the unmodified URL and cause a server-side copy, executed as the signer, of any object the signing key can read. A grant to write one object becomes a read of every bucket that key can reach. Amazon S3 rejects the equivalent request with HTTP 403 AccessDenied. The minio/minio GitHub repository was archived in April 2026; pgsty/silo before 1233254 is also affected.",
  "id": "GHSA-r7wh-x6rf-8g63",
  "modified": "2026-09-25T03:31:01Z",
  "published": "2026-09-25T03:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97731"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgsty/silo/commit/1233254309b15571f101b2b26d531951ceaeef1e"
    },
    {
      "type": "WEB",
      "url": "https://silo.pgsty.com/about/security-advisories/#sn-2026-011"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R7XX-X336-XQQR

Vulnerability from github – Published: 2026-08-03 03:31 – Updated: 2026-09-10 21:31
VLAI
Details

In Bouncy Castle for Java before 1.85, OpenPGP inline-signature policy failures silently ignored. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 2.0.13.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
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/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-59643"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-03T01:16:44Z",
    "severity": "HIGH"
  },
  "details": "In Bouncy Castle for Java before 1.85, OpenPGP inline-signature policy failures silently ignored. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 2.0.13.",
  "id": "GHSA-r7xx-x336-xqqr",
  "modified": "2026-09-10T21:31:14Z",
  "published": "2026-08-03T03:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59643"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/commit/d3f8cc408b4a36d28e5a410c93436fe3d0fe726b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9059643"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE-2026-59643"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "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/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:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-R8GM-V65F-C973

Vulnerability from github – Published: 2022-10-31 22:42 – Updated: 2022-10-31 22:42
VLAI
Summary
acryl-datahub missing JWT signature check
Details

Missing JWT signature check (GHSL-2022-078)

The StatelessTokenService of the DataHub metadata service (GMS) does not verify the signature of JWT tokens. This allows an attacker to connect to DataHub instances as any user if Metadata Service authentication is enabled. This vulnerability occurs because the StatelessTokenService of the Metadata service uses the parse method of io.jsonwebtoken.JwtParser, which does not perform a verification of the cryptographic token signature. This means that JWTs are accepted regardless of the used algorithm.

Impact

This issue may lead to an authentication bypass.

Resources

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "acryl-datahub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39366"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-31T22:42:57Z",
    "nvd_published_at": "2022-10-28T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "# Missing JWT signature check (`GHSL-2022-078`)\n\nThe [`StatelessTokenService`](https://github.com/datahub-project/datahub/blob/aa146db611e3a4ca3aa17bb740783f789d4444d3/metadata-service/auth-impl/src/main/java/com/datahub/authentication/token/StatelessTokenService.java#L30) of the DataHub metadata service (GMS) does not verify the signature of JWT tokens. This allows an attacker to connect to DataHub instances as any user if Metadata Service authentication is enabled. This vulnerability occurs because the `StatelessTokenService` of the Metadata service uses the [`parse`](https://github.com/datahub-project/datahub/blob/aa146db611e3a4ca3aa17bb740783f789d4444d3/metadata-service/auth-impl/src/main/java/com/datahub/authentication/token/StatelessTokenService.java#L134) method of `io.jsonwebtoken.JwtParser`, which does not perform a verification of the cryptographic token signature. This means that JWTs are accepted regardless of the used algorithm.\n\n#### Impact\n\nThis issue may lead to an authentication bypass.\n\n#### Resources\n\n* [CodeQL: Missing JWT signature check](https://codeql.github.com/codeql-query-help/java/java-missing-jwt-signature-check/)",
  "id": "GHSA-r8gm-v65f-c973",
  "modified": "2022-10-31T22:42:57Z",
  "published": "2022-10-31T22:42:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/datahub-project/datahub/security/advisories/GHSA-r8gm-v65f-c973"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39366"
    },
    {
      "type": "WEB",
      "url": "https://codeql.github.com/codeql-query-help/java/java-missing-jwt-signature-check"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/datahub-project/datahub"
    },
    {
      "type": "WEB",
      "url": "https://github.com/datahub-project/datahub/blob/aa146db611e3a4ca3aa17bb740783f789d4444d3/metadata-service/auth-impl/src/main/java/com/datahub/authentication/token/StatelessTokenService.java#L134"
    },
    {
      "type": "WEB",
      "url": "https://github.com/datahub-project/datahub/blob/aa146db611e3a4ca3aa17bb740783f789d4444d3/metadata-service/auth-impl/src/main/java/com/datahub/authentication/token/StatelessTokenService.java#L30"
    },
    {
      "type": "WEB",
      "url": "https://github.com/datahub-project/datahub/releases/tag/v0.8.45"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "acryl-datahub missing JWT signature check"
}

GHSA-R98J-G9P3-FCGM

Vulnerability from github – Published: 2026-06-26 00:32 – Updated: 2026-06-27 21:30
VLAI
Details

PKCS#12 MAC verification uses an attacker-controlled comparison length, weakening the integrity check on the MAC and allowing a mismatched MAC to be accepted. The PKCS#12 verify path compared the locally computed HMAC against the MAC parsed from the PKCS#12 structure using a length taken directly from the attacker-supplied input, without first verifying that it equals the length of the digest actually produced by the configured algorithm. A truncated or zero-length stored MAC could therefore be accepted, defeating the integrity protection of the MAC.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6329"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T22:17:02Z",
    "severity": "MODERATE"
  },
  "details": "PKCS#12 MAC verification uses an attacker-controlled comparison length, weakening the integrity check on the MAC and allowing a mismatched MAC to be accepted. The PKCS#12 verify path compared the locally computed HMAC against the MAC parsed from the PKCS#12 structure using a length taken directly from the attacker-supplied input, without first verifying that it equals the length of the digest actually produced by the configured algorithm. A truncated or zero-length stored MAC could therefore be accepted, defeating the integrity protection of the MAC.",
  "id": "GHSA-r98j-g9p3-fcgm",
  "modified": "2026-06-27T21:30:28Z",
  "published": "2026-06-26T00:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6329"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfSSL/wolfssl/pull/10192"
    },
    {
      "type": "WEB",
      "url": "https://www.wolfssl.com/docs/security-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/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-R9GP-7F88-9R54

Vulnerability from github – Published: 2026-06-25 22:05 – Updated: 2026-06-25 22:05
VLAI
Summary
Lemur: JWT verifier honors attacker-supplied alg, enabling ATO
Details

Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure

Vulnerability Summary

Field Value
Title Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure
Component lemur/lemur/auth/service.py:130-137
CWE CWE-347 (Improper Verification of Cryptographic Signature)
Attack Prerequisite Defense-in-depth gap on its own — no single-request exploit against PyJWT 2.x. Single-request ATO requires a separate disclosure issue that leaks LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink.
Affected Versions github.com/Netflix/lemur version = "1.9.0". Same code present in every prior release that has the auth/service.py:130 block.

Executive Summary

The Lemur JWT verifier reads the alg header field from the unverified token and passes it straight into pyjwt.decode(..., algorithms=[header['alg']]). This is a classic JWT antipattern: the server is supposed to pin the algorithm, not the attacker. PyJWT 2.x's default config rejects alg=none, so this is not a single-request ATO today — I want to be precise about that. The bug is a hardening gap with two real consequences. First, if the deployment ever migrates to asymmetric signing (RS256/ES256), an attacker can pin alg=HS256 and forge tokens using the public key as the HMAC secret — the legacy "RS256→HS256 confusion" trick. Second, the audit-log surface that records alg to flag anomalous tokens is filled in from the attacker's header, so anomaly detection is blinded. I'm submitting this honestly at MEDIUM 4.8 (defense-in-depth) rather than inflating it; the chain to single-request ATO is documented but it depends on a separate disclosure bug.

Walkthrough: https://asciinema.org/a/2Blv9r4DoOleUk7a

Description

lemur/lemur/auth/service.py:130-137:

try:
    header_data = fetch_token_header(token)
    payload = decode_with_multiple_secrets(
        token, token_secrets, algorithms=[header_data["alg"]]
    )
except jwt.DecodeError:
    return dict(message="Token is invalid"), 403

fetch_token_header decodes the JWT's first segment (base64-decoded JSON, no signature check) and returns the header object. header_data["alg"] is whatever the bearer of the token put there. That value is then handed to decode_with_multiple_secrets, which calls pyjwt.decode(..., algorithms=[<attacker_value>]). The algorithms parameter is meant to be the server's pinned allowlist of acceptable signing algorithms — the line that says "I will accept HS256 and nothing else". By reading it from the token, Lemur asks the attacker which algorithm to trust.

Why this is MEDIUM and not CRITICAL today: PyJWT 2.x's decode() rejects alg=none regardless of the algorithms parameter (PyJWT enforces this in jwt.algorithms.NoneAlgorithm.verify). I confirmed this in the lab — a forged alg=none token comes back as HTTP 403 {"error":"When alg = \"none\", key value must be None.","message":"Failed to decode token"}. The classic single-request alg=none ATO is closed by the library, not by Lemur.

Why this still matters:

  1. Algorithm confusion is exactly what algorithms= is supposed to prevent. The widely-cited "RS256→HS256 confusion" attack works by pinning alg=HS256 and using the RS256 public key as the HMAC secret. The fix everyone teaches for that attack is "server pins the algorithm". Lemur doesn't, so the protection has a hole the moment the deployment moves to asymmetric signing.
  2. The PyJWT 2.x mitigation is a library default, not a Lemur design choice. A future PyJWT major that loosens the none check, or a downgrade to a vulnerable PyJWT for any reason, re-opens single-request ATO. Defense-in-depth means not relying on library defaults to backstop the framework's own validation.
  3. Audit blindness. Logging tooling that consumes alg to detect "this token claims an algorithm we don't issue" sees only what the attacker put in the header. A real HS256 token forged by an attacker who pins alg=ES256 (or any garbage that survives decode) bypasses naive alg-based anomaly heuristics.
  4. The chain to single-request ATO is short. Any separate disclosure issue that leaks LEMUR_TOKEN_SECRET (a debug page, an unguarded /metrics, an SSRF-to-config, an S3 backup leak, a git history accident) immediately turns into HS256 forgery — and the alg-from-header sink leaves the verifier downgradeable even after an operator migrates to RS256 later.

I'm framing this as a hardening defect at MEDIUM 4.8 because that's what the evidence supports. The chain step (config disclosure → forge admin) is demonstrated in the lab as a clear "what happens if this chain links" walk-through, not as a primary claim.

Proof of Concept & Steps to Reproduce

Walkthrough: https://asciinema.org/a/2Blv9r4DoOleUk7a. Offline cast: lemur_jwt_alg_hardening.cast. Harness: lemur_jwt_alg_hardening/support/ (lemur_jwt_mock.py mirrors lemur/auth/service.py:130-137 line-for-line).

Prerequisites: Docker, curl, jq, python3 with PyJWT.

Run

cd lemur_jwt_alg_hardening/
EXPLOIT_FAST=1 ./exploit_code.sh

Step 1 — Baseline legitimate login

curl -sS -X POST http://127.0.0.1:18001/api/1/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"operator@netflix.example"}'

Response (evidence/03_login_response.json):

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....",
 "user":{"active":true,"email":"operator@netflix.example","id":1,"role":"operator"}}

/api/1/users/me with that token returns 200 — baseline auth path works.

Step 2 — Confirm the antipattern in source

docker exec lemur-jwt-alg-hardening-harness cat /app/evidence-src/jwt_sink.txt

Output is the verbatim Lemur block:

# lemur/lemur/auth/service.py:130-137
try:
    header_data = fetch_token_header(token)
    payload = decode_with_multiple_secrets(
        token, token_secrets, algorithms=[header_data["alg"]]   # <-- antipattern
    )
except jwt.DecodeError:
    return dict(message="Token is invalid"), 403

The mock applies the same code path. No transformation, no allowlist, no server pin.

Step 3 — Forge alg=none (PyJWT 2.x rejects)

curl -sS -o /dev/null -w 'HTTP %{http_code}
' \
  http://127.0.0.1:18001/api/1/users/me \
  -H 'Authorization: Bearer eyJhbGciOiAibm9uZSIsICJ0eXAiOiAiSldUIn0.eyJzdWIiOiAyLCAiZW1haWwiOiAiYWRtaW5AbmV0ZmxpeC5leGFtcGxlIn0.'

Response (evidence/05_alg_none_attempt.json): HTTP 403. Body: {"error":"When alg = \"none\", key value must be None.","message":"Failed to decode token"}.

This is honest: PyJWT 2.x closes the single-request alg=none path. The antipattern is not directly exploitable at this PyJWT version.

Step 4 — Chain demo: config disclosure → HS256 forgery

The lab simulates an upstream disclosure issue by docker exec-ing into the container and reading /app/lemur.conf.py. In production this corresponds to any of: a /metrics page that echoes config, a debug error that prints current_app.config, an SSRF that reaches file:///app/lemur.conf.py, a misindexed git history, an S3 backup with the config file. The lab does not invent a separate vulnerability — it documents what happens when one of those exists.

docker exec lemur-jwt-alg-hardening-harness cat /app/lemur.conf.py
# LEMUR_TOKEN_SECRET = 'lab-deploy-token-secret-DO-NOT-USE-IN-PROD-aabbccdd11'

Forge an admin JWT with the leaked secret:

python3 -c "import jwt; print(jwt.encode({'sub':2,'email':'admin@netflix.example'}, '<leaked>', algorithm='HS256'))"
# eyJhbGciOiJIUzI1NiIs...

Send it:

curl -sS http://127.0.0.1:18001/api/1/users/me \
  -H "Authorization: Bearer $FORGED_ADMIN"

Response (evidence/06_forged_admin_response.json):

{"payload":{"email":"admin@netflix.example","sub":2},
 "user":{"active":true,"email":"admin@netflix.example","id":2,"role":"admin"}}

HTTP 200, role=admin. The forgery succeeds because (a) the attacker picked alg=HS256, (b) the server didn't pin its own algorithm, and (c) the secret was disclosed by the separate upstream issue. If the alg-from-header sink were fixed, even a leaked HS256 secret would not extend to whatever asymmetric algorithm the operator migrates to next — the attacker would have to also break the asymmetric key.

Step 5 — Verdict

VERDICT: ANTIPATTERN CONFIRMED — chain-dependent ATO
1. lemur/auth/service.py:130-137 passes attacker-controlled alg into decode()
2. PyJWT 2.x rejects alg=none, so the antipattern is NOT directly exploitable
3. Chained with upstream config disclosure → HS256 forgery wins
# Exploit Code & Lab Set-up [Lemur-jwt-alg-hardening.zip](https://github.com/user-attachments/files/28317909/Lemur-jwt-alg-hardening.zip)

Root Cause Analysis

The pattern in auth/service.py:130-137 is what every JWT-library author warns against. pyjwt.decode's algorithms parameter exists precisely to pin the server's accepted set; the documentation calls out that callers should never pass the value from the token header. The author of this block likely intended to support multiple deployment configurations (some on HS256, some on RS256) and dispatched on the token's claimed algorithm — but the right way to do that is algorithms=current_app.config["JWT_ACCEPTED_ALGS"] (a server-pinned list), not algorithms=[header_data["alg"]] (the attacker's preference).

The PyJWT 2.x mitigation is the only thing standing between this code and a single-request alg=none ATO. That mitigation lives in PyJWT's NoneAlgorithm.verify, which raises InvalidKeyError when alg=none is supplied with a non-None key. Lemur passes a real key, so the path raises and Lemur catches it as jwt.DecodeError and returns 403. Good — but the protection is in the dependency, not in Lemur's code. A PyJWT-1.x backport, an accidental downgrade, or a future PyJWT behaviour change re-opens the door.

The RS256→HS256 confusion variant is the more durable concern. If an operator migrates Lemur from HS256 to RS256 — a normal hardening step — the attacker pins alg=HS256 in the header and uses the RS256 public key as the HMAC secret. PyJWT 2.x's decode_complete does call _verify_signature with the supplied algorithm, and if the algorithm is HS256 and the "secret" is the bytes of the RS256 public key, the verifier passes. The fix is a server-pinned algorithm list; if the server only accepts ["RS256"], an attacker-supplied alg=HS256 token fails at the algorithms check before any key material is consulted.

The MEDIUM 4.8 score honestly reflects what's exploitable today: the antipattern is real, the impact today is limited to (a) audit-log blinding and (b) a downgrade primitive that activates under separate conditions. I'm explicitly not claiming RS256→HS256 against current Lemur because Lemur today is HS256 — the "RS256 → HS256" trick doesn't apply because Lemur's secret arg is HMAC bytes, not an RSA pubkey. The fix is still worth making.

Attack Scenario

sequenceDiagram
    participant Attacker
    participant Lemur as Lemur API
    participant Disclosure as Disclosure surface
    participant Audit as Audit logging

    Note over Attacker,Lemur: "Today: PyJWT 2.x mitigation holds for alg=none"
    Attacker->>Lemur: "Bearer alg=none token with [payload]"
    Lemur->>Lemur: "pyjwt.decode raises (alg=none + non-None key)"
    Lemur-->>Attacker: "403 Forbidden"

    Note over Disclosure,Lemur: "Chain step: separate disclosure leaks LEMUR_TOKEN_SECRET"
    Attacker->>Disclosure: "trigger debug / SSRF / backup leak"
    Disclosure-->>Attacker: "LEMUR_TOKEN_SECRET value"

    Note over Attacker,Lemur: "Forge HS256 admin token with leaked secret"
    Attacker->>Lemur: "Bearer alg=HS256 admin token signed with leaked secret"
    Lemur->>Lemur: "algorithms=[HS256] (taken from header) — accepted"
    Lemur-->>Attacker: "200 OK, role=admin"

    Note over Audit: "alg=HS256 in audit log - no anomaly flag because attacker picks alg"

Impact Assessment

Today, in a fully-patched Lemur 1.9.0 on PyJWT 2.x, the standalone impact is C:L (audit-log surface is attacker-influenced) / I:L (an attacker who controls alg can downgrade a future verifier upgrade) / A:N. The vector requires no user interaction — the attacker just sends a crafted token directly — but AC:H reflects the real-world conditions that have to align (PyJWT version, future migration to asymmetric signing, or a separate disclosure issue) before standalone impact materializes. That's the 4.8 MEDIUM score. The chain step to single-request ATO depends on a separate disclosure issue, which I'm not claiming as part of this report.

The reason this is worth fixing now rather than later is that it's a one-line change with no behavioural risk, and the consequence of leaving it in place is a permanent downgrade vector against any algorithm migration Netflix later decides to do. Lemur's role in the certificate-signing pipeline makes its session tokens unusually high-value — anyone who forges a Lemur admin JWT can issue, revoke, and exfiltrate certificates across the org. The Lemur PKI compromise report submitted separately (ACME acme_url SSRF + creator IDOR) shows what an admin Lemur identity can do in practice.

If Lemur ever moves to asymmetric signing without fixing this sink, the score moves to CRITICAL on the same day. Fix it now.

Remediation

One-line server pin:

# lemur/lemur/auth/service.py:130-137
allowed_algs = current_app.config.get("JWT_ALGORITHMS", ["HS256"])
try:
    payload = decode_with_multiple_secrets(
        token, token_secrets, algorithms=allowed_algs
    )
except jwt.DecodeError:
    return dict(message="Token is invalid"), 403

Three follow-ups worth doing at the same time:

  1. Log the algorithm the server actually applied, separately from the algorithm in the token header. This lets audit tooling see "the server enforced HS256 and the token claimed HS256" or, post-fix, "the server enforced RS256 and the token claimed HS256 — rejected", and flag mismatches.
  2. Pin algorithms to the smallest possible set. If Lemur only ever issues HS256, accept only HS256. Don't list every supported algorithm just because the library supports it.
  3. Migrate to asymmetric signing in a separate hardening PR once the algorithm pin is in. RS256 with key rotation removes the "leaked secret = forge admin" chain entirely.
Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55165"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T22:05:17Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "\u003c!-- obsidian --\u003e\u003ch1 data-heading=\"Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header \u2014 defense-in-depth gap; chain-dependent ATO with secret disclosure\"\u003eLemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header \u2014 defense-in-depth gap; chain-dependent ATO with secret disclosure\u003c/h1\u003e\n\u003ch2 data-heading=\"Vulnerability Summary\"\u003eVulnerability Summary\u003c/h2\u003e\n\nField | Value\n-- | --\nTitle | Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header \u2014 defense-in-depth gap; chain-dependent ATO with secret disclosure\nComponent | lemur/lemur/auth/service.py:130-137\nCWE | CWE-347 (Improper Verification of Cryptographic Signature)\nAttack Prerequisite | Defense-in-depth gap on its own \u2014 no single-request exploit against PyJWT 2.x. Single-request ATO requires a separate disclosure issue that leaks LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink.\nAffected Versions | github.com/Netflix/lemur __version__ = \"1.9.0\". Same code present in every prior release that has the auth/service.py:130 block.\n\n\n\u003ch2 data-heading=\"Executive Summary\"\u003eExecutive Summary\u003c/h2\u003e\n\u003cp\u003eThe Lemur JWT verifier reads the \u003ccode\u003ealg\u003c/code\u003e header field from the \u003cem\u003eunverified\u003c/em\u003e token and passes it straight into \u003ccode\u003epyjwt.decode(..., algorithms=[header[\u0027alg\u0027]])\u003c/code\u003e. This is a classic JWT antipattern: the server is supposed to pin the algorithm, not the attacker. PyJWT 2.x\u0027s default config rejects \u003ccode\u003ealg=none\u003c/code\u003e, so this is not a single-request ATO today \u2014 I want to be precise about that. The bug is a hardening gap with two real consequences. First, if the deployment ever migrates to asymmetric signing (RS256/ES256), an attacker can pin \u003ccode\u003ealg=HS256\u003c/code\u003e and forge tokens using the public key as the HMAC secret \u2014 the legacy \"RS256\u2192HS256 confusion\" trick. Second, the audit-log surface that records \u003ccode\u003ealg\u003c/code\u003e to flag anomalous tokens is filled in from the attacker\u0027s header, so anomaly detection is blinded. I\u0027m submitting this honestly at MEDIUM 4.8 (defense-in-depth) rather than inflating it; the chain to single-request ATO is documented but it depends on a separate disclosure bug.\u003c/p\u003e\n\u003cp\u003eWalkthrough: \u003ca href=\"https://asciinema.org/a/2Blv9r4DoOleUk7a\" class=\"external-link\" target=\"_blank\" rel=\"noopener nofollow\"\u003ehttps://asciinema.org/a/2Blv9r4DoOleUk7a\u003c/a\u003e\u003cbr\u003e\n\u003chr\u003e\n\u003ch2 data-heading=\"Description\"\u003eDescription\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003elemur/lemur/auth/service.py:130-137\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-python\"\u003etry:\n    header_data = fetch_token_header(token)\n    payload = decode_with_multiple_secrets(\n        token, token_secrets, algorithms=[header_data[\"alg\"]]\n    )\nexcept jwt.DecodeError:\n    return dict(message=\"Token is invalid\"), 403\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003efetch_token_header\u003c/code\u003e decodes the JWT\u0027s first segment (base64-decoded JSON, no signature check) and returns the header object. \u003ccode\u003eheader_data[\"alg\"]\u003c/code\u003e is whatever the bearer of the token put there. That value is then handed to \u003ccode\u003edecode_with_multiple_secrets\u003c/code\u003e, which calls \u003ccode\u003epyjwt.decode(..., algorithms=[\u0026#x3C;attacker_value\u003e])\u003c/code\u003e. The \u003ccode\u003ealgorithms\u003c/code\u003e parameter is meant to be the server\u0027s pinned allowlist of acceptable signing algorithms \u2014 the line that says \"I will accept HS256 and nothing else\". By reading it from the token, Lemur asks the attacker which algorithm to trust.\u003c/p\u003e\n\u003cp\u003eWhy this is MEDIUM and not CRITICAL today: PyJWT 2.x\u0027s \u003ccode\u003edecode()\u003c/code\u003e rejects \u003ccode\u003ealg=none\u003c/code\u003e regardless of the \u003ccode\u003ealgorithms\u003c/code\u003e parameter (PyJWT enforces this in \u003ccode\u003ejwt.algorithms.NoneAlgorithm.verify\u003c/code\u003e). I confirmed this in the lab \u2014 a forged \u003ccode\u003ealg=none\u003c/code\u003e token comes back as \u003ccode\u003eHTTP 403 {\"error\":\"When alg = \\\"none\\\", key value must be None.\",\"message\":\"Failed to decode token\"}\u003c/code\u003e. The classic single-request \u003ccode\u003ealg=none\u003c/code\u003e ATO is closed by the library, not by Lemur.\u003c/p\u003e\n\u003cp\u003eWhy this still matters:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eAlgorithm confusion is exactly what \u003ccode\u003ealgorithms=\u003c/code\u003e is supposed to prevent.\u003c/strong\u003e The widely-cited \"RS256\u2192HS256 confusion\" attack works by pinning \u003ccode\u003ealg=HS256\u003c/code\u003e and using the RS256 public key as the HMAC secret. The fix everyone teaches for that attack is \"server pins the algorithm\". Lemur doesn\u0027t, so the protection has a hole the moment the deployment moves to asymmetric signing.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe PyJWT 2.x mitigation is a library default, not a Lemur design choice.\u003c/strong\u003e A future PyJWT major that loosens the \u003ccode\u003enone\u003c/code\u003e check, or a downgrade to a vulnerable PyJWT for any reason, re-opens single-request ATO. Defense-in-depth means not relying on library defaults to backstop the framework\u0027s own validation.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAudit blindness.\u003c/strong\u003e Logging tooling that consumes \u003ccode\u003ealg\u003c/code\u003e to detect \"this token claims an algorithm we don\u0027t issue\" sees only what the attacker put in the header. A real \u003ccode\u003eHS256\u003c/code\u003e token forged by an attacker who pins \u003ccode\u003ealg=ES256\u003c/code\u003e (or any garbage that survives \u003ccode\u003edecode\u003c/code\u003e) bypasses naive alg-based anomaly heuristics.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe chain to single-request ATO is short.\u003c/strong\u003e Any separate disclosure issue that leaks \u003ccode\u003eLEMUR_TOKEN_SECRET\u003c/code\u003e (a debug page, an unguarded \u003ccode\u003e/metrics\u003c/code\u003e, an SSRF-to-config, an S3 backup leak, a git history accident) immediately turns into HS256 forgery \u2014 and the alg-from-header sink leaves the verifier downgradeable even after an operator migrates to RS256 later.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eI\u0027m framing this as a hardening defect at MEDIUM 4.8 because that\u0027s what the evidence supports. The chain step (config disclosure \u2192 forge admin) is demonstrated in the lab as a clear \"what happens if this chain links\" walk-through, not as a primary claim.\u003c/p\u003e\n\u003ch2 data-heading=\"Proof of Concept \u0026#x26; Steps to Reproduce\"\u003eProof of Concept \u0026#x26; Steps to Reproduce\u003c/h2\u003e\n\u003cp\u003eWalkthrough: \u003ca href=\"https://asciinema.org/a/2Blv9r4DoOleUk7a\" class=\"external-link\" target=\"_blank\" rel=\"noopener nofollow\"\u003ehttps://asciinema.org/a/2Blv9r4DoOleUk7a\u003c/a\u003e. Offline cast: \u003ccode\u003elemur_jwt_alg_hardening.cast\u003c/code\u003e. Harness: \u003ccode\u003elemur_jwt_alg_hardening/support/\u003c/code\u003e (\u003ccode\u003elemur_jwt_mock.py\u003c/code\u003e mirrors \u003ccode\u003elemur/auth/service.py:130-137\u003c/code\u003e line-for-line).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePrerequisites\u003c/strong\u003e: Docker, \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ejq\u003c/code\u003e, \u003ccode\u003epython3\u003c/code\u003e with PyJWT.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRun\u003c/strong\u003e\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-bash\"\u003ecd lemur_jwt_alg_hardening/\nEXPLOIT_FAST=1 ./exploit_code.sh\n\u003c/code\u003e\u003c/pre\u003e\n\u003ch3 data-heading=\"Step 1 \u2014 Baseline legitimate login\"\u003eStep 1 \u2014 Baseline legitimate login\u003c/h3\u003e\n\u003cpre\u003e\u003ccode class=\"language-bash\"\u003ecurl -sS -X POST http://127.0.0.1:18001/api/1/auth/login \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"email\":\"operator@netflix.example\"}\u0027\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eResponse (\u003ccode\u003eevidence/03_login_response.json\u003c/code\u003e):\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\"token\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....\",\n \"user\":{\"active\":true,\"email\":\"operator@netflix.example\",\"id\":1,\"role\":\"operator\"}}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/api/1/users/me\u003c/code\u003e with that token returns 200 \u2014 baseline auth path works.\u003c/p\u003e\n\u003ch3 data-heading=\"Step 2 \u2014 Confirm the antipattern in source\"\u003eStep 2 \u2014 Confirm the antipattern in source\u003c/h3\u003e\n\u003cpre\u003e\u003ccode class=\"language-bash\"\u003edocker exec lemur-jwt-alg-hardening-harness cat /app/evidence-src/jwt_sink.txt\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eOutput is the verbatim Lemur block:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-python\"\u003e# lemur/lemur/auth/service.py:130-137\ntry:\n    header_data = fetch_token_header(token)\n    payload = decode_with_multiple_secrets(\n        token, token_secrets, algorithms=[header_data[\"alg\"]]   # \u0026#x3C;-- antipattern\n    )\nexcept jwt.DecodeError:\n    return dict(message=\"Token is invalid\"), 403\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe mock applies the same code path. No transformation, no allowlist, no server pin.\u003c/p\u003e\n\u003ch3 data-heading=\"Step 3 \u2014 Forge \u0026#x60;alg=none\u0026#x60; (PyJWT 2.x rejects)\"\u003eStep 3 \u2014 Forge \u003ccode\u003ealg=none\u003c/code\u003e (PyJWT 2.x rejects)\u003c/h3\u003e\n\u003cpre\u003e\u003ccode class=\"language-bash\"\u003ecurl -sS -o /dev/null -w \u0027HTTP %{http_code}\n\u0027 \\\n  http://127.0.0.1:18001/api/1/users/me \\\n  -H \u0027Authorization: Bearer eyJhbGciOiAibm9uZSIsICJ0eXAiOiAiSldUIn0.eyJzdWIiOiAyLCAiZW1haWwiOiAiYWRtaW5AbmV0ZmxpeC5leGFtcGxlIn0.\u0027\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eResponse (\u003ccode\u003eevidence/05_alg_none_attempt.json\u003c/code\u003e): \u003ccode\u003eHTTP 403\u003c/code\u003e. Body: \u003ccode\u003e{\"error\":\"When alg = \\\"none\\\", key value must be None.\",\"message\":\"Failed to decode token\"}\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis is honest: PyJWT 2.x closes the single-request \u003ccode\u003ealg=none\u003c/code\u003e path. The antipattern is not directly exploitable at this PyJWT version.\u003c/p\u003e\n\u003ch3 data-heading=\"Step 4 \u2014 Chain demo: config disclosure \u2192 HS256 forgery\"\u003eStep 4 \u2014 Chain demo: config disclosure \u2192 HS256 forgery\u003c/h3\u003e\n\u003cp\u003eThe lab simulates an upstream disclosure issue by \u003ccode\u003edocker exec\u003c/code\u003e-ing into the container and reading \u003ccode\u003e/app/lemur.conf.py\u003c/code\u003e. In production this corresponds to any of: a \u003ccode\u003e/metrics\u003c/code\u003e page that echoes config, a debug error that prints \u003ccode\u003ecurrent_app.config\u003c/code\u003e, an SSRF that reaches \u003ccode\u003efile:///app/lemur.conf.py\u003c/code\u003e, a misindexed git history, an S3 backup with the config file. The lab does not invent a separate vulnerability \u2014 it documents what happens \u003cem\u003ewhen one of those exists\u003c/em\u003e.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-bash\"\u003edocker exec lemur-jwt-alg-hardening-harness cat /app/lemur.conf.py\n# LEMUR_TOKEN_SECRET = \u0027lab-deploy-token-secret-DO-NOT-USE-IN-PROD-aabbccdd11\u0027\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eForge an admin JWT with the leaked secret:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-bash\"\u003epython3 -c \"import jwt; print(jwt.encode({\u0027sub\u0027:2,\u0027email\u0027:\u0027admin@netflix.example\u0027}, \u0027\u0026#x3C;leaked\u003e\u0027, algorithm=\u0027HS256\u0027))\"\n# eyJhbGciOiJIUzI1NiIs...\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSend it:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-bash\"\u003ecurl -sS http://127.0.0.1:18001/api/1/users/me \\\n  -H \"Authorization: Bearer $FORGED_ADMIN\"\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eResponse (\u003ccode\u003eevidence/06_forged_admin_response.json\u003c/code\u003e):\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\"payload\":{\"email\":\"admin@netflix.example\",\"sub\":2},\n \"user\":{\"active\":true,\"email\":\"admin@netflix.example\",\"id\":2,\"role\":\"admin\"}}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eHTTP 200, \u003ccode\u003erole=admin\u003c/code\u003e. The forgery succeeds because (a) the attacker picked \u003ccode\u003ealg=HS256\u003c/code\u003e, (b) the server didn\u0027t pin its own algorithm, and (c) the secret was disclosed by the separate upstream issue. If the alg-from-header sink were fixed, even a leaked HS256 secret would not extend to whatever asymmetric algorithm the operator migrates to next \u2014 the attacker would have to also break the asymmetric key.\u003c/p\u003e\n\u003ch3 data-heading=\"Step 5 \u2014 Verdict\"\u003eStep 5 \u2014 Verdict\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003eVERDICT: ANTIPATTERN CONFIRMED \u2014 chain-dependent ATO\n1. lemur/auth/service.py:130-137 passes attacker-controlled alg into decode()\n2. PyJWT 2.x rejects alg=none, so the antipattern is NOT directly exploitable\n3. Chained with upstream config disclosure \u2192 HS256 forgery wins\n\u003c/code\u003e\u003c/pre\u003e\n\n# Exploit Code \u0026 Lab Set-up\n\n[Lemur-jwt-alg-hardening.zip](https://github.com/user-attachments/files/28317909/Lemur-jwt-alg-hardening.zip)\n\n\n\u003ch2 data-heading=\"Root Cause Analysis\"\u003eRoot Cause Analysis\u003c/h2\u003e\n\u003cp\u003eThe pattern in \u003ccode\u003eauth/service.py:130-137\u003c/code\u003e is what every JWT-library author warns against. \u003ccode\u003epyjwt.decode\u003c/code\u003e\u0027s \u003ccode\u003ealgorithms\u003c/code\u003e parameter exists precisely to pin the server\u0027s accepted set; the documentation calls out that callers should never pass the value from the token header. The author of this block likely intended to support multiple deployment configurations (some on HS256, some on RS256) and dispatched on the token\u0027s claimed algorithm \u2014 but the right way to do that is \u003ccode\u003ealgorithms=current_app.config[\"JWT_ACCEPTED_ALGS\"]\u003c/code\u003e (a server-pinned list), not \u003ccode\u003ealgorithms=[header_data[\"alg\"]]\u003c/code\u003e (the attacker\u0027s preference).\u003c/p\u003e\n\u003cp\u003eThe PyJWT 2.x mitigation is the only thing standing between this code and a single-request \u003ccode\u003ealg=none\u003c/code\u003e ATO. That mitigation lives in PyJWT\u0027s \u003ccode\u003eNoneAlgorithm.verify\u003c/code\u003e, which raises \u003ccode\u003eInvalidKeyError\u003c/code\u003e when \u003ccode\u003ealg=none\u003c/code\u003e is supplied with a non-None key. Lemur passes a real key, so the path raises and Lemur catches it as \u003ccode\u003ejwt.DecodeError\u003c/code\u003e and returns 403. Good \u2014 but the protection is in the dependency, not in Lemur\u0027s code. A PyJWT-1.x backport, an accidental downgrade, or a future PyJWT behaviour change re-opens the door.\u003c/p\u003e\n\u003cp\u003eThe RS256\u2192HS256 confusion variant is the more durable concern. If an operator migrates Lemur from HS256 to RS256 \u2014 a normal hardening step \u2014 the attacker pins \u003ccode\u003ealg=HS256\u003c/code\u003e in the header and uses the RS256 \u003cem\u003epublic key\u003c/em\u003e as the HMAC secret. PyJWT 2.x\u0027s \u003ccode\u003edecode_complete\u003c/code\u003e does call \u003ccode\u003e_verify_signature\u003c/code\u003e with the supplied algorithm, and if the algorithm is HS256 and the \"secret\" is the bytes of the RS256 public key, the verifier passes. The fix is a server-pinned algorithm list; if the server only accepts \u003ccode\u003e[\"RS256\"]\u003c/code\u003e, an attacker-supplied \u003ccode\u003ealg=HS256\u003c/code\u003e token fails at the \u003ccode\u003ealgorithms\u003c/code\u003e check before any key material is consulted.\u003c/p\u003e\n\u003cp\u003eThe MEDIUM 4.8 score honestly reflects what\u0027s exploitable today: the antipattern is real, the impact today is limited to (a) audit-log blinding and (b) a downgrade primitive that activates under separate conditions. I\u0027m explicitly not claiming RS256\u2192HS256 against current Lemur because Lemur today is HS256 \u2014 the \"RS256 \u2192 HS256\" trick doesn\u0027t apply because Lemur\u0027s secret arg is HMAC bytes, not an RSA pubkey. The fix is still worth making.\u003c/p\u003e\n\n\u003ch2 data-heading=\"Attack Scenario\"\u003eAttack Scenario\u003c/h2\u003e\n\n```mermaid\nsequenceDiagram\n    participant Attacker\n    participant Lemur as Lemur API\n    participant Disclosure as Disclosure surface\n    participant Audit as Audit logging\n\n    Note over Attacker,Lemur: \"Today: PyJWT 2.x mitigation holds for alg=none\"\n    Attacker-\u003e\u003eLemur: \"Bearer alg=none token with [payload]\"\n    Lemur-\u003e\u003eLemur: \"pyjwt.decode raises (alg=none + non-None key)\"\n    Lemur--\u003e\u003eAttacker: \"403 Forbidden\"\n\n    Note over Disclosure,Lemur: \"Chain step: separate disclosure leaks LEMUR_TOKEN_SECRET\"\n    Attacker-\u003e\u003eDisclosure: \"trigger debug / SSRF / backup leak\"\n    Disclosure--\u003e\u003eAttacker: \"LEMUR_TOKEN_SECRET value\"\n\n    Note over Attacker,Lemur: \"Forge HS256 admin token with leaked secret\"\n    Attacker-\u003e\u003eLemur: \"Bearer alg=HS256 admin token signed with leaked secret\"\n    Lemur-\u003e\u003eLemur: \"algorithms=[HS256] (taken from header) \u2014 accepted\"\n    Lemur--\u003e\u003eAttacker: \"200 OK, role=admin\"\n\n    Note over Audit: \"alg=HS256 in audit log - no anomaly flag because attacker picks alg\"\n```\n\n\u003ch2 data-heading=\"Impact Assessment\"\u003eImpact Assessment\u003c/h2\u003e\n\u003cp\u003eToday, in a fully-patched Lemur 1.9.0 on PyJWT 2.x, the standalone impact is C:L (audit-log surface is attacker-influenced) / I:L (an attacker who controls \u003ccode\u003ealg\u003c/code\u003e can downgrade a future verifier upgrade) / A:N. The vector requires no user interaction \u2014 the attacker just sends a crafted token directly \u2014 but AC:H reflects the real-world conditions that have to align (PyJWT version, future migration to asymmetric signing, or a separate disclosure issue) before standalone impact materializes. That\u0027s the 4.8 MEDIUM score. The chain step to single-request ATO depends on a separate disclosure issue, which I\u0027m not claiming as part of this report.\u003c/p\u003e\n\u003cp\u003eThe reason this is worth fixing now rather than later is that it\u0027s a one-line change with no behavioural risk, and the consequence of leaving it in place is a permanent downgrade vector against any algorithm migration Netflix later decides to do. Lemur\u0027s role in the certificate-signing pipeline makes its session tokens unusually high-value \u2014 anyone who forges a Lemur admin JWT can issue, revoke, and exfiltrate certificates across the org. The Lemur PKI compromise report submitted separately (ACME \u003ccode\u003eacme_url\u003c/code\u003e SSRF + creator IDOR) shows what an admin Lemur identity can do in practice.\u003c/p\u003e\n\u003cp\u003eIf Lemur ever moves to asymmetric signing without fixing this sink, the score moves to CRITICAL on the same day. Fix it now.\u003c/p\u003e\n\u003ch2 data-heading=\"Remediation\"\u003eRemediation\u003c/h2\u003e\n\u003cp\u003eOne-line server pin:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-python\"\u003e# lemur/lemur/auth/service.py:130-137\nallowed_algs = current_app.config.get(\"JWT_ALGORITHMS\", [\"HS256\"])\ntry:\n    payload = decode_with_multiple_secrets(\n        token, token_secrets, algorithms=allowed_algs\n    )\nexcept jwt.DecodeError:\n    return dict(message=\"Token is invalid\"), 403\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThree follow-ups worth doing at the same time:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eLog the algorithm the server actually applied, separately from the algorithm in the token header.\u003c/strong\u003e This lets audit tooling see \"the server enforced HS256 and the token claimed HS256\" or, post-fix, \"the server enforced RS256 and the token claimed HS256 \u2014 rejected\", and flag mismatches.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePin \u003ccode\u003ealgorithms\u003c/code\u003e to the smallest possible set.\u003c/strong\u003e If Lemur only ever issues HS256, accept only HS256. Don\u0027t list every supported algorithm just because the library supports it.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMigrate to asymmetric signing in a separate hardening PR\u003c/strong\u003e once the algorithm pin is in. RS256 with key rotation removes the \"leaked secret = forge admin\" chain entirely.\u003c/li\u003e\n\u003c/ol\u003e",
  "id": "GHSA-r9gp-7f88-9r54",
  "modified": "2026-06-25T22:05:17Z",
  "published": "2026-06-25T22:05:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-r9gp-7f88-9r54"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Netflix/lemur"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/releases/tag/v1.9.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": " Lemur: JWT verifier honors attacker-supplied alg, enabling ATO"
}

GHSA-R9HF-26XJ-X88V

Vulnerability from github – Published: 2026-09-04 00:31 – Updated: 2026-09-04 00:31
VLAI
Details

Improper verification of cryptographic signature in Copilot Studio allows an unauthorized attacker to elevate privileges over a network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-80098"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-03T23:17:20Z",
    "severity": "CRITICAL"
  },
  "details": "Improper verification of cryptographic signature in Copilot Studio allows an unauthorized attacker to elevate privileges over a network.",
  "id": "GHSA-r9hf-26xj-x88v",
  "modified": "2026-09-04T00:31:07Z",
  "published": "2026-09-04T00:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80098"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80098"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RF63-989X-X4X8

Vulnerability from github – Published: 2026-08-01 15:30 – Updated: 2026-08-01 15:30
VLAI
Details

better-auth versions greater than 1.3.34 and before 1.4.0 contain a vulnerability in the multi-session plugin's /sign-out after-hook, which trusts raw multi-session cookies and forwards extracted values to internalAdapter.deleteSessions without verifying the cookie signature (e.g., via getSignedCookie). An attacker can supply a forged _multi-* cookie to trigger deletion of arbitrary session tokens.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-71402"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-01T13:16:55Z",
    "severity": "LOW"
  },
  "details": "better-auth versions greater than 1.3.34 and before 1.4.0 contain a vulnerability in the multi-session plugin\u0027s /sign-out after-hook, which trusts raw multi-session cookies and forwards extracted values to internalAdapter.deleteSessions without verifying the cookie signature (e.g., via getSignedCookie). An attacker can supply a forged _multi-* cookie to trigger deletion of arbitrary session tokens.",
  "id": "GHSA-rf63-989x-x4x8",
  "modified": "2026-08-01T15:30:23Z",
  "published": "2026-08-01T15:30:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-wmjr-v86c-m9jj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71402"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/better-auth-before-session-revocation-via-forged-cookie"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:L/VI:L/VA:L/SC:L/SI:L/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-RFFH-WMQ4-5XWM

Vulnerability from github – Published: 2025-09-19 03:30 – Updated: 2025-09-19 03:30
VLAI
Details

There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X13SEM-F . An attacker can update the system firmware with a specially crafted image.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-6198"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-19T02:15:44Z",
    "severity": "MODERATE"
  },
  "details": "There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X13SEM-F . An attacker can update the system firmware with a specially crafted image.",
  "id": "GHSA-rffh-wmq4-5xwm",
  "modified": "2025-09-19T03:30:51Z",
  "published": "2025-09-19T03:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6198"
    },
    {
      "type": "WEB",
      "url": "https://www.supermicro.com/en/support/security_BMC_IPMI_Sept_2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.

← Back to the CWE list