io.github.MervinPraison/praisonai

PraisonAI has a Browser Server WebSocket origin validation bypass via unanchored regex (patch bypass of CVE-2026-40289 / GHSA-8x8f-54wf-vv92)

### Summary `praisonai/browser/server.py` validates incoming WebSocket connections using a Chrome extension Origin check. The regex `chrome-extension://[a-z0-9]{32}` is applied with `re.match()`, which **only anchors at the start of the string, not the end**. Any Origin header with more than 32 alphanumeric characters after `chrome-extension://` — including non-alphanumeric trailing characters — passes the check. This is a **patch bypass** of GHSA-8x8f-54wf-vv92. That advisory triggered the ad

PraisonAI: Origin-validation bypass (startswith prefix match) enables unauthenticated cross-site request forgery against the PraisonAI MCP HTTP server

### Summary The PraisonAI MCP server exposes an HTTP-stream transport (praisonai mcp serve --transport http-stream) that binds to localhost and, by default, has no API key. Its only access control for browser-originated requests is an Origin allowlist, which the code implements as required by the MCP 2025-11-25 security guidance. The allowlist check uses a prefix match (request_origin.startswith(allowed)), so any Origin whose string begins with http://localhost or http://127.0.0.1 is accepted,

PraisonAI: Authentication fail-open in Recipe server allows unauthenticated access when API key or JWT auth is configured without a secret

### Summary The PraisonAI Recipe HTTP server silently allows unauthenticated requests when `auth` is configured as `api-key` or `jwt` but the corresponding secret is missing. This creates an authentication fail-open condition. An operator can start the Recipe server with authentication enabled, including on a non-localhost interface, but the server still accepts unauthenticated requests if no API key or JWT secret is provided. The issue is especially risky because the CLI safety check for non

PraisonAI: [Auth Bypass] PraisonAI async Jobs API (`/api/v1/runs`) has no authentication — unauthenticated job execution, result theft, cancel and delete

### Summary PraisonAI's async **Jobs API** (the FastAPI service in `praisonai/jobs/`) installs its router with no authentication middleware, no router-level dependency, and no per-route auth check. Any caller who can reach the jobs server can submit agent jobs (executed against the operator's configured LLM credentials), list every job in the shared store, read other jobs' results, cancel running jobs, and delete terminal jobs — with no token, cookie, session, or per-job ownership value. The s

PraisonAI: `--api-key` flag on `praisonai serve` is not properly enforced

## Summary `praisonai serve agents` and `praisonai serve unified` both accept `--api-key` for authentication. The flag is parsed but never wired into the FastAPI app — no middleware, no header check, nothing. The server runs wide open regardless of what key you set. Tested on 4.6.50 from PyPI. ## Affected versions - Confirmed on **4.6.50** (current PyPI, 2026-06-02) - Likely since **4.6.34** when the serve subsystem shipped - File: `src/praisonai/praisonai/cli/features/serve.py` ## What happ