CVE-2021-3712

What it actually does

This is a read buffer overrun in OpenSSL ASN.1 string handling. OpenSSL normally represents ASN.1 strings with an explicit length, but multiple OpenSSL printing and certificate-processing functions incorrectly assumed certain ASN1_STRING buffers were NUL-terminated like C strings. If an application directly constructs an ASN1_STRING without a trailing NUL byte, including through ASN1_STRING_set0() or by manually setting data and length fields, affected OpenSSL functions may read beyond the intended buffer. Impact can include application crash and, in some execution paths, disclosure of adjacent process memory such as sensitive plaintext or cryptographic material. The issue affects OpenSSL 1.1.1 through 1.1.1k and 1.0.2 through 1.0.2y; the supplied downstream package context also identifies identitypython/pysaml2 source builds fixed at commit f28c470b90e564dc6ff6cc03f42e9cbd461ed444.

Why it matters to the business

Systems that process certificates, SAML metadata, identity assertions, OCSP data, or other ASN.1-backed security material through vulnerable OpenSSL-linked components may be exposed to denial of service and potential leakage of sensitive in-memory data. Because OpenSSL is widely embedded in application stacks and security products, the operational risk is often indirect: an affected dependency may be present even when OpenSSL is not directly managed by application teams. The EPSS score is elevated, indicating meaningful likelihood of attempted exploitation in the wild despite no CISA KEV listing and no known ransomware association in the provided data. Priority should be highest for internet-facing identity, authentication, federation, certificate-validation, TLS inspection, and API services that parse attacker-controlled certificates or ASN.1-derived inputs.

How an attack unfolds

An attacker must reach an application path that causes the target process to construct an ASN1_STRING without NUL termination and then pass that structure into an affected OpenSSL function. In practice, this may involve submitting maliciously crafted certificate-like, OCSP, SAML, or other ASN.1-related data to a service that parses or transforms the input into OpenSSL ASN.1 structures using unsafe construction patterns. When the application later prints the ASN.1 data, evaluates certificate name constraints, extracts email addresses, handles certificate request email fields, or retrieves OCSP URLs, OpenSSL may continue reading past the intended string boundary. The most likely visible outcome is a crash of the consuming service. Under favorable memory layout conditions, the over-read may expose adjacent process memory to logs, responses, diagnostics, or other application output, potentially revealing secrets. Exploitation is higher complexity because the vulnerable condition depends on both affected OpenSSL versions and application-specific direct ASN1_STRING construction behavior; simply presenting a normally parsed malformed certificate is usually not sufficient if OpenSSL’s own d2i parsing paths NUL-terminate the string.

How to fix it

Upgrade OpenSSL to a fixed release: OpenSSL 1.1.1l or later for the 1.1.1 branch, and OpenSSL 1.0.2za or later for the 1.0.2 branch where that legacy branch is still supported through a vendor. For identitypython/pysaml2 source deployments, update to a version containing commit f28c470b90e564dc6ff6cc03f42e9cbd461ed444 or a later maintained release that includes the fix. Rebuild and redeploy statically linked applications, containers, language runtimes, appliances, and vendored dependencies that bundle OpenSSL; updating the operating-system OpenSSL package alone is not sufficient for statically linked or bundled copies. Where immediate patching is not possible, reduce exposure by restricting untrusted certificate/SAML/OCSP ingestion paths, disabling optional parsing or diagnostic printing of untrusted ASN.1 data where feasible, and isolating vulnerable services to reduce blast radius. Developers should avoid direct ASN1_STRING field manipulation, prefer safe OpenSSL constructors/parsers, and ensure any manually constructed ASN1_STRING buffer is explicitly NUL-terminated when passed to APIs that may print or treat the content as a C string.

How to confirm the fix worked

Confirm the runtime OpenSSL version used by each application, not only the system package version. Use commands such as `openssl version -a`, package manager inventory, container image scanning, SBOM review, and binary inspection for embedded OpenSSL copies. For source or dependency validation, confirm identitypython/pysaml2 includes commit f28c470b90e564dc6ff6cc03f42e9cbd461ed444 or a later release containing it. Restart services after patching and verify the running process maps the expected fixed OpenSSL library using platform tools such as `ldd`, `otool -L`, `proc maps`, package metadata, or container image attestations. For application code, search for direct use of ASN1_STRING_set0(), manual ASN1_STRING data/length assignment, and calls to affected extraction or printing functions. Regression testing should include certificate, OCSP, SAML, and ASN.1 processing paths with boundary-case strings and should verify no crashes, sanitizer findings, or memory disclosure occur.

Typical attack path

1. Identify an exposed service or application workflow that accepts certificates, certificate requests, OCSP-related data, SAML metadata, or other ASN.1-derived input.
2. Determine or infer that the service uses a vulnerable OpenSSL version or a vulnerable downstream component linked against OpenSSL.
3. Craft input that causes the application to directly create an ASN1_STRING without NUL termination, such as through unsafe use of ASN1_STRING_set0() or manual ASN1_STRING field population.
4. Trigger a later operation that calls an affected OpenSSL function, such as ASN.1 printing, certificate name constraints processing, X509_get1_email(), X509_REQ_get1_email(), or X509_get1_ocsp().
5. Cause OpenSSL to read beyond the ASN1_STRING buffer boundary.
6. Observe application crash, service instability, abnormal error responses, or unintended disclosure of adjacent process memory depending on the code path and memory layout.

How to detect it

Reliable exploitation detection is difficult because this flaw is a memory over-read and may not leave a unique network or file indicator. Focus on evidence of crashes, abnormal restarts, and memory disclosure from services that parse certificates, SAML, OCSP, or other ASN.1 inputs. Review system logs, application logs, container logs, reverse-proxy logs, crash dumps, core files, EDR telemetry, and APM traces around authentication, federation, certificate-validation, and TLS-processing workflows. Look for segmentation faults or aborts with stack traces referencing OpenSSL ASN.1 or X.509 functions such as ASN1_STRING_print_ex, ASN1_STRING_to_UTF8, X509_get1_email, X509_REQ_get1_email, X509_get1_ocsp, NAME_CONSTRAINTS_check, or X509_check_issued. Correlate crashes with inbound requests carrying certificate, SAML metadata, certificate request, OCSP, or identity-provider payloads. Inspect logs and diagnostic files for unexpected fragments of private keys, bearer tokens, session identifiers, passwords, plaintext identity data, or other adjacent process memory emitted shortly before or after OpenSSL-related errors. If core dumps exist, preserve them securely and analyze stack traces and memory contents; they may contain secrets. Network detection should emphasize anomalous repeated submissions to certificate/SAML/OCSP endpoints followed by 5xx responses or service restarts rather than a fixed signature.

• ASN1_STRING_print_ex
• ASN1_STRING_to_UTF8
• ASN1_STRING_set0
• X509_get1_email
• X509_REQ_get1_email
• X509_get1_ocsp
• NAME_CONSTRAINTS_check
• X509_check_issued
• OpenSSL 1.1.1k
• OpenSSL 1.1.1j
• OpenSSL 1.1.1i
• OpenSSL 1.1.1h
• OpenSSL 1.0.2y
• OpenSSL 1.0.2x
• segfault at
• Segmentation fault
• core dumped
• libcrypto.so.1.1
• libcrypto.so.1.0.0
• -----BEGIN PRIVATE KEY-----
• -----BEGIN RSA PRIVATE KEY-----
• -----BEGIN EC PRIVATE KEY-----

What your security team should do

• Prioritize inventory of internet-facing and externally reachable services that process certificates, SAML metadata/assertions, OCSP data, certificate requests, or other ASN.1-derived inputs.
• Patch or rebuild all affected OpenSSL deployments to 1.1.1l or later, or 1.0.2za or vendor-supported later builds for legacy 1.0.2 deployments.
• Update identitypython/pysaml2 source deployments to a revision containing f28c470b90e564dc6ff6cc03f42e9cbd461ed444 or a later maintained release.
• Search for statically linked or bundled OpenSSL copies in containers, appliances, language runtimes, and third-party products; do not rely solely on host package inventories.
• Ask application owners to review custom ASN.1, certificate, SAML, and OCSP handling code for unsafe ASN1_STRING construction patterns.
• Enable crash monitoring and alerting for authentication, federation, certificate-validation, and TLS-processing services until remediation is complete.
• Review recent logs, core dumps, and diagnostic outputs for crashes or memory disclosure around affected OpenSSL functions.
• If sensitive data may have been exposed through logs, error responses, or diagnostic dumps, treat affected artifacts as sensitive and assess whether credential or key rotation is required.