PraisonAI AgentTeam.launch() missing authentication: anyone who can reach the server can list and call your AI agents

Who is affected

Sources disagree on the affected range: The CVE record (CNA: GitHub) says praisonaiagents before 1.6.59 and PraisonAI before 4.6.59. The maintainer’s own GitHub security advisory (that page contains attack code, so we don’t link to it) says praisonaiagents 4.6.57 and earlier are affected and 1.6.59 or later is fixed. praisonaiagents uses 1.x version numbers, so in PlainCVE’s view the advisory’s upper bound looks like a PraisonAI version number entered for praisonaiagents by mistake; the GitLab advisory database says before 1.6.59. Both advisories list praisonaiagents 1.6.59 or later as fixed.

The reporter tested release v4.6.57 and the main-branch commit 2f9677ab at the time. An attacker needs to reach the server over the network, and Agents.launch() binds to 0.0.0.0 (all network interfaces) by default; the official docs show the same for remote access. In PlainCVE’s view, this makes accidental exposure more likely.

How it works

PraisonAI can wrap a team of AI agents (programs driven by a language model that call tools to finish tasks) as an HTTP service. AgentTeam.launch() and its alias Agents.launch() register three kinds of endpoints (URL paths on the server that can be called): one lists the agents, two call them. The problem is that these routes never check who is calling before listing agents or running agent.chat(). The maintainer’s advisory says requests with no Authorization header (the field that carries login credentials) are accepted, and so are requests with an obviously wrong token (an access credential).

This maps to CWE-306 (missing authentication for critical function) and CWE-862 (missing authorization). The maintainer’s advisory also describes it as a sibling of earlier PraisonAI advisories about unauthenticated API servers, a variant the earlier fixes did not cover.

According to the CVE record, anyone who can reach the server may be able to list agents, use up model resources (such as paid model usage), reach private context connected to the agents, and trigger agent tools or workflow side effects. Which of these is possible depends on the agents deployed.

The flawed approach (conceptual illustration, not the original source code):

@app.post("/{path}/{agent_id}")
def call_agent(agent_id, body):
    # No identity check at all; run the agent directly
    return agents[agent_id].chat(body.message)

The fixed approach:

@app.post("/{path}/{agent_id}")
def call_agent(agent_id, body, request):
    if not is_authorised(request):   # reject without a valid key
        raise Unauthorized()
    return agents[agent_id].chat(body.message)

The fix commit b4270173 is titled as adding API key authentication middleware. Its diff shows that praisonaiagents/agents/agents.py gains an _authorise_launch_request check: the token comes from the PRAISONAI_LAUNCH_AUTH_TOKEN environment variable and is compared against the Authorization: Bearer or X-Auth-Token header, with a 401 on mismatch. Note that if the environment variable is not set, the check allows every request, and the fix does not change launch()’s default bind address.

Timeline

Further reading

• Scoring: 9.8 is the CVSS 3.1 score from the CNA (GitHub). NVD has not done its own analysis yet (status: Awaiting Analysis, as checked on 2026-10-17), so GitHub’s is the only score.
• Disclosure date: The maintainer’s GitHub security advisory was published on 2026-06-17 (published_at in the GitHub API; that page contains attack code, so we don’t link to it), before the CVE record on 2026-10-12, so this page uses June 17 as the first public disclosure. The 2026-06-18 date shown by OSV and GitLab is when the GitHub Advisory Database reviewed the entry; the 2026-07-23 date on Vulert’s CVE page is the PYSEC-2026-3537 publication date.
• Is it “remote code execution”? Miggo labels this CVE “Unauth RCE” (unauthenticated remote code execution). The maintainer’s advisory and the CVE record describe unauthenticated agent invocation and don’t claim arbitrary code execution. Our analysis: whether it leads to code execution depends on the tools the agents have, so treat the label as unconfirmed.
• Exploitation status: The advisory includes a local-only proof of concept that confirms the endpoints answer without authentication (that page contains attack code, so we don’t link to it). That is a public test, not evidence of attacks. The sources show no evidence of exploitation in the wild or before a patch existed. FIRST’s EPSS (a score predicting the chance of exploitation) is 0.33% (about the 24th percentile, as of 2026-10-16).
• Credit: The maintainer’s GitHub security advisory credits rexpository as the reporter. The CVE record’s discovery field is UNKNOWN; that field describes how the issue was found, not who is credited.
• Other ID: PYSEC-2026-3537.