Bug 2525317 (CVE-2026-77358)

Summary: CVE-2026-77358 cpp-httplib: cpp-httplib: Use-after-free in WebSocket client leads to denial of service
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in cpp-httplib. The TLS (Transport Layer Security)-enabled WebSocket client improperly frees a TLS session while the WebSocket connection is still active. This timing issue, which occurs during the normal shutdown of a secure WebSocket connection, leads to a use-after-free vulnerability where the client attempts to access memory that has already been released. A remote attacker could potentially exploit this to cause a denial of service (DoS) by crashing the application or leading to other unpredictable system behavior.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2526709, 2526710    
Bug Blocks:    

Description OSIDB Bzimport 2026-08-27 23:33:52 UTC 
cpp-httplib is a C++ header-only HTTP/HTTPS library. In versions 0.33.0 through 0.50.0, the TLS-enabled WebSocket client frees the TLS session before closing the WebSocket that still uses it, producing a use-after-free. In WebSocketClient::shutdown_and_close the SSL object is freed and the pointer cleared, but the subsequent WebSocket close still sends a close frame through the SSL socket stream, which holds a raw copy of the now-dangling session pointer and reads from and writes to the freed memory. The same freed-then-used ordering is reachable through the client's destructor and its connect path, so ordinary teardown of a secure WebSocket connection triggers the defect. This issue is fixed in version 0.50.1.