How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows SSL/TLS clients using OCSP stapling to accept connections to servers with revoked certificates, potentially transmitting sensitive data to compromised servers. Such exposure of sensitive data could lead to non-compliance with data protection regulations like GDPR and HIPAA, which require secure handling and protection of personal and health information.

Because the vulnerability enables attackers to bypass certificate revocation checks, it undermines the integrity and confidentiality of communications, which are critical requirements under many security standards and regulations.

Mitigations such as disabling OCSP validation, using CRL-based revocation checking, or implementing custom trusted responder validation functions can help reduce risk and support compliance efforts.

Useful 0 Not Useful 0

Can you explain this vulnerability to me?

CVE-2026-32144 is an Improper Certificate Validation vulnerability in the Erlang OTP public_key module, specifically in the pubkey_ocsp component that handles OCSP (Online Certificate Status Protocol) responses.

The vulnerability occurs because the OCSP response validation function does not cryptographically verify that a designated OCSP responder certificate was actually signed by the issuing Certificate Authority (CA). Instead, it only checks that the responder certificate's issuer name matches the CA's subject name and that the certificate has the OCSPSigning extended key usage (EKU).

This flaw allows an attacker who can intercept or control OCSP responses to create a self-signed certificate with a matching issuer name and the OCSPSigning EKU, enabling them to forge OCSP responses that falsely indicate revoked certificates as valid.

The issue affects SSL/TLS clients using OCSP stapling, which may accept connections to servers with revoked certificates, potentially exposing sensitive data to compromised servers. Applications using the public_key:pkix_ocsp_validate/5 API directly are also affected, with impact depending on usage context.

Useful 0 Not Useful 0

How can this vulnerability impact me? :

This vulnerability can allow an attacker who can intercept or control OCSP responses to forge OCSP responses that mark revoked certificates as valid.

As a result, SSL/TLS clients using OCSP stapling may accept connections to servers presenting revoked certificates, potentially transmitting sensitive data to compromised or attacker-controlled servers.

For applications using the public_key:pkix_ocsp_validate/5 API directly, the impact varies depending on how the API is used; for example, server-side client certificate validation can be bypassed, leading to authentication bypass.

The vulnerability requires the attacker to be able to perform a man-in-the-middle (MITM) attack or otherwise control OCSP responses.

Workarounds include disabling OCSP validation, using CRL-based revocation checking, or supplying custom trusted responder validation functions.

Useful 0 Not Useful 0

What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, you should consider the following immediate steps:

• Disable OCSP validation by setting the stapling option to no_staple (default is {stapling, no_staple}).
• Use CRL-based revocation checking by enabling the {crl_check, true} SSL option.
• For applications using the public_key:pkix_ocsp_validate/5 API directly, supply a custom {is_trusted_responder_fun, Fun} function to validate trusted responder certificates.
• Restrict OCSP responder access to trusted network endpoints if you control the infrastructure.

Additionally, apply available patches from Erlang OTP commits ac7ff528be85 and 49033a6d93a5 to ensure proper cryptographic verification of OCSP responder certificates.

Useful 0 Not Useful 0

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves improper certificate validation in Erlang OTP's OCSP responder verification, specifically missing cryptographic signature verification of designated OCSP responder certificates.

To detect this vulnerability on your system, you should first identify if your Erlang/OTP environment is running a vulnerable version (OTP 27.0 up to 28.4.2, public_key 1.16 through 1.20.3, or ssl 11.2 through 11.5.4).

Detection can involve checking the version of Erlang/OTP and related libraries installed on your system using commands like:

• erl -eval 'erlang:system_info(otp_release).' -noshell -s init stop
• erl -eval 'application:get_key(public_key, vsn).' -noshell -s init stop
• erl -eval 'application:get_key(ssl, vsn).' -noshell -s init stop

To detect if your system is vulnerable in practice, you can monitor OCSP responses in your network traffic for suspicious or forged OCSP responder certificates that have issuer names matching your CA but are self-signed or not properly signed by the CA. This requires capturing and analyzing OCSP stapled responses or OCSP traffic.

While no specific detection commands are provided in the resources, you can use tools like OpenSSL to inspect OCSP responses manually, for example:

• openssl ocsp -respin <ocsp_response.der> -text -noverify

However, since the vulnerability is in the Erlang OTP implementation, detection of the flaw requires verifying whether the OCSP responder certificate is cryptographically signed by the CA, which the vulnerable versions fail to do.

Therefore, the primary detection method is to verify your Erlang/OTP version and apply patches or updates that include the fix.

Useful 0 Not Useful 0