Affected: MervinPraison PraisonAI

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, the Jobs API create_app function mounts /api/v1/runs without authentication. Any reachable caller can submit jobs, read results, cancel runs, or delete jobs using operator credentials. The fix adds PRAISONAI_JOBS_API_KEY middleware for Authorization or X-API-Key. This issue is fixed in version 4.6.58.

Affected: PyPI: praisonai

### 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 server's default bind is `127.0.0.1`, so remote reach requires an operator to bind a public interface, container-publish, reverse-proxy, or tunnel the service. Once reachable, the primitive is fully pre-authenticated. **This is a distinct, still-unpatched sibling of CVE-2026-44338.** That CVE (GHSA-6rmh-7xcm-cpxj, fixed in 4.6.34) covered only the *legacy Flask* server `src/praisonai/api_server.py`. The fix added `AUTH_ENABLED`/`AUTH_TOKEN`/`check_auth()` to that file and did **not** touch the FastAPI jobs module. At the latest commit (`9fcac3a`, version **4.6.51**) the legacy Flask server is patched but the jobs API remains completely unauthenticated.

## Technical Detail ### Source-to-sink trace The FastAPI app includes the jobs router with only CORS middleware — no auth (`server.py`, `create_app`): ```python # src/praisonai/praisonai/jobs/server.py def create_app(store=None, executor=None, cors_origins=None) -> FastAPI: app = FastAPI(title="PraisonAI Jobs API", ...)…