PraisonAI CVE-2026-44338 Targeted Within Hours of Public Disclosure

A PraisonAI vulnerability tracked as CVE-2026-44338 was targeted within hours of public disclosure, showing how quickly attackers and scanners now move against exposed AI agent infrastructure.

The flaw affects PraisonAI versions from 2.5.6 through 4.6.33 and has been fixed in version 4.6.34. It comes from a legacy Flask API server that shipped with authentication disabled by default, allowing reachable users to access protected functions without a token.

Sysdig researchers observed scanning activity against the vulnerable endpoint 3 hours and 44 minutes after the advisory became public on May 11, 2026. The request targeted `/agents` without an Authorization header and returned a successful response, confirming the authentication bypass on exposed systems.

What CVE-2026-44338 allows

PraisonAI is an open-source framework for building and running multi-agent AI systems. In vulnerable versions, the legacy API server can expose agent workflows if operators run it in a reachable environment.

The issue affects the legacy API server path, not every possible PraisonAI deployment. When that server is reachable, an unauthenticated attacker can query the configured agent file through `/agents` and trigger the local `agents.yaml` workflow through `/chat`.

The impact depends on what the victim’s workflow can do. A harmless test workflow may reveal little, but a production workflow connected to paid model APIs, internal tools, business data, or automation pipelines can create much higher risk.

Vulnerability detail	Information
CVE ID	CVE-2026-44338
GitHub advisory	GHSA-6rmh-7xcm-cpxj
Affected package	PraisonAI for pip
Affected versions	2.5.6 through 4.6.33
Fixed version	4.6.34
Severity	High, CVSS 7.3

Why the legacy API server was exposed

The root cause is an insecure default configuration in the legacy Flask API server. The server shipped with authentication disabled, meaning the authorization check could fail open when the server was reachable.

The GitHub advisory says any reachable caller can invoke protected functionality without a token. That includes unauthenticated enumeration of the configured agent file through `/agents` and unauthenticated triggering of the configured workflow through `/chat`.

The flaw also creates availability and cost risks. Attackers may repeatedly trigger workflows, consume paid model API quota, cause downstream actions, or retrieve whatever output the configured PraisonAI workflow returns.

Scanners moved fast after disclosure

Sysdig said the advisory became public at 13:56 UTC on May 11, 2026. The first targeted request against the vulnerable PraisonAI surface landed at 17:40 UTC the same day.

The scanner identified itself with the user agent `CVE-Detector/1.0`. It first performed broader reconnaissance, then shifted to AI-agent surfaces, including PraisonAI-specific paths.

The most relevant request was a `GET /agents` call with no Authorization header. Sysdig said this returned a successful response containing the configured agent file and agent data. Researchers did not observe a matching `POST /chat` request during those scan passes, so the activity looked like exploit validation rather than full workflow execution.

• The advisory became public on May 11, 2026, at 13:56 UTC.
• Generic reconnaissance started later the same day.
• The first PraisonAI-specific request appeared at 17:40 UTC.
• The scanner used the user agent `CVE-Detector/1.0`.
• The observed exploit check targeted `/agents` without authorization.

Why AI agent frameworks are attractive targets

AI agent frameworks often connect language models to files, tools, APIs, databases, and workflow automation. That makes them useful for developers, but it also increases the damage when an exposed agent server lacks authentication.

An attacker does not need direct access to the underlying model provider account to cause harm. If the vulnerable server can trigger workflows, the attacker may force the victim’s environment to spend API credits, run internal automation, or expose workflow output.

This type of issue also creates a new operational risk for teams experimenting with AI agents. A developer may expose a local test server to a cloud host or public network without realizing that the default API path lacks authentication.

The flaw is not arbitrary prompt injection by itself

The GitHub advisory makes an important distinction. CVE-2026-44338 does not automatically mean attackers can inject arbitrary prompts into every PraisonAI workflow.

The current `/chat` handler runs the configured workflow and ignores the submitted message value. That means the attacker’s power depends on what the existing `agents.yaml` workflow already does.

Still, the authentication bypass is unconditional in the legacy server. If the server is exposed, the attacker does not need credentials to enumerate agents or trigger the configured workflow.

Possible impact	Why it matters
Agent enumeration	Attackers can learn what workflows and agents are configured.
Workflow triggering	Attackers can run the local `agents.yaml` workflow without a token.
API quota abuse	Repeated requests can consume paid model usage.
Data exposure	Attackers may receive output returned by the configured workflow.
Operational side effects	Risk depends on what tools, files, and services the workflow can access.

How to fix CVE-2026-44338

Developers using PraisonAI should upgrade to version 4.6.34 or later. Teams should also audit existing deployments to confirm they are not running the legacy API server with authentication disabled on a reachable interface.

Sysdig recommends moving away from the legacy `api_server.py` entry point. The newer `praisonai serve agents` command is safer by default because it binds to `127.0.0.1` unless a different host is specified and supports an `–api-key` option.

Security teams should also review sample deployment configurations. Any deployment that binds to `0.0.0.0` and keeps authentication disabled can expose the service to other systems on the network or the public internet.

• Upgrade PraisonAI to version 4.6.34 or later.
• Stop using the legacy API server entry point where possible.
• Use `praisonai serve agents` with an API key for server deployments.
• Bind services to `127.0.0.1` unless remote access is required.
• Avoid exposing agent APIs directly to the internet.
• Check model provider billing for unusual usage spikes.
• Rotate credentials referenced by `agents.yaml` if exposure is suspected.
• Review logs for unauthenticated `/agents` or `/chat` requests.

What defenders should monitor

Organizations should hunt for requests to `/agents`, `/chat`, `/docs`, `/api/agents`, and similar PraisonAI-related paths from unknown sources. Requests without Authorization headers deserve closer review.

Admins should also check for the `CVE-Detector/1.0` user agent, although attackers can easily change that value. Network-level telemetry, reverse proxy logs, container logs, and application logs can help identify attempted exploitation.

The bigger lesson is that disclosure-to-exploitation windows are getting shorter. AI agent tools that ship with insecure defaults can attract attention within hours, not days or weeks.

FAQ