GHSA-hc5v-gxvj-58wh CVE-2026-61427 PYSEC-2026-4257

PraisonAI: MCP HTTP-stream transport is unauthenticated by default, exposing tool enumeration and an unvalidated tool-call surface

Medium PyPI

Severity: 6.9 / 10; Medium · CVSS 4.0
Exploit chance (EPSS): 0.43%; Chance of exploitation in the next 30 days. Higher than 36.96% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-20 Improper Input Validation; CWE-306 Missing Authentication for Critical Function; CWE-862 Missing Authorization
Fix: 4.6.78; Upgrade praisonai to this version or later

Description

Summary

PraisonAI's MCP HTTP-stream server authenticates requests only when an API key is configured; the CLI defaults --api-key to None, so praisonai mcp serve --transport http-stream exposes the full MCP surface unauthenticated. A request with no Authorization (and no Origin) can initialize and tools/list (~50 tools), and the dispatcher forwards tool-call arguments to handlers without validating them against the advertised inputSchema. Runtime-confirmed for unauthenticated initialize/tools/list and the dispatcher schema-bypass. This is not an RCE/file-read in 4.6.63 — workflow.run/workflow.run_file are runtime-refuted (adapter regression). Severity Medium–High.

Details

Affected component

Package: praisonai 4.6.63. Files: src/praisonai/praisonai/mcp_server/transports/http_stream.py, mcp_server/cli.py, mcp_server/server.py (dispatcher).

Vulnerable code / root cause

Path: src/praisonai/praisonai/mcp_server/transports/http_stream.py

Function: mcp_post / _validate_origin

Snippet:

if self.api_key:                       # auth applied ONLY when api_key is set
    auth_header = request.headers.get("Authorization", "")
    if not auth_header.startswith("Bearer ") or auth_header[7:] != self.api_key:
        return JSONResponse({"error": "Unauthorized"}, status_code=401)
# _validate_origin: returns True when the Origin header is absent

Issue: with api_key=None, no auth check runs; a missing Origin header is allowed, so non-browser clients (curl/Burp) are not blocked.

Path: src/praisonai/praisonai/mcp_server/cli.py

Function: cmd_serve (argparse)

Snippet:

parser.add_argument("--api-key", default=None)   # unauthenticated by default

Path: src/praisonai/praisonai/mcp_server/server.py

Function: _handle_tools_call

Snippet:

result = await tool.handler(**arguments)   # arguments forwarded without inputSchema validation

Issue: attacker-controlled arguments are passed straight to the handler; the dispatcher does not validate them against the tool's advertised inputSchema. The only thing rejecting undeclared keys is the handler's own Python signature.

Attack flow

Operator runs praisonai mcp serve --transport http-stream (no --api-key).
Attacker (no auth, no Origin) sends initialize → session; tools/list → enumerates ~50 tools; tools/call → arguments pass through unvalidated.

Why existing protection is bypassed

Auth is opt-in (only added when an api key is set); missing Origin is allowed; the dispatcher does not enforce inputSchema.

Security boundary

Unauthenticated access to the MCP tool surface. Default bind 127.0.0.1 (any local process / multi-user host; remote only if --host 0.0.0.0).

Scope limits (do not overclaim)

praisonai.workflow.run / workflow.run_file are runtime-refuted in 4.6.63: the adapter calls AgentsGenerator(...) missing the required config_list argument → errors before any execution/file open. Several other tool adapters also error at runtime. No unauthenticated RCE/arbitrary-file-open via these tools at HEAD.
MCP knowledge.add file read is broken (see FT-01_Knowledge_FileRead_Negative_Report.md).

Proof of Concept

Environment

Real MCP HTTP-stream server (api_key=None) in a local runtime (127.0.0.1:18090). Runnable assets: PraisonAI-Runtime-Repro\runtime-files\ (docker-compose.mcp.yml). MCP requests use Accept: application/json + header Mcp-Session-Id.

Steps to reproduce

MCP-Initialize: POST /mcp initialize (no Authorization) → 200 + mcp-session-id.
MCP-Tools-List-NoAuth: POST /mcp tools/list with that session id → 200 + ~50 tools.
MCP-Schema-Bypass: tools/call with an undeclared extra argument (__undeclared_evil_param__).

Expected result

The transport requires authentication; the dispatcher validates arguments against inputSchema.

Actual result

initialize/tools/list succeed with no auth and no Origin header.
The undeclared argument reaches the handler (got an unexpected keyword argument '__undeclared_evil_param__'), proving no schema validation at the dispatcher.

Screenshots

Screenshots

Unauthenticated MCP initialize

A POST request to /mcp with method initialize succeeds without an Authorization header. The server returns HTTP 200 OK, exposes MCP capabilities, and issues an mcp-session-id to the unauthenticated client.

Unauthenticated MCP tools/list

After initialization, the same unauthenticated MCP session can call tools/list using only the issued Mcp-Session-Id. The server returns HTTP 200 OK and exposes tool names, schemas, and annotations.

MCP tool-call schema bypass

The unauthenticated MCP client calls tools/call with an extra argument not declared in the tool schema. Instead of rejecting the schema-violating input at the dispatcher layer, the unexpected parameter reaches the Python handler and causes an unexpected keyword argument error. This confirms incomplete input-schema enforcement for tool calls.

Impact

Unauthenticated tool enumeration and tool-call surface; LLM-key/cost abuse and data access via whichever tools function (impact currently limited by several broken adapters and the default loopback bind). No confirmed unauthenticated RCE/file-read in 4.6.63.

Affected versions

PyPI

Package	Vulnerable	Fixed in
praisonai	`< 4.6.78`	`4.6.78`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

praisonai PyPI → `4.6.78`

pip

pip install --upgrade "praisonai>=4.6.78"

poetry

poetry add "praisonai>=4.6.78"

uv

uv add "praisonai>=4.6.78"

Severity breakdown

CVSS 4.0 6.9

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector: Network
Attack complexity: Low
Attack requirements: None
Privileges required: None
User interaction: None
Confidentiality (vulnerable system): Low
Integrity (vulnerable system): Low
Availability (vulnerable system): Low
Confidentiality (subsequent systems): None
Integrity (subsequent systems): None
Availability (subsequent systems): None
Exploit maturity: Not defined
Scope: X

CVSS 3.1 7.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: Low
Integrity: Low
Availability: Low

Weakness

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.

How to prevent it

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).
Architecture and Design, Implementation: Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Implementation: When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
Implementation: Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
Implementation: Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
Implementation: When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

CWE-306: Missing Authentication for Critical Function

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

How to prevent it

Architecture and Design: Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Architecture and Design: Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks. In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Implementation, System Configuration, Operation: When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CWE-862: Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

How to prevent it

Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Advisories

Packages

Timeline

Jul 15, 2026 Published
Oct 24, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-26mh-57q7-jfvr PraisonAI vulnerable to Remote Code Execution via Broken AST Sandbox	High	Also affects praisonai
GHSA-6g6r-q6gw-w8fg PraisonAI has a Browser Server WebSocket origin validation bypass via unanchored regex (patch bypass of CVE-2026-40289 / GHSA-8x8f-54wf-vv92)	Critical	Also affects praisonai
GHSA-pvph-5j39-v8qc PraisonAI: Origin-validation bypass (startswith prefix match) enables unauthenticated cross-site request forgery against the PraisonAI MCP HTTP server	High	Also affects praisonai
GHSA-gfq8-hmph-9gjv PraisonAI: Authentication fail-open in Recipe server allows unauthenticated access when API key or JWT auth is configured without a secret	High	Also affects praisonai
GHSA-2jgc-f764-c5r2 PraisonAI: [Auth Bypass] PraisonAI async Jobs API (`/api/v1/runs`) has no authentication — unauthenticated job execution, result theft, cancel and delete	High	Also affects praisonai
GHSA-pvxx-r596-f5qj PraisonAI: `--api-key` flag on `praisonai serve` is not properly enforced	High	Also affects praisonai
GHSA-hmfx-4v44-9qw9 PraisonAI vulnerable to Server-Side Request Forgery via DNS rebinding bypass in webhook_url validation	Medium	Also affects praisonai
GHSA-rg5q-pp8p-f7jm PraisonAI: Webhook SSRF via DNS fail-open in `JobSubmitRequest.validate_webhook_url()` — bypass of CVE-2026-40114	High	Also affects praisonai

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor

Description

Summary

Details

Affected component

Vulnerable code / root cause

Attack flow

Why existing protection is bypassed

Security boundary

Scope limits (do not overclaim)

Proof of Concept

Environment

Steps to reproduce

Expected result

Actual result

Screenshots

Screenshots

Impact

Affected versions

PyPI

How to fix

praisonai PyPI → 4.6.78

Severity breakdown

CVSS 4.0 6.9

CVSS 3.1 7.3

Weakness

CWE-20: Improper Input Validation

CWE-306: Missing Authentication for Critical Function

CWE-862: Missing Authorization

References

Advisories

Packages

Other links

Timeline

Related advisories

praisonai PyPI → `4.6.78`