CVE-2026-77357: Mesop Python Framework DoS Vulnerability

CVE-2026-77357 Overview

CVE-2026-77357 is a denial-of-service vulnerability in Mesop, a Python-based UI framework for building web applications. Mesop versions prior to 1.3.3 expose a GET /__hot-reload__ endpoint when running in debug mode. The endpoint contains an unbounded polling loop controlled by a user-supplied counter query parameter. An unauthenticated attacker can send requests with high counter values that hold worker threads indefinitely. Repeated requests exhaust the worker pool, rendering the server unresponsive until it is manually restarted. The issue is fixed in Mesop 1.3.3. This weakness is classified as CWE-400: Uncontrolled Resource Consumption.

Critical Impact
A single unauthenticated attacker can crash a Mesop debug-mode server with minimal effort by exhausting worker threads through the /__hot-reload__ long-poll endpoint.

Affected Products

Mesop (Python UI framework) versions prior to 1.3.3
Applications running Mesop in debug mode with the /__hot-reload__ endpoint reachable
Deployments exposing Mesop debug routes to untrusted networks

Discovery Timeline

2026-08-25 - CVE-2026-77357 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-77357

Vulnerability Analysis

Mesop registers a debug route /__hot-reload__ via configure_debug_routes in mesop/server/server_debug_routes.py. The handler reads a client-supplied counter integer from the request and enters a while True loop that only exits when the server-side hot_reload_counter exceeds the supplied value. The loop sleeps for 100 milliseconds between checks but never enforces a maximum duration.

An attacker submits a counter value larger than any value the server will ever reach in normal operation. The request handler blocks forever, holding one worker thread. Sending many such requests in parallel consumes every worker in the pool. Legitimate requests are then queued indefinitely and the server appears offline until restarted.

Root Cause

The root cause is missing input validation and missing timeout bounds on a long-polling endpoint. The counter parameter is trusted and the polling loop has no upper time or iteration limit. This is a classic uncontrolled resource consumption weakness on a request-handling code path.

Attack Vector

The attack is remote and unauthenticated over the network. The attacker only needs HTTP access to a Mesop instance running in debug mode. A minimal request such as GET /__hot-reload__?counter=999999999 is sufficient to occupy one worker. Repeating the request to match the worker pool size stalls the server.

python

# Patched handler in mesop/server/server_debug_routes.py
# Source: https://github.com/mesop-dev/mesop/commit/2b8e7f2c349c9e2eec202f46b07bada83061ce2d

_MAX_POLL_SECONDS = 25

def configure_debug_routes(flask_app: Flask):
  @flask_app.route(prefix_base_url("/__hot-reload__"))
  def hot_reload() -> Response:
    counter = int(request.args["counter"])
    start_time = time.monotonic()
    while counter >= runtime().hot_reload_counter:
      if time.monotonic() - start_time > _MAX_POLL_SECONDS:
        break
      # Sleep a short duration but not too short that we hog up excessive CPU.
      time.sleep(0.1)

The fix caps each poll at 25 seconds, ensuring workers are released even when the counter never advances. A corresponding client update in mesop/web/src/services/channel.ts re-polls when the counter is unchanged so hot reload continues to function correctly.

Detection Methods for CVE-2026-77357

Indicators of Compromise

Multiple concurrent GET /__hot-reload__ requests from the same source IP or a small set of IPs
Requests to /__hot-reload__ with unusually large counter query values
Sustained increase in in-flight request counts and worker-thread saturation on the Mesop process
Application logs showing stalled requests to the debug route without a matching response

Detection Strategies

Alert on any traffic to /__hot-reload__ originating from outside development networks
Baseline normal counter values and flag requests with values above expected ranges
Monitor Flask or WSGI worker utilization and alert on prolonged 100% worker occupancy
Correlate long-running request durations on the debug route with client IP concentration

Monitoring Recommendations

Enable request-duration and per-endpoint metrics for the Mesop application
Log source IP, counter parameter, and response time for every /__hot-reload__ call
Track process-level thread counts and queue depth for the WSGI server hosting Mesop
Forward Mesop and reverse-proxy logs to a central analytics platform for anomaly detection

How to Mitigate CVE-2026-77357

Immediate Actions Required

Upgrade Mesop to version 1.3.3 or later, which bounds /__hot-reload__ poll duration to 25 seconds
Disable debug mode in any Mesop deployment that is reachable from untrusted networks
Block external access to the /__hot-reload__ route at the reverse proxy or WAF
Review Mesop instances currently exposed to the internet and take vulnerable hosts offline until patched

Patch Information

The fix is included in Mesop 1.3.3. See the GitHub Release v1.3.3, the patch commit 2b8e7f2, and the GitHub Security Advisory GHSA-8p72-497j-83mx. The server-side change caps each long-poll at _MAX_POLL_SECONDS = 25, and the client-side change re-polls when the counter is unchanged.

Workarounds

Run Mesop only in production mode when deployed outside a developer workstation
Add a reverse-proxy rule that denies requests to /__hot-reload__ from non-local addresses
Enforce per-endpoint request timeouts at the WSGI server or load balancer to release stalled workers
Rate-limit requests to Mesop debug routes to prevent worker-pool exhaustion

bash

# Example nginx rule to block external access to the Mesop debug endpoint
location = /__hot-reload__ {
    allow 127.0.0.1;
    allow ::1;
    deny all;
}

# Upgrade Mesop to the patched version
pip install --upgrade "mesop>=1.3.3"