Praisonai EUVD-2026-21160

This vulnerability presents a moderate but realistically exploitable denial of service risk. The CVSS score of 6.2 reflects the local attack vector (AV:L), low complexity (AC:L), and high availability impact (A:H), correctly rating it as Medium severity. The local-only attack vector significantly constrains real-world applicability compared to network-accessible services, limiting the threat to scenarios where an attacker has shell access or can spawn processes on the same host. However, the absence of authentication (PR:N) and low attack complexity (AC:L) make exploitation trivial once local access is achieved. The vulnerability is not listed as actively exploited in public KEV databases, and no public proof-of-concept code has been independently confirmed. The default-disabled authentication posture and the existence of a properly implemented size-limit in the alternative Starlette server suggest this was a design oversight rather than a sophisticated bypass. Organizations running PraisonAI in multi-tenant environments or with untrusted local users should prioritize patching; isolated single-user deployments face lower practical risk. The availability impact (denial of service) is severe but not escalable to confidentiality or integrity breaches.

An attacker with local shell access to a host running PraisonAI crafts a custom HTTP POST request to the WSGI recipe registry server with a fraudulent Content-Length header claiming a payload of 10GB, then sends only a small amount of data. The WSGI server allocates memory to buffer the claimed Content-Length and enters a wait state for the remaining data, accumulating memory pressure. By repeating this attack with multiple concurrent requests, the attacker exhausts available system memory, causing the PraisonAI server process to be terminated by the OS out-of-memory killer, resulting in service unavailability. No authentication is required because token-based authentication is disabled by default. Attack complexity is low because the attacker only needs to construct a standard HTTP POST request with a malicious Content-Length header; no special exploit code or deep protocol knowledge is required.