PraisonAI shipped auth-off-by-default; first exploit attempt landed in under 4 hours
CVE-2026-44338, disclosed on May 14, 2026, is an authentication bypass in PraisonAI's legacy Flask API server caused by a single defining choice: AUTH_ENABLED was hard-coded to False and AUTH_TOKEN to None. Anything reachable on the network could enumerate configured agents via GET /agents and trigger the configured agents.yaml workflow via POST /chat, with no token required. Within three hours, forty-four minutes, and thirty-nine seconds of the advisory becoming public, a scanner identifying itself as "CVE-Detector/1.0" was already probing the exact vulnerable endpoint on internet-exposed PraisonAI instances. The bug affects versions 2.5.6 through 4.6.33 and is fixed in 4.6.34. The rapid-exploitation timeline is the part that should worry every operator of an open-source AI agent framework, not the CVSS 7.3 score.
Incident Details
Tech Stack
References
The bug is two lines of code
PraisonAI's legacy Flask API server defines two constants near the top of the file: AUTH_ENABLED = False and AUTH_TOKEN = None. Those two lines are the entire authentication model. As long as the server is running with the legacy API enabled, anyone who can reach the network port can interact with the endpoints that drive the platform's agents.
The CVE record, published as CVE-2026-44338 with a CVSS score of 7.3, describes the two vulnerable endpoints:
GET /agentsreturns the configured agent metadata, including the path of the agents definition file and the list of available agents.POST /chataccepts a JSON body containing amessagekey and executes the configuredagents.yamlworkflow. The Sysdig analysis notes that the submitted message value is actually ignored; what the request does is trigger the workflow that has already been wired up on the server.
The combination means an unauthenticated caller can both learn what the platform is configured to do and then make it do that thing, without ever providing a credential. The affected versions are 2.5.6 through 4.6.33; the fix is in 4.6.34.
The 3-hour, 44-minute timeline
Sysdig's writeup is the document to read on this one. Their honeypot-style monitoring caught the first targeted request against the vulnerable PraisonAI endpoint at three hours, forty-four minutes, and thirty-nine seconds after the advisory became public. The scanning client identified itself as "CVE-Detector/1.0," which is consistent with one of the publicly available CVE-tracking scanner stacks that operates by ingesting fresh advisories and immediately turning them into probe rules.
CSO Online, The Hacker News, and GBHackers all picked up the timing detail as the centerpiece of their coverage, because it is unusual. Most authentication-bypass bugs in mainstream frameworks take days or weeks to see meaningful exploitation traffic; some never see it at all. The CVE-Detector hit on PraisonAI in under four hours is closer to the timeline you would expect for a critical IIS or Apache bug than for a vulnerability in an open-source AI agent framework that most security teams have never heard of.
The reason the timeline matters is that it shortens the patching window operators have. Even an operator who is actively monitoring CVE feeds for the frameworks they run is unlikely to push a patched container image into production within four hours of a public advisory. The realistic patch window for most teams is days. The exploitation window opened in hours.
What the chain looks like for attackers
The Sysdig analysis walked through the practical attacker workflow:
- Discovery. Scanners walk public IP ranges looking for PraisonAI's default ports and characteristic HTTP responses. The platform's open-source provenance means default ports and default response shapes are well known.
- Enumeration. The attacker hits
GET /agentsto retrieve the configured agent metadata, including the agents definition file name. This tells the attacker what the deployment is wired to do. - Execution. The attacker fires
POST /chatwith any payload. The configured workflow runs. The body of the request does not need to be meaningful; the server triggers the agent run regardless of message content.
In a typical PraisonAI deployment, the configured workflow has access to whatever the operator wired it to: API keys for external services, tool integrations, knowledge bases, and downstream agent calls. Attackers do not need to know any of those secrets up front. They just need to invoke the workflow and let the platform's own configured access do the work. API-quota drain is the most immediate concrete cost; the more interesting attacker outcome is using the agent's configured tool access as a pivot into adjacent systems.
Why the default matters more than the CVSS score
CVSS 7.3 looks moderate next to OpenClaw's Claw Chain CVE-2026-44112 at 9.6 from the same general window. The two stories are different in important ways.
Claw Chain is a set of code-level bugs in an otherwise security-conscious architecture. The OpenShell sandbox was designed to contain code execution; CVE-2026-44112 punches a hole in that sandbox. The implementation got close, missed on the TOCTOU race, and shipped a serious vulnerability that needed a patch.
PraisonAI's CVE-2026-44338 is a configuration choice. AUTH_ENABLED was hard-coded to False. AUTH_TOKEN was hard-coded to None. There is no implementation bug to fix; the implementation worked exactly as the constants told it to. The vulnerability is that the project shipped with the constants set that way and exposed an API server in that state by default.
In agent-platform security, default permissive configurations tend to be more dangerous than implementation bugs. An implementation bug gets a patch; operators who track CVE feeds upgrade and move on. A permissive default propagates everywhere the platform is deployed and survives upgrades until someone notices the configuration is wrong. Many of the OpenClaw exposure incidents previously documented on Vibe Graveyard - 135,000 instances publicly exposed without authentication, the malicious skills campaign, the infostealer config exfiltration - all trace back to operators running OpenClaw with the default configuration that left the API reachable. PraisonAI just shipped the same failure mode with two lines of explicit constants.
What the patch actually does
PraisonAI 4.6.34 changes the defaults: AUTH_ENABLED defaults to True and AUTH_TOKEN must be set by the operator before the legacy API server will start. The release notes also recommend that operators rotate any credentials accessible through their previously exposed deployments, on the assumption that an attacker who had even short access to the running workflow could have extracted tokens or pivoted into integrated services.
The fix is correct. The harder question is the gap between fix availability and fix adoption. The Sysdig writeup ends on the same point that comes up in every rapid-exploitation story: the patch was available within the same window the exploitation traffic was already running. Operators who patched in the first day were fine. Operators on a weekly patching cadence were exposed for the entire week. Operators who did not subscribe to PraisonAI's advisory channel may still be exposed today.
The graveyard lesson
The pattern this CVE illustrates is one that Vibe Graveyard's vibe-coding and AI-framework coverage keeps returning to. Platforms in this space ship with defaults that optimize for "it works out of the box," because making the developer experience smooth is how the platform wins early adopters. The cost of that posture lands on the operator population that never re-reads the configuration after the demo works.
Two things would change the failure mode going forward. First, projects in this category should refuse to start an API server with auth disabled unless the operator passes an explicit --allow-unauthenticated flag, the same shape of friction that databases and message queues already use. Second, advisory disclosure for AI agent frameworks should assume rapid exploitation as the default scenario and structure release notes accordingly: lead with the active-exploitation status, the patched version, and the credential-rotation step, rather than burying those steps below long technical analyses.
The CVE-Detector scan that hit PraisonAI in under four hours was not unusual. It was the new normal. The question is whether the projects on the receiving end of that scan are going to keep shipping defaults that make a single advisory the only thing standing between an attacker and a configured agent workflow.
Discussion