Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
MEDIUM severity

CVE-2026-40115 praisonai

MEDIUM

CVE-2026-40115 is a medium-severity (CVSS 6.2) CWE-770 vulnerability in praisonai. A fix is available for praisonai — see the affected versions and patch details below.

PraisonAI has an Unrestricted Upload Size in WSGI Recipe Registry Server Enables Memory Exhaustion DoS

Also known asGHSA-2xgv-5cv2-47vvPYSEC-2026-2896
Published
Apr 9, 2026
Updated
Aug 12, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40115.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs27th percentile — riskier than 27% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

CVE-2026-40115 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐍praisonai

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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):

content_length = int(environ.get("CONTENT_LENGTH", 0))
body = environ["wsgi.input"].read(content_length) if content_length > 0 else b""

The content_length 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):

result = {"fields": {}, "files": {}}
boundary_bytes = f"--{boundary}".encode()
parts = body.split(boundary_bytes)

The _parse_multipart 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):

with tempfile.NamedTemporaryFile(suffix=".praison", delete=False) as tmp:
    tmp.write(bundle_content)

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):

def _check_auth(self, headers: Dict[str, str]) -> bool:
    if not self.token:
        return True  # No token configured = no auth

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

The entry point is praisonai registry serve (cli/features/registry.py:176), which calls run_server() 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

# 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:

# In create_wsgi_app(), before reading the body:
MAX_REQUEST_SIZE = 10 * 1024 * 1024  # 10MB, matching serve.py

def application(environ, start_response):
    # ... existing code ...
    
    # Read body with size limit
    try:
        content_length = int(environ.get("CONTENT_LENGTH", 0))
    except (ValueError, TypeError):
        content_length = 0
    
    if content_length > MAX_REQUEST_SIZE:
        status = "413 Request Entity Too Large"
        response_headers = [("Content-Type", "application/json")]
        body = json.dumps({
            "error": {
                "code": "request_too_large",
                "message": f"Request body too large. Max: {MAX_REQUEST_SIZE} bytes"
            }
        }).encode()
        start_response(status, response_headers)
        return [body]
    
    body = environ["wsgi.input"].read(content_length) if content_length > 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()

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIpraisonaiall versions4.5.128pip install --upgrade 'praisonai==4.5.128'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for praisonai, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update praisonai to 4.5.128 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-40115 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-40115 can be triaged on real exposure rather than presence alone.

Tailored to CVE-2026-40115. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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/serv
O3 Security · Impact-Aware SCA

Is CVE-2026-40115 in your dependencies?

O3 Security finds CVE-2026-40115 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

CVE-2026-40115: praisonai (Medium 6.2) | O3 Security