cyberivy
PraisonAIAI SecurityCVE-2026-44338AI AgentsAuthentication BypassOpen SourceDevSecOpsSysdig

PraisonAI flaw shows how fast agent attacks now move

May 14, 2026

Ein Server-Rack mit Festplatten, Netzwerkkabeln und Statuslichtern in einem Rechenzentrum.

A PraisonAI flaw was targeted less than four hours after its GitHub advisory, Sysdig says. The issue: a legacy API server could trigger agent workflows without a token.

What this is about

PraisonAI, an open-source framework for multi-agent workflows, has patched a security flaw tracked as CVE-2026-44338. According to Sysdig, the vulnerability became public through a GitHub advisory at 13:56 UTC on May 11, 2026. By 17:40 UTC, Sysdig was already seeing targeted scans for the documented vulnerable endpoint. That is three hours, 44 minutes and 39 seconds.

This is not an abstract enterprise warning. It touches exactly the new class of tools that developers, DevOps teams and automation teams are putting into production: agents that read files, call APIs, handle tickets or control external services. When that kind of workflow is reachable without protection, the damage is not limited to a bad chat reply.

What PraisonAI actually does

PraisonAI coordinates multiple AI agents in a workflow. In the affected legacy component, api_server.py, authentication was disabled by default. The routes GET /agents and POST /chat were supposed to be protected, but according to the GitHub advisory and NVD, reachable callers could use them without a token.

GET /agents could expose agent metadata. POST /chat could start the configured agents.yaml workflow. The important detail: the flaw was not automatically a classic remote-code-execution bug. Its effect depended on what the local workflow was allowed to do. If that workflow had shell tools, file access, cloud APIs or model accounts, one unauthenticated request could still create very real side effects.

Affected versions ran from 2.5.6 to before 4.6.34. The fix is in version 4.6.34.

Why it matters

The hard signal is the time window. Sysdig says the scanner first checked generic paths such as /.env and /admin, then pivoted to PraisonAI-specific endpoints including /docs, /api/agents/config and /agents. The user agent was CVE-Detector/1.0.

For defenders, this means AI-agent advisories cannot be treated as something to review at the end of the week. Public CVE data, example code, patch diffs and scanners can be combined very quickly. Sysdig points to similar patterns around Marimo, LMDeploy and Langflow. The special issue with agents is that they are often deliberately given useful production permissions. That usefulness is also the risk.

In plain language

Imagine a workshop where a robot arm sorts screws, ships packages and starts machines. The workshop door is supposed to be locked. In some setups of this old PraisonAI component, the door was open. A stranger did not need to reprogram the robot. Pressing the start button could be enough to make it do whatever it was already allowed to do.

A practical example

A small SaaS team runs an internal agent that summarizes 200 support tickets per day, reads logs from an S3 bucket and sends Slack messages to engineering when needed. The service is accidentally reachable from the internet.

A scanner finds /agents, confirms the open configuration and marks the host as exploitable. A second bot calls POST /chat 5,000 times. The immediate damage could be model costs, leaked internal agent names, exposed logs or flooded Slack channels. If the workflow has write permissions, it can get worse: false tickets, changed files or triggered deployments.

Scope and limits

  • The vulnerability affects the legacy API server component, not automatically every PraisonAI deployment. A host that was never exposed faces a different risk than an internet-facing service.
  • The sources do not describe a universal remote-code-execution flaw. Practical impact depends heavily on the permissions inside the local agents.yaml workflow.
  • The observed scan proves targeted discovery, not necessarily large-scale successful exploitation. The short time to scanning is still a clear warning.

In practice, operators should upgrade to version 4.6.34 or later, stop using the legacy api_server.py entry point, avoid exposing agent services directly to the internet, and review logs for CVE-Detector/1.0, /agents, /chat, /api/agents and related paths.

SEO & GEO keywords

PraisonAI, CVE-2026-44338, GHSA-6rmh-7xcm-cpxj, AI agent security, authentication bypass, Sysdig, NVD, GitHub Advisory, agent workflows, MCP security, open-source AI security, DevSecOps

πŸ’‘ In plain English

An old PraisonAI API could start agent workflows without a token in certain setups. That is risky because agents often have access to files, APIs or model accounts. The most important signal is how quickly the flaw was scanned after disclosure.

Key Takeaways

  • β†’CVE-2026-44338 affects PraisonAI versions from 2.5.6 to before 4.6.34.
  • β†’Sysdig saw targeted scanning less than four hours after the GitHub advisory.
  • β†’The flaw could trigger agent workflows without a token when the legacy API was reachable.
  • β†’Impact depends on the permissions granted to the local agent workflow.
  • β†’Operators should upgrade to 4.6.34 and avoid exposing agent endpoints publicly.

FAQ

Is this remote code execution?

Not universally. The sources describe missing authentication for workflow execution; concrete impact depends on the tools and permissions in the workflow.

Which version fixes it?

According to NVD and GitHub, PraisonAI is patched starting with version 4.6.34.

Why is this especially risky for agents?

Agents are often deliberately connected to APIs, files or cloud permissions. An exposed trigger can therefore cause real side effects.

What should operators do first?

Upgrade, disable the legacy API, check internet exposure and review logs for the documented paths and the CVE-Detector/1.0 user agent.

Sources & Context