PraisonAI’s legacy Flask server shipped with authentication disabled by default for more than two years, exposing the /agents and /chat endpoints to any reachable IP address. The configuration, present in src/praisonai/api_server.py across versions 2.5.6 through 4.6.33, was assigned CVE-2026-44338 with a CVSS score of 7.3. An internet-wide scanner was probing the exact flaw 3 hours and 44 minutes after the GitHub advisory dropped on May 11.
What Shipped: The Legacy api_server.py Auth Defaults
The vulnerable entrypoint is src/praisonai/api_server.py, which hard-codes AUTH_ENABLED = False and AUTH_TOKEN = None according to Sysdig’s analysis. The check_auth() helper returns True whenever authentication is disabled, so the /agents and /chat routes fail open by design. The server binds to 0.0.0.0:8080, so the failure mode is not a localhost convenience that someone forgot to lock down; it is a public listener with the lock removed [Updated June 2026]. A GET request to /agents returns configured agent metadata including the agent_file path and agent list, while POST /chat executes the agents.yaml workflow regardless of the submitted message body (The Hacker News).
One detail constrains the blast radius and is worth stating precisely: POST /chat accepts any JSON body with a message key, then runs PraisonAI(agent_file="agents.yaml").run() and ignores the submitted value [Updated June 2026]. The caller cannot inject a new prompt or swap the agent definition through this route. What they get is the ability to trigger the operator’s pre-configured workflow on demand, repeatedly, plus the metadata to know it is there. That is a real limit on direct prompt injection, and it is also why the impact is entirely downstream of what the workflow already does.
The flaw was discovered by Shmulik Cohen and disclosed via GHSA-6rmh-7xcm-cpxj. NIST classifies it under CWE-306 (Missing Authentication for Critical Function), CWE-668 (Exposure of Resource to Wrong Sphere), and CWE-1188 (Initialization with Insecure Default). Versions from 2.5.6 through 4.6.33 are affected. The published CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L (GitHub advisory): network-reachable, no privileges, no interaction, with low confidentiality, integrity, and availability impact rather than the high marks an arbitrary-execution bug would carry [Updated June 2026].
The Timeline: 3h44m From Advisory to CVE-Detector/1.0
The GitHub Security Advisory was published at 13:56:16 UTC on May 11, 2026. The first targeted request arrived at 17:40:55 UTC from IP address 146.190.133.49 on DigitalOcean’s AS14061, carrying the User-Agent: CVE-Detector/1.0, according to Sysdig’s honeypot telemetry. The elapsed time was exactly 3 hours, 44 minutes, and 39 seconds.
At the time of disclosure, PraisonAI held roughly 7,100 GitHub stars. That places it well outside the top tier of AI agent frameworks, yet the scan latency was indistinguishable from what you would expect for a widely deployed Apache or Nginx module.
What the Scanner Did (And Didn’t Do)
The CVE-Detector/1.0 probe ran in two passes roughly eight minutes apart. The first pass swept generic disclosure paths such as /.env and /admin; the second targeted AI-agent-specific surfaces including /agents, /api/agents, /api/tasks, and MCP endpoints. Each pass pushed approximately 70 requests in about 50 seconds (Sysdig).
Only /agents was probed. Sysdig observed no POST /chat requests, which suggests the activity was reconnaissance and validation, not immediate weaponized exploitation. The distinction matters: the auth bypass itself exposes metadata and workflow triggering, but actual impact depends on what the operator’s agents.yaml is configured to do.
As of late June 2026, public reporting still describes scanning and endpoint validation rather than confirmed compromise, and the CVE has not appeared in CISA’s Known Exploited Vulnerabilities catalog [Updated June 2026]. That is consistent with a metadata-and-trigger bypass whose payoff is target-dependent: a scanner can confirm the door is open cheaply, but walking through it only pays off against a victim whose workflow does something worth triggering. Absence from the KEV list is not absence of risk; it reflects the bar CISA sets for cataloguing, not the speed at which the endpoint was found.
The 4.6.34 Patch: What Changed
Version 4.6.34 patches the flaw by reversing the authentication defaults in the legacy server. Operators who upgrade will no longer stand up an open /agents endpoint simply by launching the Flask entrypoint. The fix closes the immediate hole, but it does not uninstall the legacy server from existing container images or deployments already bound to 0.0.0.0.
The advisory also points operators at the newer surface rather than just a patched version. The serve agents command, the supported way to expose agents in current PraisonAI, binds to 127.0.0.1 by default and accepts an --api-key flag for token auth [Updated June 2026]. That is the right model: localhost-only unless you opt into exposure, and authenticated when you do. The legacy api_server.py predates that convention, which is how it accumulated two and a half years of shipping with the gate open. Upgrading the package without switching off the legacy entrypoint leaves you on a server that was insecure by design and is now merely insecure by configuration, since nothing stops an operator from setting AUTH_ENABLED=False again. Treat the version bump as necessary, not sufficient.
The Bigger Picture: AI Agent Frameworks Now on the Rapid-Exploitation Treadmill
Sysdig’s researchers were explicit about the trend: “Adversary tooling has scaled to the entire AI and agent ecosystem, no matter the size, and not just the household names, and the operating assumption for any project that ships an unauthenticated default must be that the window between disclosure and active exploitation is measured in single-digit hours.”
That is a new operational tempo for AI agent stacks. The PraisonAI case confirms that a framework with a four-digit star count is now swept as quickly as routine infrastructure software. For security teams, the implication is that “AI agent framework” is becoming shorthand for “unauthenticated REST surface bound to 0.0.0.0”, and that surface is being catalogued by scanners in near-real time.
The Insecure-Default Pattern in Agent Frameworks
PraisonAI is not an outlier. It is the latest data point in a recurring failure class: agent frameworks that ship with a dangerous setting turned on, because the default was chosen for a single developer running things on their own laptop and never revisited when the same code started landing in 0.0.0.0-bound containers.
The shapes differ, but the root cause repeats. PraisonAI ships auth off. InstructLab’s CVE-2026-6859 hard-coded trust_remote_code=True, so loading a model from Hugging Face would execute attacker-supplied Python without a prompt. LMDeploy’s CVE-2026-33626 shipped a vision endpoint that would fetch arbitrary URLs, an SSRF that was exploited within twelve hours of its advisory. In each case the insecure behavior was the path of least resistance for the maintainer and the path of least resistance for an attacker at the same time.
What links them is not a shared bug but a shared assumption: that the framework runs in a trusted, single-tenant environment. That assumption was true in a notebook and false the moment the project added a serve command and a Dockerfile. The March/April MCP CVE wave made the same point about local-host trust at the protocol layer: code that assumes localhost is safe inherits every flaw of the network it actually listens on. CWE-1188, the “insecure default initialization” tag NIST hung on PraisonAI, is the formal name for it.
The practical takeaway for anyone integrating an agent framework: read the network defaults before the README. Check what the serve entrypoint binds to, whether auth is on, and whether a model load can run code. Those three questions catch most of the class, and none of them are answered by the star count on the repo.
What Ops Teams Should Hunt For
If you run PraisonAI or maintain images that depend on it, the hunt list is short and concrete. Check whether any container still launches src/praisonai/api_server.py directly. Verify that AUTH_ENABLED is not explicitly set to False in environment variables or config maps. Inspect network policies for unexpected exposure on the Flask port. And inventory your tags: images built before 4.6.34 will still contain the old defaults even if the upstream package has been patched.
Frequently Asked Questions
How does PraisonAI’s 3h44m scan time compare to other AI framework CVEs?
Sysdig places PraisonAI alongside LMDeploy (~12 hours post-disclosure), Marimo (~9 hours), and Flowise, all swept by automated scanners within hours of their respective advisories. PraisonAI’s window is the fastest recorded for a sub-10k-star framework, but the pattern shows star count no longer buys delay; only the existence of a public GHSA advisory matters.
What’s the fastest mitigation if upgrading to 4.6.34 isn’t immediately possible?
Place PraisonAI behind an authenticating reverse proxy or restrict the Flask port to internal-only network segments. Setting AUTH_ENABLED=True and AUTH_TOKEN to a strong value via environment variables also closes the gap without a version bump, but only if no Docker Compose file or Kubernetes ConfigMap resets them.
Why is the CVSS score 7.3 and not Critical given sub-4-hour scanning?
The 7.3 reflects network accessibility with no auth or user interaction required, but the impact subscores are capped because the bypass alone exposes agent metadata and workflow triggering, not arbitrary execution. Remote code execution would require the operator’s agents.yaml to grant the agent shell access, file I/O, or a code interpreter, which is a victim-configured variable, not a vulnerability property.
Does the CVE-Detector/1.0 two-pass pattern change how AI projects should time their disclosures?
The scanner’s generic-first, AI-specific-second pass structure indicates it cross-references GitHub Advisory publications against a catalogue of known AI framework API layouts in near-real-time. Projects that publish unauthenticated-endpoint advisories should treat the GHSA timestamp as the start of their exposure window, not a subsequent blog post or social announcement that may follow days later.
