Summary
PraisonAI: Jobs API is unauthenticated by default and allows attacker-controlled webhook SSRF
PraisonAI's Async Jobs API enables its API-key middleware only when PRAISONAI_JOBS_API_KEY is set, so by default every endpoint is unauthenticated. An unauthenticated POST /api/v1/runs accepts an attacker-controlled webhook_url; on job completion the server POSTs the job payload to it via httpx. The webhook_url 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:
praisonai4.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:create_app
Snippet:
jobs_api_key = os.environ.get("PRAISONAI_JOBS_API_KEY")
# ...
if jobs_api_key:
app.add_middleware(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:submit_job
Snippet:
@router.post("", response_model=JobSubmitResponse, status_code=202)
async def submit_job(request, response, body: JobSubmitRequest, ...):
# no auth dependency; body.webhook_url is attacker-controlled
job = Job(prompt=body.prompt, webhook_url=body.webhook_url, ...)
await executor.submit(job)
Issue: attacker-controlled webhook_url 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:validate_webhook_url → _send_webhook
Snippet:
# models.py validate_webhook_url (CHECK time)
ip = socket.gethostbyname(hostname)
if ipaddress.ip_address(ip).is_private or ...:
raise ValueError("Webhook URL resolves to a private or restricted network address")
# executor.py _send_webhook (CONNECT time, re-resolves, no pinning)
async with httpx.AsyncClient(timeout=30.0) as client:
response = await client.post(job.webhook_url, 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
- Operator runs the Jobs API without
PRAISONAI_JOBS_API_KEY(default → unauth). - Attacker
POST /api/v1/runswithwebhook_url= a rebinding domain. - The validator(s) see a public IP (pass); on completion
httpx.postre-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 webhook_url 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
PRAI-04-01-Jobs-Submit-NoAuth:POST /api/v1/runs {"prompt":"hello"}→202(no auth).PRAI-04-02-Jobs-Webhook-SSRF-Blind:POST /api/v1/runs {"prompt":"hello","webhook_url":"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.
Suggested remediation
- Authenticate the Jobs API by default (auto-generate a token / fail closed when binding non-loopback), like the gateway.
- For
webhook_url: resolve once, reject private/loopback/CGNAT/metadata, then pin and connect to the validated IP; disable redirects.
Impact
Unauthenticated job submission (LLM cost abuse); SSRF to internal services (blind, DNS-rebinding); exfiltration of the job result to an attacker-controlled webhook.
A critical operation is accessible without requiring any authentication. Typical impact: any user can invoke the privileged function.
CVE-2026-60091 has a CVSS score of 7.2 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.6.78); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-60091? CVE-2026-60091 is a high-severity missing authentication for critical function vulnerability in praisonai (pip), affecting versions <= 4.6.77. It is fixed in 4.6.78. A critical operation is accessible without requiring any authentication.
- How severe is CVE-2026-60091? CVE-2026-60091 has a CVSS score of 7.2 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of praisonai are affected by CVE-2026-60091? praisonai (pip) versions <= 4.6.77 is affected.
- Is there a fix for CVE-2026-60091? Yes. CVE-2026-60091 is fixed in 4.6.78. Upgrade to this version or later.
- Is CVE-2026-60091 exploitable, and should I be worried? Whether CVE-2026-60091 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-60091 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-60091? Upgrade
praisonaito 4.6.78 or later.