By A popular open-source AI agent framework shipped with authentication hard-coded off — and attackers were scanning for it less than four hours after the advisory went public. CVE-2026-44338 in PraisonAI is not a subtle misconfiguration a developer introduced. It is a deliberate default baked into every release from version 2.5.6 through 4.6.33: AUTH_ENABLED = False, hard-coded in src/praisonai/api_server.py. If your infrastructure runs one of those versions and it is internet-accessible, there is a reasonable chance someone has already run your workflows without your permission.
What PraisonAI Is and Why This Matters
PraisonAI is a production multi-agent AI framework built on top of CrewAI and AutoGen. It lets developers spin up autonomous agent workflows in roughly five lines of code, supports over 100 LLMs — including OpenAI, Anthropic, Google Gemini, and AWS Bedrock — and is used in enterprises for automation, customer service, and analysis. Its low-code YAML configuration makes it accessible. That same accessibility is what makes an unauthenticated API server dangerous: agent configs routinely embed API keys inline, and any workflow that processes internal data is now potentially exposed.
The Vulnerability: A Route That Fails Open by Design
The legacy Flask API server in PraisonAI ships with two unprotected routes:
- GET /agents — Returns the agent configuration metadata, including the definition file name and the full list of configured agents. No credentials required.
- POST /chat — Accepts any JSON body with a
messagekey and executes the configured PraisonAI workflow unconditionally. The message content is irrelevant; the workflow runs regardless of what is sent.
The check_auth() helper returns True whenever AUTH_ENABLED is False — which is the default. These routes do not fail closed. They fail open.
In practice, an attacker with network access sends POST /chat with any payload and your agent pipeline runs: LLM calls are made on your billing account, internal outputs are generated, and any API keys embedded in agents.yaml are reachable via GET /agents. The financial exposure from quota drain alone is real — a busy agent workflow hitting GPT-4o or Claude Opus burns money fast.
The Timeline That Should Concern You
The advisory was published on May 11, 2026 at 13:56 UTC. By 17:40 UTC — three hours and forty-four minutes later — automated scanners were actively probing internet-facing PraisonAI instances for this exact CVE.
This is not exceptional in 2026. The average time from CVE disclosure to first active exploitation has collapsed from 56 days in 2024 to roughly 10 hours today. Mandiant’s M-Trends 2026 report found that 28.3% of CVEs are now exploited within 24 hours of disclosure. AI tools can analyze a new advisory, generate candidate exploit code, and begin automated testing in under 15 minutes at costs approaching one dollar per attempt. The window between “advisory public” and “attacker has a working scanner” is no longer measured in days.
Check Your Version and Upgrade
The affected versions are 2.5.6 through 4.6.33. The fix ships in version 4.6.34, released the same day as the disclosure. To check your current version:
pip show praisonaiUpgrade with:
pip install --upgrade praisonaiBeyond upgrading, audit any instance that was internet-accessible during the exposure window. Rotate API keys stored in agents.yaml or passed to your agents as environment variables. Check your LLM provider billing dashboards for unexpected usage spikes — those are a reliable indicator of exploitation. The full CVE-2026-44338 advisory and Sysdig’s technical breakdown have additional remediation detail.
The Design Choice at the Root of This
CVE-2026-44338 is not a subtle memory corruption bug or a complex logic flaw. It is a line of code that reads AUTH_ENABLED = False and was committed, reviewed, and shipped across dozens of releases. That is a design choice, not an oversight.
The AI tooling ecosystem is moving fast and shipping rough edges. PraisonAI is not alone — multiple AI agent frameworks and MCP server implementations have shipped with authentication disabled or trivially bypassed in 2026. The pattern is consistent: developer experience wins over security defaults, and the assumption is that developers will harden things themselves before exposing anything to the internet. In practice, they do not always do that.
If your stack includes AI agent frameworks — PraisonAI, any CrewAI-based tooling, any Flask API proxy sitting in front of an LLM — audit the authentication defaults before your next deployment. The scanner does not care that you meant to enable it later.
