CVE-2026-61427: PraisonAI MCP Authentication Bypass

authentication free stock image for MCPwatch editorial use — Free stock image for MCPwatch editorial use. Source: Wikimedia Commons. Original: Computersicherheit.jpg. Creator: Wikimedia Commons contributor. License: CC BY-SA 3.0. License URL: http://creativecommons.org/licenses/by-sa/3.0/.

CVE-2026-61427 describes a missing-authentication condition in PraisonAI’s Model Context Protocol HTTP-stream server before version 4.6.78. The default command-line configuration did not require a bearer token, allowing a client that could reach the endpoint to initialize an MCP session, list exposed tools and submit tool calls.

This is a vulnerability report, not an incident report. No primary source reviewed by MCPwatch claims exploitation in the wild, and MCPwatch did not independently reproduce the behavior. The default server bind was loopback, which materially limits exposure: remote network access required an operator to bind the service to a network-accessible address or otherwise publish the local endpoint.

What the CNA record establishes

The VulnCheck CNA record for CVE-2026-61427, published July 15, says the --api-key option defaulted to no key and authentication checks ran only when a key was configured. It identifies the PyPI praisonai package before 4.6.78 as affected and 4.6.78 as unaffected.

VulnCheck assigns CVSS 4.0 6.9 Medium and CVSS 3.1 7.3 High. GitHub’s unreviewed mirror displays a Moderate label while carrying the same 7.3 CVSS 3.1 score. These are source-assigned ratings. MCPwatch is preserving the scoring-system and label differences rather than presenting a new severity judgment.

The duplicate CVE has been rejected

A repository security advisory, GHSA-hc5v-gxvj-58wh, had associated the same issue with CVE-2026-62178. During preparation of this brief, the CVE Services record for CVE-2026-62178 changed to REJECTED, names CVE-2026-61427 as the duplicate’s replacement and instructs users to reference CVE-2026-61427.

Asset inventories, tickets and feeds should therefore converge on CVE-2026-61427 while retaining the rejected number as an alias for historical matching. A scanner hit containing CVE-2026-62178 is not evidence of a second vulnerability. The GitHub repository advisory still displayed the older identifier at retrieval time, so consumers should rely on the current CVE Services disposition for identifier status.

Exposure depends on deployment shape

The CNA record says PraisonAI bound the MCP server to 127.0.0.1 by default. That still leaves the tool surface reachable by local processes and users able to access the host. Remote reachability requires a non-loopback bind, forwarding, proxying or another path that makes the endpoint accessible.

The advisory also reports that tool-call arguments were forwarded without dispatcher validation against each advertised input schema. That statement does not establish that every listed tool was functional or that arbitrary code execution occurred. The repository advisory explicitly says several higher-impact tool paths failed in the tested version and cautions against turning the authentication finding into an unsupported RCE or file-read claim.

Risk assessment should combine reachability with tool authority. A loopback-only service on a dedicated workstation has a different exposure path from a server bound to all interfaces, but either can become consequential if its enabled tools possess credentials or can modify external systems. Conversely, finding the package in a dependency inventory does not prove that the MCP HTTP-stream server was started. Operators should document whether the affected command ran, which interface and port it used, which tools were registered, and which operating-system identity and secrets were available to the process.

Patch version versus available package

The repository has a v4.6.78 release tag, and both the CNA and repository advisory use 4.6.78 as the fixed boundary. However, the live PyPI release index returned no downloadable files for praisonai 4.6.78 when checked. The first later version verified with PyPI files was 4.6.81, corresponding to the project’s v4.6.81 release.

Operators should not pin to an artifact that the package index does not provide. At retrieval time PyPI and the repository both identified 4.6.149 as current. Choose a currently supported available release, validate compatibility and record the exact installed artifact. The version boundary is a source claim; MCPwatch did not execute the patch or regression tests.

Defensive actions for operators

Inventory the running artifact. Record the resolved praisonai version from the environment, lockfile, image and process—not only a repository tag.
Map reachability. Check the bind address, host firewall, reverse proxy, tunnels, port forwarding and whether untrusted local users or workloads share the host.
Upgrade to an available supported release. Use a PyPI artifact newer than the affected boundary, then restart and verify the old process or image is gone.
Require authentication. Configure a strong API key or an authenticated gateway, restrict network access and avoid treating loopback as the only control.
Reduce tool authority. Expose only necessary tools and run the service with the minimum filesystem, credential and network permissions required.
Review evidence proportionately. Examine service, proxy, host and process logs for unexpected MCP sessions or tool calls. A vulnerable version alone is not proof of compromise.
Normalize the identifier. Track CVE-2026-61427 as canonical and retain CVE-2026-62178 only as a rejected alias.

Uncertainty and record status

The authentication and argument-validation claims originate in the CNA and linked repository advisory. MCPwatch verified the public record states, affected boundary, release tags and PyPI availability but did not reproduce requests or inspect a deployed customer environment. No exploitation claim was found. The rejected duplicate status is especially time-sensitive and may take time to propagate across databases.