CVE-2026-61427: PraisonAI: MCP server auth bypass by default
HIGH PoC AVAILABLE CISA: TRACK*PraisonAI's MCP HTTP-stream server ships with authentication effectively off: the CLI's --api-key defaults to None, and Bearer/Authorization checks only trigger if an operator explicitly configures a key, so an unauthenticated client can initialize a session, enumerate every registered tool via tools/list, and invoke them via tools/call with arguments the dispatcher never validates against the advertised inputSchema. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, and the server defaults to binding on 127.0.0.1 — so real exposure depends entirely on whether an operator ran it with --host 0.0.0.0 for a container or shared-network deployment, a common pattern for agent tooling. Blast radius looks narrow on paper (1 tracked downstream dependent), but the package's 0/100 internal risk score and 138 other recorded CVEs signal a chronically weak security posture worth flagging if PraisonAI is anywhere in your agent stack. Patch to PraisonAI 4.6.78 or later now, and until then treat any non-loopback deployment lacking --api-key as a critical misconfiguration. Detection: audit for praisonai mcp serve processes bound to non-loopback interfaces and firewall/segment any exposed MCP HTTP-stream port that isn't enforcing Authorization: Bearer.
What is the risk?
CVSS 7.3 (High) with network attack vector, low complexity, no privileges or user interaction required makes this trivially exploitable once a target is network-reachable — the sole gating factor is that the server defaults to 127.0.0.1, so exploitability in practice depends on operator misconfiguration (--host 0.0.0.0). No active exploitation signals exist: not in CISA KEV, no EPSS score published, no public PoC or Nuclei template. This keeps current real-world risk moderate rather than critical, but the combination of 'secure by default only if you remember a flag' plus AI agent frameworks increasingly being deployed in shared/cloud environments makes misconfiguration plausible and worth proactive scanning rather than waiting for exploitation evidence.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| PraisonAI | pip | — | No patch |
Do you use PraisonAI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Upgrade to PraisonAI 4.6.78 or later immediately. 2) Until patched, always launch with an explicit --api-key when using --transport http-stream, and never combine an unset --api-key with --host 0.0.0.0. 3) Keep MCP servers bound to 127.0.0.1 unless remote access is a hard requirement; if remote access is needed, place the endpoint behind a VPN, reverse proxy with its own auth, or network ACL/firewall rule restricting source IPs. 4) Audit current deployments for praisonai mcp serve processes and check their bind address and API-key configuration. 5) Even after patching, treat tool handler input validation as a defense-in-depth gap — review custom tools for assumptions that arguments always match their declared inputSchema. 6) Detection: monitor for MCP session-initialize and tools/list calls from unexpected source IPs or without Authorization headers in server logs.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-61427?
PraisonAI's MCP HTTP-stream server ships with authentication effectively off: the CLI's --api-key defaults to None, and Bearer/Authorization checks only trigger if an operator explicitly configures a key, so an unauthenticated client can initialize a session, enumerate every registered tool via tools/list, and invoke them via tools/call with arguments the dispatcher never validates against the advertised inputSchema. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, and the server defaults to binding on 127.0.0.1 — so real exposure depends entirely on whether an operator ran it with --host 0.0.0.0 for a container or shared-network deployment, a common pattern for agent tooling. Blast radius looks narrow on paper (1 tracked downstream dependent), but the package's 0/100 internal risk score and 138 other recorded CVEs signal a chronically weak security posture worth flagging if PraisonAI is anywhere in your agent stack. Patch to PraisonAI 4.6.78 or later now, and until then treat any non-loopback deployment lacking --api-key as a critical misconfiguration. Detection: audit for praisonai mcp serve processes bound to non-loopback interfaces and firewall/segment any exposed MCP HTTP-stream port that isn't enforcing Authorization: Bearer.
Is CVE-2026-61427 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-61427, increasing the risk of exploitation.
How to fix CVE-2026-61427?
1) Upgrade to PraisonAI 4.6.78 or later immediately. 2) Until patched, always launch with an explicit --api-key when using --transport http-stream, and never combine an unset --api-key with --host 0.0.0.0. 3) Keep MCP servers bound to 127.0.0.1 unless remote access is a hard requirement; if remote access is needed, place the endpoint behind a VPN, reverse proxy with its own auth, or network ACL/firewall rule restricting source IPs. 4) Audit current deployments for praisonai mcp serve processes and check their bind address and API-key configuration. 5) Even after patching, treat tool handler input validation as a defense-in-depth gap — review custom tools for assumptions that arguments always match their declared inputSchema. 6) Detection: monitor for MCP session-initialize and tools/list calls from unexpected source IPs or without Authorization headers in server logs.
What systems are affected by CVE-2026-61427?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool-calling agents.
What is the CVSS score for CVE-2026-61427?
CVE-2026-61427 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.39%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0053 AI Agent Tool Invocation AML.T0084.001 Tool Definitions Compliance Controls Affected
What are the technical details?
Original Advisory
PraisonAI before 4.6.78 exposes the MCP HTTP-stream transport without authentication by default: the CLI --api-key option defaults to None, and the server only enforces Authorization/Bearer checks when an API key is configured. When an operator runs 'praisonai mcp serve --transport http-stream' without an API key, an unauthenticated client (no Authorization header, and no Origin header, which is also permitted) can initialize a session, enumerate the available tools (tools/list), and invoke tools (tools/call). Additionally, the dispatcher forwards tool-call arguments to handlers without validating them against the advertised inputSchema. The server binds to 127.0.0.1 by default, so remote exploitation requires the operator to bind to a network-accessible address (e.g., --host 0.0.0.0).
Exploitation Scenario
An operator containerizes a PraisonAI agent and runs 'praisonai mcp serve --transport http-stream --host 0.0.0.0' to make it reachable from other services in the cluster, without setting --api-key. An adversary who can reach that port — via internal network access, a misconfigured cloud security group, or simple internet scanning — sends an HTTP request to initialize an MCP session with no Authorization or Origin header, both of which the server accepts. The adversary then calls tools/list to see exactly what capabilities the agent exposes (e.g., file access, code execution, API integrations), and issues tools/call requests to invoke those tools directly, supplying arguments that don't need to conform to the tool's declared schema. Depending on what tools are registered, this can escalate from information disclosure (enumerating agent capabilities and data) to abuse of write/execute-capable tools for data exfiltration or unauthorized actions on connected systems.
Weaknesses (CWE)
CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
- [Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
- [Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L References
Timeline
Related Vulnerabilities
CVE-2026-48168 10.0 PraisonAI: shell injection in Claude Action enables RCE
Same package: praisonai CVE-2026-61447 10.0 PraisonAI: RCE via unsandboxed LLM code execution
Same package: praisonai CVE-2026-61445 9.9 PraisonAI: AICoder root RCE via unsanitized tool calls
Same package: praisonai GHSA-vmmj-pfw7-fjwp 9.9 praisonai: sandbox escape gives RCE via codeMode tool
Same package: praisonai CVE-2026-47392 9.9 praisonaiagents: RCE via Python sandbox bypass
Same package: praisonai