PraisonAI Authentication Bypass CVE-2026-44338 Exploited Less Than Four Hours After Disclosure

PraisonAI, an open-source multi-agent orchestration framework with approximately 7,100 GitHub stars, shipped a legacy Flask-based API server (src/praisonai/api_server.py) with authentication disabled by default (AUTH_ENABLED = False, AUTH_TOKEN = None). The check_auth() helper returns True whenever authentication is disabled, causing two protected routes—GET /agents and POST /chat—to fail open by design. Any internet-reachable instance allowed unauthenticated access to agent workflows. GitHub advisory GHSA-6rmh-7xcm-cpxj was published May 11, 2026, at 13:56 UTC. Sysdig observed the first targeted reconnaissance from 146.190.133.49 at 17:32 UTC (generic paths), pivoting to PraisonAI-specific endpoints (/api/agents, /api/agents/config) at 17:40 UTC—three hours and 44 minutes after disclosure. The scanner identified itself as 'CVE-Detector/1.0.'

Unauthenticated remote access to agent workflow trigger endpoints. An attacker can send GET requests to /agents to enumerate configured workflows and POST requests to /chat to execute arbitrary agent workflows without providing valid authentication tokens. The impact ceiling is determined by whatever permissions the operator granted to the agent workflow—potentially including cloud credentials, API access, or database manipulation.

PraisonAI versions 2.5.6 through 4.6.33. The flaw affects any deployment using the legacy api_server.py entrypoint and exposed to network access. Organizations running internet-facing PraisonAI instances or using the legacy API server in internal environments should assume exposure.

Upgrade to PraisonAI version 4.6.34 or later, which removes the vulnerable legacy API server and introduces stronger authentication protections. Discontinue use of the legacy api_server.py entrypoint entirely. Monitor for requests containing the 'CVE-Detector/1.0' user-agent string and suspicious traffic targeting /agents, /chat, /api/agents, and related MCP endpoints. Until upgrade is possible, implement network-layer controls to restrict access to the API server, as the bypass leaves no missing-auth signal in application logs.