PraisonAI Vulnerability Exploited Hours After Public Disclosure

A high-severity authentication bypass in PraisonAI is drawing urgent attention after security researchers observed active exploitation attempts within hours of public disclosure a stark reminder of how quickly threat actors move on newly published flaws.

The flaw, tracked as CVE-2026-44338 and documented in GitHub advisory GHSA-6rmh-7xcm-cpxj, exposes a critical weakness in PraisonAI’s legacy API server, allowing unauthenticated attackers to remotely execute AI workflows without any credentials.

PraisonAI Vulnerability

The flaw affects PraisonAI versions 2.5.6 through 4.6.33. At its core, the problem lies in a legacy Flask-based API server that ships with authentication entirely disabled by default.

The configuration hard-codes AUTH_ENABLED = False and AUTH_TOKEN = None, meaning the server’s authentication check always returns true, granting access to anyone who can reach the endpoint.

Making matters worse, the server binds to 0.0.0.0:8080, exposing it across the network if publicly reachable.

Researchers confirmed that two key endpoints respond with HTTP 200 status codes without any Authorization header present:

• GET /agents – Retrieves metadata about configured AI agents
• POST /chat – Triggers the execution of workflows defined in the agents.yaml file

The /chat The endpoint is particularly dangerous. It only requires a JSON body with a message field, but it ignores the input entirely, instead directly executing the predefined workflow via PraisonAI(agent_file="agents.yaml").run().

This means unauthenticated users can execute AI workflows remotely, enumerate internal agent configurations, drain API or model usage quotas, causing financial loss, and access sensitive outputs generated by backend workflows.

The problem extends beyond a single misconfiguration. PraisonAI’s deployment templates actively recommend binding to 0.0.0.0 With authentication disabled, normalizing insecure behavior at scale.

While a newer serve agent command does bind to localhost and supports API keys, the vulnerable legacy server remains bundled in all production releases up to version 4.6.33.

Patch and Mitigations

The vulnerability is fixed in version 4.6.34. Users should upgrade immediately. For those unable to patch right away, recommended steps include:

• Restricting API server access using firewalls
• Avoiding public internet exposure of the service
• Manually enabling authentication where possible
• Migrating to the newer, secure server agents deployment method

This incident fits a growing pattern of AI platforms shipping with insecure defaults, making them easy targets for opportunistic attackers.

The speed of exploitation here reinforces that organizations deploying AI infrastructure cannot afford to delay patching or trust default configurations out of the box.

Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google