Vulnerability record · CVE-2017-3737 · published 7 December 2017
CVE-2017-3737: OpenSSL error-state bypass in SSL_read/SSL_write after failed handshake
OOpenssl · Openssl
OpenSSL 1.0.2b through 1.0.2m fails to enforce its handshake error state when an application calls SSL_read() or SSL_write() directly after a fatal handshake error. Instead of failing, those calls succeed and pass data straight to or from the TLS record layer without encryption or decryption. This matters because it can silently break the confidentiality and integrity guarantees applications expect from TLS.
Description
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Automated analysis
medium priorityCVSS 3.0 base score is 5.9 (medium) and exploitation requires a specific application coding bug, though the high EPSS and broad OpenSSL deployment warrant prompt patching.
What it is
OpenSSL 1.0.2b through 1.0.2m fails to enforce its handshake error state when an application calls SSL_read() or SSL_write() directly after a fatal handshake error. Instead of failing, those calls succeed and pass data straight to or from the TLS record layer without encryption or decryption. This matters because it can silently break the confidentiality and integrity guarantees applications expect from TLS.
Impact
An attacker positioned to influence the connection could have plaintext read or written outside the TLS protection, exposing or injecting data. The CVSS vector rates confidentiality impact as high with no integrity or availability impact.
Attack surface
Reachable over the network (AV:N) but requires a race-prone condition (AC:H) and no authentication or user interaction (PR:N, UI:N). Exploitation additionally requires an application bug that calls SSL_read()/SSL_write() on the same SSL object after a fatal handshake error.
Exploitation
Not listed in CISA KEV and no ransomware associations are recorded. EPSS is high (0.78675, 99.567th percentile), but references carry only advisory and VDB tags, with no public exploit or in-the-wild reporting indicated.
What to do
- Upgrade OpenSSL to 1.0.2n or later; 1.1.0 is not affected.
- Apply vendor errata for bundled OpenSSL (Debian DSA-4065, Red Hat RHSA-2018:0998/2185/2186/2187, FreeBSD, Gentoo, NetApp, Oracle, Siemens).
- Audit application code so SSL_read()/SSL_write() are not called on an SSL object after a fatal handshake error.
- Track affected 1.0.2b-1.0.2m builds in SBOMs and prioritize internet-facing services for patching.
Detection
- Inventory OpenSSL versions across hosts and containers to find 1.0.2b-1.0.2m.
- Monitor TLS logs for handshake failures immediately followed by successful application data on the same connection.
- Watch for anomalous plaintext or malformed records on TLS ports that suggest record-layer bypass.
This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.
Affected products
2 vulnerable configurations from NVD's CPE data, grouped by vendor and product.
References
Track CVE-2017-3737 inside VULONE
Watch it alongside the ransomware crews, C2 infrastructure and forum chatter that reference it, query it through the API and pull it into your SIEM over TAXII.
Related vulnerabilities
Same products first, then exploited flaws of the same weakness class.
Source: NIST National Vulnerability Database (record CVE-2017-3737), CISA KEV, FIRST EPSS (scores of 2026-09-25). This page is refreshed as NVD updates the record.