CVE-2026-33753
Python vulnerability analysis and mitigation

Overview

CVE-2026-33753 is an Authorization Bypass vulnerability in Trail of Bits' rfc3161-client, a Python library implementing the Time-Stamp Protocol (RFC 3161). The flaw allows any unauthenticated attacker to impersonate a trusted TimeStamping Authority (TSA) by exploiting a logic error in leaf certificate selection from an unordered PKCS#7 certificate bag. All versions up to and including 1.0.5 are affected; the issue is fixed in version 1.0.6, released April 8, 2026. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) per NVD, and 6.2 (Medium) per the GitHub Security Advisory (GitHub Advisory, Red Hat Bugzilla).

Technical details

The root cause (CWE-295: Improper Certificate Validation) lies in rfc3161_client.verify.Verifier._verify_leaf_certs(), which uses a naive algorithm to identify the leaf certificate: it iterates the PKCS#7 SignedData certificate bag and selects the first certificate that does not appear to issue any other certificate in the bag. This approach does not use the cryptographically-bound ESSCertID/ESSCertIDv2 fields specified in RFC 3161 to securely identify the signer certificate. An attacker who can intercept or deliver a modified TimeStampResponse can (1) obtain a legitimate timestamp from any trusted public TSA (e.g., FreeTSA), (2) generate a self-signed spoofed certificate with the target common_name and id-kp-timeStamping EKU, (3) generate a dummy certificate whose issuer matches the real TSA leaf (disqualifying it from selection), and (4) inject both certificates into the PKCS#7 bag. The library then evaluates common_name and EKU authorization checks against the spoofed certificate while OpenSSL validates the actual cryptographic signature against the authentic TSA certificate, resulting in a complete bypass of TSA identity pinning. The fix in v1.0.6 replaces the heuristic with a lookup using SignerInfo.issuerAndSerialNumber, which is covered by the PKCS#7 signature and cannot be tampered with (GitHub Advisory, Fix Commit).

Impact

Successful exploitation allows an unauthenticated attacker to forge valid timestamp signatures that are accepted as originating from a pinned, trusted TSA. Applications relying on rfc3161-client for TSA identity verification — such as code signing pipelines, document signing workflows, or audit logging systems — are completely exposed to TSA impersonation. There is no confidentiality or availability impact; the impact is entirely on integrity, as fraudulent timestamps can be used to falsify the time of signing events, undermine non-repudiation guarantees, or facilitate supply chain attacks by making malicious artifacts appear to have been signed at a trusted time (GitHub Advisory).

Exploitability

A functional proof-of-concept (poc.py) is publicly available in the GitHub Security Advisory, demonstrating the full attack flow against the live FreeTSA service with high confidence. The exploit requires no authentication, no special privileges, and no user interaction — only the ability to deliver a crafted TimeStampResponse to a vulnerable application. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.003% (0.000030), indicating low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

Exploitation steps

  1. Obtain a legitimate timestamp: Send a TimeStampRequest to a publicly trusted TSA (e.g., https://freetsa.org/tsr) for the target message (e.g., b'hello world'), receiving a valid, cryptographically signed TimeStampResponse.
  2. Generate a spoofed certificate: Create a self-signed X.509 certificate with the exact common_name and ExtendedKeyUsage (id-kp-timeStamping) that the target application's VerifierBuilder is configured to pin (e.g., CN=Spoofed TSA).
  3. Generate a dummy certificate: Create a second certificate whose issuer field matches the subject of the real TSA leaf certificate found in the authentic response. This causes the real leaf to appear to "issue" the dummy certificate, disqualifying it from the naive leaf-selection algorithm.
  4. Inject certificates into the PKCS#7 bag: Parse the authentic TimeStampResponse using an ASN.1 library (e.g., asn1crypto), append both the dummy certificate and the spoofed certificate to the SignedData.certificates list, and re-serialize the modified response.
  5. Trigger vulnerable verification: Pass the malicious response bytes to decode_timestamp_response() and invoke VerifierBuilder(common_name='Spoofed TSA', roots=[trusted_root], ...).build().verify_message(tsa_resp_obj, message). The library selects the spoofed certificate as the leaf (passing common_name and EKU checks), while OpenSSL validates the real cryptographic signature against the authentic TSA certificate — resulting in successful verification under the forged identity (GitHub Advisory).

Indicators of compromise

  • Network: Unexpected outbound requests from application servers to public TSA endpoints (e.g., https://freetsa.org/tsr) not matching normal signing workflows; requests fetching TSA root/intermediate certificates (e.g., https://freetsa.org/files/cacert.pem, https://freetsa.org/files/tsa.crt) from unusual processes.
  • File System: Presence of poc.py or similar scripts referencing rfc3161_client, asn1crypto, and TSA endpoints; unexpected .tsr files with anomalous certificate bag sizes (more than the expected 2–3 certificates in the PKCS#7 chain).
  • Logs: Application logs showing successful TSA verification for a common_name that does not match any known, contracted TSA; verification success events immediately following network requests to public free TSA services in production environments.
  • Process: Python processes invoking rfc3161_client.verify.VerifierBuilder with common_name values inconsistent with the organization's configured TSA providers (GitHub Advisory).

Mitigation and workarounds

Upgrade rfc3161-client to version 1.0.6 or later, released April 8, 2026. The fix replaces the naive leaf certificate heuristic with a cryptographically sound lookup using SignerInfo.issuerAndSerialNumber, which is covered by the PKCS#7 signature and cannot be manipulated by an attacker. No configuration-based workaround is available for versions prior to 1.0.6; the only remediation is upgrading the package (pip install 'rfc3161-client>=1.0.6'). Organizations using this library in code signing, document signing, or audit pipelines should treat this as a high-priority upgrade (GitHub Release, Fix Commit).

Community reactions

The vulnerability was reported by researcher Jaynornj and published by Trail of Bits maintainer DarkaMaul via GitHub Security Advisory on April 8, 2026. Red Hat tracked the issue via Bugzilla (Bug 2456545) and classified it as medium severity. The OpenSUSE security team issued a security announcement referencing the fix. No significant broader media coverage or notable social media discussion has been identified beyond standard vulnerability aggregator indexing (GitHub Advisory, Red Hat Bugzilla).

Additional resources


SourceThis report was generated using AI

Related Python vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-48039CRITICAL9.1
  • Python logoPython
  • meta-ads-mcp
NoYesAug 07, 2026
CVE-2026-48169HIGH8.8
  • Python logoPython
  • praisonai-platform
NoYesAug 07, 2026
GHSA-wvpp-8hx9-p66jHIGH8.8
  • Python logoPython
  • gitpython
NoYesAug 07, 2026
CVE-2026-71870MEDIUM4.8
  • Python logoPython
  • pypdf2
NoYesAug 07, 2026
CVE-2026-71852MEDIUM4.8
  • Python logoPython
  • pypdf
NoYesAug 07, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management