al-ice.ai

PraisonAI’s 27-CVE Batch Breaks Agent Approval, MCP, Sandbox, and Authentication Boundaries

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Twenty-seven PraisonAI CVE records published on September 14 and 15 expose a security failure larger than any single endpoint: controls labeled authentication, approval, sandboxing, network isolation, and workspace containment repeatedly did not govern the operation they appeared to protect.

Twelve of the records are critical, twelve are high severity, and three are medium severity under their CNA-provided CVSS 3.1 ratings. The affected surfaces span PraisonAI’s Python framework, praisonaiagents, praisonai-platform, and the separate npm package. Consequences include unauthenticated agent and tool invocation, command execution, sandbox escape, forged identities and webhooks, arbitrary file access, SSRF, and an approval callback that ran only after a tool had already executed.

The CVE publication is new, but the underlying vendor advisories are not zero-days disclosed this week. GitHub records show the relevant advisories were published in June and fixes were released before the September CVE assignments. The records do not establish exploitation in the wild. Exposure depends on which PraisonAI package and feature is deployed, whether its service is reachable, which tools and credentials are registered, and whether untrusted users or content can influence agent inputs.

Unauthenticated control planes reached tools, agents, and commands

The most direct paths turn network reachability into agent authority. CVE-2026-57123 covers an MCP SSE server that bound to all interfaces without authentication or origin validation, allowing a reachable client to list and invoke registered tools. CVE-2026-57139 describes the equivalent failure in the npm package’s MCP HTTP server: requests were forwarded to tools/list, tools/call, resource, and prompt handlers without an authorization gate.

CVE-2026-57124 was more explicit. A default UI endpoint accepted caller-controlled MCP command and argument values and passed them to a local stdio client, while the UI listened on 0.0.0.0. A reachable unauthenticated caller could therefore start a process as the service account even if the subsequent MCP handshake failed. This is the same dangerous ordering seen in the recent Flowise Custom MCP flaws: protocol failure happens after process creation and cannot serve as an execution control.

CVE-2026-57125 chained an unauthenticated Jobs API with attacker-supplied agent YAML and an approval field that could pre-authorize execute_command. CVE-2026-57131 separately covers the Jobs API’s missing authentication and cross-job access. CVE-2026-57127 covers recipe-server authentication middleware that silently forwarded requests when the selected API-key or JWT mode lacked its corresponding secret.

The agent endpoints repeated the pattern. CVE-2026-57140 exposed npm AgentOS agent names, roles, instruction prefixes, and chat invocation without authentication. CVE-2026-57132 allowed a Python call-server configuration value to disable authentication for agent invocation. These are not merely chat-data issues: an invoked agent may carry tool access, memory, external API credentials, and workflow state.

The approval callback observed a side effect it was supposed to prevent

CVE-2026-57137 is the most instructive flaw in the batch. The npm agent loop passed executable tools into the AI SDK’s generation function before calling the application’s onToolCall approval callback. The SDK could execute a tool handler during generation; only afterward would a callback returning false record that the tool had been rejected.

That is a temporal authorization bug. The application exposed an approval interface, but the control was attached to the audit trail rather than the action. Operators should not assume a “denied” event means that no filesystem, network, database, or external-service side effect occurred. Logs around rejected calls need to be correlated with the underlying tool’s own records.

The repair has to move authorization in front of capability delivery: the model should receive a non-executing description or a gated proxy, and the real handler should become callable only after the exact tool name and arguments are approved. A post-execution callback cannot be upgraded into a security boundary through better prompting.

Three different sandboxes relied on blocklists or conventions

CVE-2026-57138 and CVE-2026-57141 cover two ways to escape the npm codeMode JavaScript sandbox. It used new Function(), a with(sandbox) scope, shadowed globals, and source-text filtering. JavaScript constructor chains or dynamically assembled names could recover the real global object and reach host filesystem and subprocess APIs. One record carries a 9.9 score; the other is rated 9.8.

CVE-2026-57136 shows the same design problem in a command sandbox. Validation checked the first executable against an allowlist, then passed the complete string to sh -c. Shell chaining could append a second command outside the allowlist. CVE-2026-57133 affected a related utility wrapper that validated the first whitespace-delimited token before sending the original string to child_process.exec().

CVE-2026-57135 called a mode network-isolated even though it only injected invalid HTTP proxy environment variables. Programs that ignored those variables could open sockets directly. CVE-2026-57120 covers a Python execution sandbox where C-level str.format attribute resolution bypassed the wrapper around blocked attributes and exposed a high-impact read primitive.

The common failure is treating language syntax and cooperative client behavior as containment. A process that must be isolated needs an operating-system boundary: a separate low-privilege identity, an explicit filesystem view, syscall and process restrictions, and deny-by-default egress. A source blocklist, shell-token check, shadowed JavaScript property, or poisoned proxy setting is not equivalent.

Identity and input channels failed open

CVE-2026-57147 and CVE-2026-57148 cover a public default JWT secret in praisonai-platform and an incomplete first fix. When both the signing secret and environment designation were unset, the platform could boot in development mode with dev-secret-change-me. A remote attacker could mint an HS256 token for an attacker-chosen identity. The later record exists because the first production guard still defaulted open; operators should use praisonai-platform 0.1.6 or later rather than trying to reason about the intermediate state.

CVE-2026-57122 covers WhatsApp and Linear webhook handlers that verified signatures only when their secret existed, otherwise accepting unsigned events. That converts missing configuration into trusted agent input. CVE-2026-57130 allowed LLM-controlled values to alter quoted IMAP search criteria when email tools were enabled. CVE-2026-57134 allowed MCP Basic and OAuth policies to accept any non-empty authorization header without invoking the configured credential validator.

All three cases violate a useful agent rule: an absent verifier must disable the input channel, not authenticate it. Webhooks, mailbox operations, MCP requests, and agent invocations carry different protocols, but they all cross from external data into privileged computation.

Workspace and network boundaries also leaked

The remaining records show why a patched listener is not enough:

  • CVE-2026-57119 let the unauthenticated Jobs API read an absolute or traversing agent_file path.
  • CVE-2026-57129 let @file: mentions fall back to an unconstrained path outside the workspace.
  • CVE-2026-57145 let the LLM-controlled multiedit path read or overwrite files without traversal, symlink, or workspace checks.
  • CVE-2026-57115 validated only the first web-scraping URL and followed redirects to private or metadata addresses.
  • CVE-2026-57126 checked literal IP forms but did not resolve hostnames before connecting, allowing names that resolve to internal addresses to bypass the SSRF policy.
  • CVE-2026-57112 exposed registered MCP tools through a legacy SSE transport lacking default Host, Origin, and authentication enforcement.
  • CVE-2026-57128 exposed an SSE publish endpoint that did not consult the configured authentication token.

Several exploit chains need more than one condition—reachable service, enabled tool, prompt influence, user privilege, browser interaction, or a useful internal target. That does not make the defects theoretical. It means defenders must map a CVE to the deployed topology and capability set rather than multiplying a base score by an inventory count.

Versioning is a four-track problem

The package name alone is not enough to verify remediation. The 27 records span four independently versioned distributions. Individual fixes landed across several June releases; a conservative floor that clears this entire September CVE batch is:

  • Python praisonai: 4.6.62 or later.
  • Python praisonaiagents: 1.6.59 or later.
  • Python praisonai-platform: 0.1.6 or later.
  • npm praisonai: 1.7.2 or later.

At publication, the public registries report newer versions—Python praisonai 4.7.8, praisonaiagents 1.7.6, praisonai-platform 0.1.9, and npm praisonai 1.7.4. Upgrade to a currently supported release rather than pinning exactly to the minimum. Verify the package manager, runtime import, deployed container, and long-lived worker process; a changed lockfile does not prove the old service stopped.

What defenders should do now

  • Inventory by distribution and feature. Record the installed versions of all four packages and identify Jobs, AgentOS, MCP SSE/HTTP, recipe serving, platform API, webhooks, email tools, code mode, shell tools, file mentions, multiedit, and web crawling.
  • Remove direct network reachability. Bind development control servers to loopback or private service networks, require authenticated gateways, and test exposure from adjacent containers, browsers, developer LANs, cloud subnets, and public ingress.
  • Rotate the platform JWT secret. Upgrading stops the published default-secret behavior, but tokens minted with a known key remain forgeable until the effective signing secret changes and old tokens are invalidated.
  • Treat rejected tools as potentially executed. For deployments affected by CVE-2026-57137, inspect tool-specific logs and downstream systems around rejected calls. Do not use the rejection record as proof of prevention.
  • Disable code and shell execution where possible. Move required execution into disposable, non-root workers with narrow mounts, no inherited secrets, constrained resources, and deny-by-default egress. Do not restore broad interpreters through allowlists.
  • Make missing trust configuration fatal. Startup should fail when authentication, webhook verification, or signing secrets are selected but absent. Add deployment checks that exercise unauthorized requests rather than only checking environment-variable presence.
  • Constrain file and network tools independently. Enforce canonical workspace paths after symlink resolution; revalidate every redirect and resolved address at connection time; block cloud metadata and management networks at the workload boundary.
  • Hunt for consequence, not only exploit strings. Review child processes, modified files, package installs, unexpected agent jobs, MCP calls, forged webhook events, mailbox searches, outbound DNS and HTTP traffic, internal-service access, platform identities, and token issuance.

This batch reinforces the lesson from the Cua and AutoAgent control-server CVEs: agent security fails when a control-plane label substitutes for an enforced boundary. “Sandbox,” “approval,” “authenticated,” “workspace,” and “network isolated” are claims that must be tested at the side-effect point. If the command has already run, the socket can still connect, or a missing secret opens the route, the control exists only in the interface.

Sources: