Due to a mistake in libcurl's WebSocket code, a malicious server can send a particularly crafted packet which makes libcurl get trapped in an endless busy-loop.

There is no other way for the application to escape or exit this loop other than killing the thread/process.

This might be used to DoS libcurl-using application.

1. A cookie is set using the secure keyword for

When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.

A Set-Cookie: header using tab (horizontal tab, ASCII code 9) instead of space (ascii code 32) immediately before the Secure attribute causes curl to store the cookie without its Secure flag. The cookie might then wrongfully be sent over plaintext HTTP on subsequent requests to the same host.

Calling curleasypause() within the event-based CURLMOPTSOCKETFUNCTION callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.