Listen to this Post
How the mentioned CVE works
Synapse uses worker threads and shared locks to process concurrent requests. Under normal operation, a `WorkerLock` coordinates access to critical sections, such as database queries or event handling. In vulnerable versions, an authenticated local user can issue a crafted request that triggers a path where the lock is held for an excessively long time – typically during the processing of large batched events or extended state‑resolution loops. Because the lock is not released, the worker thread becomes permanently blocked. Unlike a simple deadlock, the affected worker consumes full CPU cycles while waiting for the lock to be released, causing the thread to “spin”. Other requests that try to acquire the same lock are queued and never get CPU time. The server’s worker pool is limited, so a small number of such malicious requests can occupy all available workers. Consequently, legitimate user requests time out, new connections are rejected, and the homeserver enters a denial‑of‑service state. The vulnerability is rooted in the absence of a cap on the lock‑holding period. The fix introduces a 60‑second timeout on `WorkerLock` and refactors hot loops to yield the reactor, eliminating the starvation condition.
DailyCVE form
Platform: Synapse (Matrix)
Version: <1.152.1
Vulnerability: CPU starvation
Severity: High
date: 2026-05-14
Prediction: Patch available (1.152.1)
Analytics under heading What Undercode Say:
Check Synapse version python -c "import synapse; print(synapse.<strong>version</strong>)" 2>/dev/null || \ grep -oP 'version=\K[0-9.]+' /path/to/synapse/<strong>init</strong>.py Monitor CPU/worker saturation (watch top-like output) watch -n1 "ps aux | grep -c 'synapse|worker' && top -b -n1 | grep -E 'synapse|worker'" Simulate a request that could trigger the lock (requires auth token) curl -X GET "https://matrix.example.com/_matrix/client/v3/sync?timeout=30000" \ -H "Authorization: Bearer $TOKEN" --max-time 300
Exploit
A local authenticated user sends a specially crafted API call that forces Synapse to enter an unbounded `WorkerLock` acquisition loop. For example, fetching a large batch of state events or calling an endpoint that triggers deep state resolution while holding the lock. With 5–10 concurrent malicious requests, all worker threads become stuck in the lock‑contention path, starving the CPU and making the server unresponsive to any new requests.
Protection from this CVE
- Patch: Upgrade to Synapse 1.152.1 or later.
- Workaround: Place Synapse behind a reverse proxy (e.g., nginx) and apply rate‑limiting on authenticated user endpoints:
limit_req_zone $http_authorization zone=matrix:10m rate=5r/s; location /_matrix/ { limit_req zone=matrix burst=10 nodelay; proxy_pass http://synapse_backend; }
Impact
- Denial of service for all legitimate users of the affected homeserver.
- Worker threads become permanently saturated, consuming 100% CPU on the assigned cores.
- No data loss or corruption, but the server becomes completely unresponsive until restarted (or the malicious traffic stops).
- Only homeservers that trust all local users are immune; any other deployment is vulnerable.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
