CVE-2017-3737

What it actually does

The error state mechanism fails to persist across direct SSL_read()/SSL_write() calls after a fatal handshake error, allowing subsequent operations to return success and pass record-layer data without encryption or decryption.

Why it matters to the business

Organizations running affected OpenSSL versions risk exposure of sensitive data in transit, increasing the chance of breaches and compliance violations; high EPSS score indicates elevated exploitation likelihood despite the CVE's age.

How an attack unfolds

An attacker initiates a TLS handshake that triggers a fatal error, then relies on an application flaw that issues SSL_read() or SSL_write() on the same session afterward; the call succeeds and the attacker obtains or injects plaintext data from the record layer.

How to fix it

Upgrade all instances of OpenSSL 1.0.2b through 1.0.2m to version 1.0.2n or newer; rebuild and redeploy dependent applications and restart services; apply vendor patches for Debian and other distributions.

How to confirm the fix worked

Verify installed OpenSSL version is 1.0.2n or later; review application source for direct use of SSL_read()/SSL_write() after handshake functions; test error-state behavior with crafted fatal handshake sequences.

Typical attack path

1. Initiate TLS connection to trigger a fatal handshake error
2. Exploit application logic that continues calling SSL_read()/SSL_write() after the error
3. Observe or manipulate unencrypted record-layer data

How to detect it

Review TLS handshake logs for fatal errors followed immediately by successful read or write operations on the same session; inspect application logs for unexpected plaintext data after handshake failures.

What your security team should do

• Prioritize upgrade of all OpenSSL 1.0.2 installations to 1.0.2n within the next maintenance window
• Scan codebases for direct SSL_read()/SSL_write() usage after handshake calls
• Monitor EPSS trend and reassess risk if exploit maturity increases