CVE-2026-34824: Uncontrolled Thread Spawning Denial of Service in Mesop WebSockets

Mesop is a Python-based UI framework that relies on WebSockets for real-time bidirectional communication between the client interface and the server backend. The framework processes incoming user interface requests through a dedicated WebSocket handler mechanism. This component is responsible for parsing inbound messages and dispatching them to the appropriate backend logic.

CVE-2026-34824 is an uncontrolled resource consumption vulnerability (CWE-400) located within this WebSocket handler implementation. The vulnerability affects Mesop versions prior to 1.2.5 and exposes the server to severe availability degradation. Unauthenticated remote actors can trigger this flaw over the network with minimal complexity.

The core of the vulnerability is the absence of architectural constraints on concurrent execution. By repeatedly sending minimal, correctly formatted WebSocket messages, an attacker forces the application to request an unbounded number of operating system threads. This mechanism directly leads to resource exhaustion and complete application failure.

The root cause of CVE-2026-34824 resides within the handle_websocket function in the mesop/server/server.py module. In vulnerable versions, this function operates via an infinite while True: loop that blocks on ws.receive(). Upon receiving and successfully parsing a message, the handler immediately instantiates a new thread to process the request.

The application calls threading.Thread(...) and subsequently thread.start() for every single incoming message. There is no resource pooling, no queuing mechanism, and no validation of current system load before the thread creation request is passed to the underlying operating system. The thread is configured as a daemon thread, executing copy_current_request_context(ws_generate_data).

Operating systems impose strict limits on the maximum number of concurrent threads due to kernel data structure constraints and stack memory allocation. Each Python thread consumes a significant amount of system memory for its stack. When an attacker floods the server with messages, the rapid iteration of the loop requests thousands of threads in milliseconds, hitting OS thread limits and triggering Out of Memory (OOM) killer mechanisms.

The vulnerability is clearly visible in the source code of the handle_websocket loop. The implementation retrieves a message, parses the user interface request, and immediately spawns a thread. The code lacks any admission control or backpressure mechanisms.

The following snippet demonstrates the vulnerable implementation in Mesop versions 1.2.3 and 1.2.4:

# Vulnerable implementation in mesop/server/server.py
while True:
    message = ws.receive()
    if not message:
        continue
    
    # Unbounded thread creation occurs here
    thread = threading.Thread(
        target=copy_current_request_context(ws_generate_data),
        args=(ws, ui_request),
        daemon=True,
    )
    thread.start()

The patch introduced in commit 760a2079b5c609038c826d24dfbcf9b0be98d987 resolves this by implementing a bounded semaphore and a thread pool executor. The semaphore restricts the number of in-flight tasks to 500, while the executor caps the concurrent worker threads at 100. Messages exceeding the semaphore limit are dropped.

# Patched implementation in mesop/server/server.py
if not _ws_semaphore.acquire(blocking=False):
    logging.warning("WebSocket server at capacity, dropping message.")
    continue
 
_ws_executor.submit(copy_current_request_context(ws_generate_data), ws, ui_request)

Exploiting this vulnerability requires zero user interaction and no authentication. An attacker only requires network access to the target application's /__ui__ WebSocket endpoint. The attack relies entirely on volumetric message flooding rather than complex memory corruption or logic bypasses.

The provided proof-of-concept script utilizes the standard Python websocket library to establish a connection. Once connected, the attacker sends an empty, base64-encoded ui_request string (base64.urlsafe_b64encode(b'').decode('utf-8')). This minimal payload satisfies the initial parsing conditions within handle_websocket, ensuring the loop progresses directly to the vulnerable threading.Thread call.

# Exploitation Payload Loop
for i in range(50000):
    ws.send(EMPTY_UI_REQUEST_B64)

By executing a tight loop that dispatches tens of thousands of these minimal payloads within seconds, the attacker forces the server to attempt thousands of concurrent thread allocations. The target host's response degrades immediately. Within moments, the server application crashes entirely as the operating system intervenes to terminate the process due to OOM conditions or thread exhaustion.

The vulnerability carries a CVSS v3.1 base score of 7.5, reflecting a High severity rating. The impact is strictly isolated to the availability of the application and the underlying host system. There is no risk of remote code execution, arbitrary file read, or unauthorized data access stemming directly from this uncontrolled resource consumption flaw.

The availability impact is absolute. A single attacker utilizing negligible network bandwidth can render a robust Mesop deployment entirely inaccessible. Because the attack targets operating system resources, it can cause the host system to become temporarily unresponsive, potentially affecting other co-located services on the same machine before the OOM killer terminates the Mesop process.

While proof-of-concept exploit code is publicly available via OSV databases, there are currently no verified reports of active exploitation in the wild. Federal agencies and enterprise environments should prioritize patching, particularly if the Mesop application is exposed directly to the public internet.

The definitive remediation for CVE-2026-34824 is upgrading the Mesop framework to version 1.2.5 or later. Administrators managing automated deployments must update their requirements.txt or corresponding package manifests to enforce the >=1.2.5 version constraint. Restarting the application service post-upgrade is required to load the patched components.

For environments where immediate patching is unfeasible, administrators can mitigate the risk by deploying a Web Application Firewall (WAF) or a reverse proxy configured to aggressively rate-limit incoming WebSocket messages per client IP. Restricting maximum concurrent WebSocket connections at the load balancer level will also raise the difficulty of execution.

It is important to understand the residual risks present in the patched version. While the patch successfully prevents catastrophic operating system thread exhaustion, it introduces a hard limit on task concurrency via the bounded semaphore. An attacker can still exhaust these available 500 slots by sending slow-processing requests, leading to a service-level denial of service where legitimate user messages are dropped by the server.