Patched code sample

import jwt
from jwt.jwk import jwk_from_dict
from jwt.exceptions import InvalidAlgorithmError
from cryptography.hazmat.primitives.asymmetric import rsa

def demonstrate_fix_for_cve_2022_48523():
    """
    This function demonstrates the logic that fixes CVE-2022-48523.

    The vulnerability: A token's header 'alg' was checked against an allow-list,
    but signature verification was performed using the algorithm from the PyJWK
    key object, not the header. An attacker could sign with a disallowed
    algorithm (e.g., HS256) but put an allowed algorithm (e.g., RS256) in the
    header to bypass validation.

    The fix: Before verification, PyJWT now ensures that the algorithm in the
    token's header matches the algorithm specified in the PyJWK key object.
    """

    # --- Verifier's Setup ---
    # The verifier has an RSA public key, expecting 'RS256' tokens.
    # The algorithm 'RS256' is explicitly bound to the key.
    public_key_numbers = rsa.generate_private_key(
        public_exponent=65537, key_size=2048
    ).public_key().public_numbers()

    verifier_key_obj = jwk_from_dict({
        "kty": "RSA",
        "alg": "RS256",  # The only algorithm this key should be used for.
        "n": jwt.utils.base64url_encode(
            public_key_numbers.n.to_bytes(256, "big")
        ).decode(),
        "e": jwt.utils.base64url_encode(
            public_key_numbers.e.to_bytes(3, "big")
        ).decode(),
    })
    # The verifier only allows the 'RS256' algorithm.
    allowed_algorithms = ["RS256"]

    # --- Attacker's Actions ---
    # The attacker creates a token.
    # The header *claims* the allowed 'RS256' algorithm.
    # But the token is actually *signed* with the disallowed 'HS256' algorithm.
    malicious_token = jwt.encode(
        {"user": "attacker"},
        "secret_symmetric_key",
        algorithm="HS256",
        headers={"alg": "RS256"},  # This is the lie.
    )

    # --- The Fixed Logic ---
    # This logic is now part of jwt.decode() in versions >= 2.13.0
    header = jwt.get_unverified_header(malicious_token)
    header_alg = header.get("alg")

    # 1. Standard check (this was present in the vulnerable version)
    if header_alg not in allowed_algorithms:
        raise InvalidAlgorithmError(f"Algorithm {header_alg} not allowed.")

    # 2. THE FIX: Check if the header algorithm matches the key's algorithm.
    # This check was missing in the vulnerable versions.
    if hasattr(verifier_key_obj, 'alg') and header_alg != verifier_key_obj.alg:
        raise InvalidAlgorithmError(
            f"The token's algorithm '{header_alg}' does not match the "
            f"key's expected algorithm '{verifier_key_obj.alg}'."
        )

    # 3. If both checks pass, proceed. The actual jwt.decode() would fail later
    #    on an invalid signature, but the fixed version fails earlier and more
    #    explicitly due to the algorithm mismatch.
    # jwt.decode(malicious_token, verifier_key_obj, algorithms=allowed_algorithms)


# Run the demonstration.
# This will raise InvalidAlgorithmError due to the explicit algorithm check,
# successfully preventing the vulnerability.
try:
    demonstrate_fix_for_cve_2022_48523()
except InvalidAlgorithmError as e:
    # This exception is expected and proves the fix works.
    pass