CVE-2025-69420 Overview
A type confusion vulnerability has been identified in OpenSSL's TimeStamp Response verification code. The vulnerability occurs when an ASN1_TYPE union member is accessed without first validating its type, causing an invalid or NULL pointer dereference when processing a malformed TimeStamp Response file. An application calling TS_RESP_verify_response() with a malicious TimeStamp Response can be caused to dereference an invalid or NULL pointer, resulting in a Denial of Service condition.
The vulnerable functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2() access the signing certificate attribute value without validating its type. When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memory through the ASN1_TYPE union, causing a crash.
Critical Impact
Applications using OpenSSL's TimeStamp Response verification are vulnerable to Denial of Service attacks when processing malformed TimeStamp Response files. Attackers can crash vulnerable applications by providing crafted timestamp responses.
Affected Products
- OpenSSL 3.6
- OpenSSL 3.5
- OpenSSL 3.4
- OpenSSL 3.3
- OpenSSL 3.0
- OpenSSL 1.1.1
Discovery Timeline
- 2026-01-27 - CVE CVE-2025-69420 published to NVD
- 2026-01-27 - OpenSSL releases security patches
- 2026-01-29 - Last updated in NVD database
Technical Details for CVE-2025-69420
Vulnerability Analysis
This vulnerability is classified as Type Confusion (CWE-754: Improper Check for Unusual or Exceptional Conditions). The root issue lies in the TimeStamp Response verification code path where the signing certificate attribute is retrieved and processed without proper type validation.
When an application calls TS_RESP_verify_response() to verify a TimeStamp Response, the code internally invokes ossl_ess_get_signing_cert() or ossl_ess_get_signing_cert_v2() to extract the signing certificate from the response. These functions use PKCS7_get_signed_attribute() to retrieve the signing certificate attribute, but only check if the attribute is NULL—they fail to verify that the attribute's type field is V_ASN1_SEQUENCE before accessing the union's sequence member.
Exploiting this vulnerability requires an attacker to provide a malformed TimeStamp Response to an application that verifies timestamp responses. While the TimeStamp protocol (RFC 3161) is not widely deployed, applications that do implement timestamp verification are vulnerable to crash-based Denial of Service attacks.
The FIPS modules in versions 3.5, 3.4, 3.3, and 3.0 are not affected by this issue, as the TimeStamp Response implementation is outside the OpenSSL FIPS module boundary. OpenSSL 1.0.2 is also not affected.
Root Cause
The root cause is insufficient type validation in the ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2() functions within crypto/ts/ts_rsp_verify.c. These functions access the attr->value.sequence member of an ASN1_TYPE union without first checking that attr->type == V_ASN1_SEQUENCE. When the actual type differs from the expected sequence type, the code accesses memory through an incorrect union member, leading to invalid memory access or NULL pointer dereference.
Attack Vector
The attack vector is network-based, requiring no privileges or user interaction. An attacker must deliver a malformed TimeStamp Response to a vulnerable application that processes timestamp responses. This could occur in scenarios where:
- An application requests timestamps from an attacker-controlled or compromised timestamp authority
- A man-in-the-middle intercepts and modifies legitimate timestamp responses
- Malicious timestamp response files are processed from untrusted sources
The following patch demonstrates the fix applied to validate the attribute type before accessing the union member:
const unsigned char *p;
attr = PKCS7_get_signed_attribute(si, NID_id_smime_aa_signingCertificate);
- if (attr == NULL)
+ if (attr == NULL || attr->type != V_ASN1_SEQUENCE)
return NULL;
p = attr->value.sequence->data;
return d2i_ESS_SIGNING_CERT(NULL, &p, attr->value.sequence->length);
Source: GitHub OpenSSL Commit 27c7012
Detection Methods for CVE-2025-69420
Indicators of Compromise
- Unexpected application crashes or segmentation faults in processes using OpenSSL timestamp verification
- Core dumps showing crash locations in ossl_ess_get_signing_cert() or ossl_ess_get_signing_cert_v2() functions
- Log entries indicating timestamp verification failures preceding application termination
- Presence of malformed TimeStamp Response files with incorrect ASN.1 type encodings
Detection Strategies
- Monitor applications using OpenSSL for unexpected terminations, particularly those processing timestamp responses
- Implement application-level logging around TS_RESP_verify_response() calls to detect malformed input
- Deploy network monitoring to detect anomalous timestamp response traffic patterns
- Use crash analysis tools to identify signature patterns consistent with this vulnerability
Monitoring Recommendations
- Enable crash reporting and core dump collection for applications using OpenSSL timestamp verification
- Monitor system logs for repeated crashes in timestamp-related services
- Implement file integrity monitoring on timestamp response storage locations
- Track OpenSSL library versions across the environment to identify vulnerable deployments
How to Mitigate CVE-2025-69420
Immediate Actions Required
- Inventory all systems and applications using OpenSSL versions 1.1.1, 3.0, 3.3, 3.4, 3.5, or 3.6
- Prioritize patching applications that actively use TimeStamp Response verification functionality
- Apply the vendor-provided security patches immediately
- Review application logs for evidence of exploitation attempts
Patch Information
OpenSSL has released security patches addressing this vulnerability across all affected version branches. Multiple commits have been published to fix the type confusion issue:
- GitHub OpenSSL Commit 27c7012
- GitHub OpenSSL Commit 4e254b4
- GitHub OpenSSL Commit 564fd9c
- GitHub OpenSSL Commit 5eb0770
- GitHub OpenSSL Commit a99349e
For detailed patch information, refer to the OpenSSL Security Advisory 20260127.
Workarounds
- If timestamp verification is not required, disable or remove timestamp processing functionality from applications
- Implement input validation on timestamp responses before passing to OpenSSL verification functions
- Deploy application-level exception handling to gracefully handle crashes in timestamp verification code paths
- Consider upgrading to OpenSSL 1.0.2 if feasible, as this version is not affected by the vulnerability
# Check OpenSSL version to determine if patching is required
openssl version -a
# Verify timestamp verification is in use (check for TS_RESP_verify_response usage)
strings /path/to/application | grep -i "ts_resp\|timestamp"
# After patching, verify the new OpenSSL version
openssl version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


