CVE-2025-71377 Overview
CVE-2025-71377 affects stoatchat (delta) versions before 20250210-1 (0.8.2). The flaw is a logic error in the query messages route that handles fetches for messages nearby another message. When the request supplies a message limit of zero, the database interprets the value as no limit and returns the entire channel history in one query. A remote unauthenticated attacker can issue many such requests in parallel to exhaust server resources. The result is a denial of service condition affecting availability of the chat service.
Critical Impact
Unauthenticated attackers can drain server resources by triggering unbounded database queries, causing service-wide denial of service.
Affected Products
- stoatchat (delta) versions prior to 20250210-1
- stoatchat release 0.8.2 and earlier
- Deployments exposing the nearby message query route
Discovery Timeline
- 2026-07-16 - CVE-2025-71377 published to NVD
- 2026-07-16 - Last updated in NVD database
Technical Details for CVE-2025-71377
Vulnerability Analysis
The vulnerability is a business logic error in the OptionsQueryMessages handler within stoatchat's message API. The limit field is passed to MongoDB through FindOptions::builder().limit(limit / 2). When the client supplies limit = 0 or limit = 1, integer division yields 0, and the MongoDB driver treats a limit of zero as unbounded. The route responsible for fetching messages nearby a target message therefore returns the full message history for the channel. This maps to [CWE-1025] Comparison Using Wrong Factors in the logic path that validates and forwards the limit.
Root Cause
Input validation on limit did not enforce a minimum of one before the value was divided and passed to the database driver. The validator annotation existed on the struct, but the runtime path bypassed it for nearby fetches by dividing the caller-supplied value. Zero, once submitted to MongoDB, disables the limit clause entirely.
Attack Vector
A remote unauthenticated attacker sends crafted nearby message fetch requests over the network. Each request forces the server to load, serialize, and transmit the entire message history of a channel. Parallel requests multiply memory, CPU, and I/O consumption on the backend, degrading or halting the service.
// Patch: crates/core/database/src/models/messages/ops/mongodb.rs
COL,
older_message_filter,
FindOptions::builder()
- .limit(limit / 2)
+ .limit(limit / 2 + 1)
.sort(doc! {
"_id": -1_i32
})
Source: GitHub Commit 5f84daa9
// Patch: crates/core/models/src/v0/messages.rs
pub struct OptionsQueryMessages {
/// Maximum number of messages to fetch
///
- /// For fetching nearby messages, this is `(limit + 1)`.
+ /// For fetching nearby messages, this is `(limit + 2)`.
#[cfg_attr(feature = "validator", validate(range(min = 1, max = 100)))]
pub limit: Option<i64>,
/// Message id before which messages should be fetched
Source: GitHub Commit 5f84daa9
Detection Methods for CVE-2025-71377
Indicators of Compromise
- Unauthenticated HTTP requests to the nearby message query endpoint with limit=0 or limit=1
- Bursts of parallel message fetch requests originating from a single source or small set of sources
- MongoDB slow query logs showing large unbounded reads on the messages collection
- Sudden spikes in outbound response size from the stoatchat API tier
Detection Strategies
- Inspect application access logs for nearby message queries where the limit parameter is 0, missing, or below the documented minimum of one.
- Correlate database query duration and returned document count against expected per-request limits of 100 or fewer.
- Alert on rapid growth in memory or CPU utilization on stoatchat backend workers coinciding with concentrated inbound API traffic.
Monitoring Recommendations
- Enable MongoDB profiling to capture queries with high docsExamined or nreturned values against the messages collection.
- Track request rate and payload size on the message query endpoint, alerting on statistical deviations from baseline.
- Log the raw limit value received from clients before any transformation to detect probing for the zero-limit condition.
How to Mitigate CVE-2025-71377
Immediate Actions Required
- Upgrade stoatchat (delta) to version 20250210-1 (0.8.2 patched build) or later without delay.
- Place the stoatchat API behind a reverse proxy that enforces request rate limits and request body validation.
- Restrict unauthenticated access to the message query route where operationally acceptable.
Patch Information
The fix is committed in stoatchat commit 5f84daa9 and documented in the GitHub Security Advisory GHSA-h7h6-7pxm-mc66. The patch guarantees the value passed to FindOptions::builder().limit(...) is always at least one by changing limit / 2 to limit / 2 + 1 and adjusting the documented nearby offset. Additional context is available in the VulnCheck Advisory.
Workarounds
- Configure a WAF or API gateway rule that rejects requests where the limit query parameter is absent, zero, or greater than 100.
- Apply per-IP and per-endpoint rate limiting on the /messages nearby fetch route to blunt parallel abuse.
- Terminate long-running database queries with a server-side maxTimeMS setting on the messages collection.
# Example NGINX rule rejecting invalid limit values on the message query route
location /api/channels/ {
if ($arg_limit !~ ^([1-9]|[1-9][0-9]|100)$) {
return 400;
}
limit_req zone=msgapi burst=20 nodelay;
proxy_pass http://stoatchat_backend;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

