GHSA-4w49-gwv8-fpjg: Infoleak
Summary
PraisonAI's Async Jobs API enables its API-key middleware only when PRAISONAIJOBSAPIKEY is set, so by default every endpoint is unauthenticated. An unauthenticated POST /api/v1/runs accepts an attacker-controlled webhookurl; on job completion the server POSTs the job payload to it via httpx. The webhookurl has an SSRF validator (gethostbyname + private-IP check), but it validates at request time while httpx re-resolves at connection time — a DNS-rebinding TOCTOU that reaches internal services. Runtime-confirmed as an unauthenticated, blind SSRF (the internal canary received the POST; the internal response is not returned to the attacker). Severity Medium.
Details
Affected component - Package: praisonai 4.6.63. Files: src/praisonai/praisonai/jobs/server.py, jobs/router.py, jobs/executor.py, jobs/models.py.
Vulnerable code / root cause
Path: src/praisonai/praisonai/jobs/server.py
Function: createapp
Snippet: python jobsapikey = os.environ.get("PRAISONAIJOBSAPIKEY") ... if jobsapikey: app.addmiddleware(JobsAPIKeyMiddleware) # auth ONLY when env var is set Issue: with the env var unset (default), no auth middleware is added → all endpoints unauthenticated. Default bind is 127.0.0.1.
Path: src/praisonai/praisonai/jobs/router.py
Function: submitjob
Snippet: python @router.post("", responsemodel=JobSubmitResponse, statuscode=202) async def submitjob(request, response, body: JobSubmitRequest, ...): # no auth dependency; body.webhookurl is attacker-controlled job = Job(prompt=body.prompt, webhookurl=body.webhookurl, ...) await executor.submit(job) Issue: attacker-controlled webhookurl flows into the job with no authentication on the endpoint.
Path: src/praisonai/praisonai/jobs/models.py (validator) and src/praisonai/praisonai/jobs/executor.py (sink)
Function: validatewebhookurl → sendwebhook
Snippet: python models.py validatewebhookurl (CHECK time) ip = socket.gethostbyname(hostname) if ipaddress.ipaddress(ip).isprivate or ...: raise ValueError("Webhook URL resolves to a private or restricted network address")
executor.py sendwebhook (CONNECT time, re-resolves, no pinning) async with httpx.AsyncClient(timeout=30.0) as client: response = await client.post(job.webhookurl, json=payload, ...) Issue: the validator resolves the hostname at validation time but does not pin the IP for the httpx.post connection → DNS rebinding (independent resolution at check vs connect) bypasses it and reaches internal services.
Attack flow 1. Operator runs the Jobs API without PRAISONAIJOBSAPIKEY (default → unauth). 2. Attacker POST /api/v1/runs with webhookurl = a rebinding domain. 3. The validator(s) see a public IP (pass); on completion httpx.post re-resolves to an internal IP and connects → SSRF to internal.
Why existing protection is bypassed Auth is opt-in (only when the env var is set). The webhookurl validator resolves at check time but does not pin the IP for the connection → DNS-rebinding TOCTOU. (Correction to an earlier static note: the guard exists but is bypassable.)
Security boundary Unauthenticated network peer → server-side request to internal services (Scope: Changed). Default bind 127.0.0.1 limits remote reach unless the operator binds non-loopback.
Proof of Concept
Environment Real Jobs API (python -m praisonai.jobs.server, no API key) in a local runtime (127.0.0.1:18085), resolver pointed at the controlled rebinding DNS, internal canary Docker-internal only. Runnable assets: PraisonAI-Runtime-Repro\runtime-files\ (docker-compose.jobs.yml).
Steps to reproduce 1. PRAI-04-01-Jobs-Submit-NoAuth: POST /api/v1/runs {"prompt":"hello"} → 202 (no auth). 2. PRAI-04-02-Jobs-Webhook-SSRF-Blind: POST /api/v1/runs {"prompt":"hello","webhookurl":"http://rebind.lab:8081/secret"} → 202.
Expected result Unauthenticated job submission should be rejected; the webhook SSRF guard should prevent reaching internal services regardless of DNS timing.
Impact Unauthenticated job submission (LLM cost abuse); SSRF to internal services (blind, DNS-rebinding); exfiltration of the job result to an attacker-controlled webhook.
Suggested remediation - Authenticate the Jobs API by default (auto-generate a token / fail closed when binding non-loopback), like the gateway. - For webhookurl: resolve once, reject private/loopback/CGNAT/metadata, then pin and connect to the validated IP; disable redirects.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/praisonaito a version that resolves this vulnerability.Fixed in 4.6.78 - Configuration
Require API-key authentication by default by setting PRAISONAI_JOBS_API_KEY to a non-empty token; alternatively, fail closed when binding the Jobs API to a non-loopback address.
PraisonAI Async Jobs API PRAISONAI_JOBS_API_KEY = non-empty token - Compensating control
For webhook_url, resolve the hostname once, reject private, loopback, CGNAT, and metadata addresses, pin the connection to the validated IP, and disable redirects.
Event History
Frequently Asked Questions
Which deployments are exposed without credentials?
Deployments with the Async Jobs API available and PRAISONAI_JOBS_API_KEY unset have no API-key middleware enabled. In that default state, an unauthenticated attacker can submit a run request.
What does an attacker need to exploit the internal request behavior?
The attacker needs to submit a POST request to /api/v1/runs with an attacker-controlled webhook_url and use DNS rebinding so the hostname passes the initial public-IP validation but resolves to an internal address when httpx connects.
Does enabling PRAISONAI_JOBS_API_KEY fully eliminate the issue?
It prevents unauthenticated use of the Jobs API by enabling the API-key middleware. The provided data does not indicate that it removes the DNS rebinding flaw for authenticated callers.
Can an attacker read responses from internal services through this issue?
The confirmed behavior is blind SSRF: the server sends the job payload to the internal target, but the internal service response is not returned to the attacker.