Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-57127

  • PraisonAI’s 16 new CVEs describe fixes that shipped in June, and CVE-2026-57127’s affected range stops ten releases short of its own description

    PraisonAI’s 16 new CVEs describe fixes that shipped in June, and CVE-2026-57127’s affected range stops ten releases short of its own description

    Sixteen PraisonAI CVE records went live Monday afternoon; every fix they point at shipped in mid-June, 78 releases ago, and CVE-2026-57127’s machine-readable affected range stops ten releases short of the version its own description names.

    What happened

    Sixteen CVE records against PraisonAI, a multi-agent orchestration framework, were published to NVD on Monday, September 14, 2026, in two waves — eight at 3:17 p.m. UTC and eight more at 4:17 p.m. UTC. All sixteen are assigned by [email protected], which is GitHub acting as CNA for advisories filed in the project’s own repository. They split across two packages: PraisonAI, the application, and praisonaiagents, the library underneath it.

    The fixed versions named in the records are 4.6.58, 4.6.59 and 4.6.62 on the application side, and 1.6.58 and 1.6.59 on the library side. According to PyPI, which publishes upload timestamps for every release, those shipped on June 13 and June 17, 2026. The CVE records arrived 89 days later.

    Two of the sixteen were verified here one record at a time, and both carry a CVSS v3.1 base score of 9.8 CRITICAL from GitHub, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

    The first is CVE-2026-57124, CWE-78 and CWE-306. GitHub’s description:

    “Prior to 4.6.59, the default UI host applications expose POST /api/mcp/connect without mandatory authentication and accept caller-controlled command and args values that PraisonAIUI passes to StdioMCPClient to start a local process. Because the UI commands bind to 0.0.0.0 by default, a reachable unauthenticated client can execute commands as the UI service account even when the MCP handshake later fails.”

    Read that last clause again. The command runs whether or not the Model Context Protocol handshake succeeds, because the process is spawned before anything validates that the other end is an MCP server at all. The endpoint is an unauthenticated process launcher that happens to be labeled as MCP plumbing.

    The second is CVE-2026-57127, CWE-306 and CWE-1188, and it is where the record itself goes wrong.

    A ten-release gap between the description and the range

    CVE-2026-57127’s description opens: “Prior to 4.6.58, recipe serve installs APIKeyAuthMiddleware or JWTAuthMiddleware when an operator selects api-key or JWT authentication, but each middleware forwards requests when PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET and the corresponding recipe value are absent.” Prior to 4.6.58. The machine-readable affected range in the same record says less than 4.6.48, with 4.6.58 given as the fixed version.

    Those are ten releases apart. PyPI dates 4.6.48 to May 30, 2026, and 4.6.58 to June 13 — a two-week span. A scanner that matches on the affected range will report a host running 4.6.50, 4.6.53 or 4.6.57 as unaffected by a 9.8 the record’s own prose says it is affected by. CVE-2026-57131, published in the same wave, shows the same shape: range under 4.6.48, fix at 4.6.58.

    This site has reported that failure mode in other projects, and the direction matters. A range that is too wide produces false positives someone eventually investigates. A range that is too narrow produces silence, and silence is indistinguishable from safety.

    What the other fourteen cover

    Scores for the remaining records were not individually verified in this run and are therefore not given here. The mechanisms are, and they fall into three groups.

    Services listening on every interface with nothing in front of them. CVE-2026-57123 says ToolsMCPServer.run_sse and launch_tools_mcp_server “bind to 0.0.0.0” with no authentication and no origin validation, so any reachable client can invoke tools. CVE-2026-57125 covers an unauthenticated POST /api/v1/runs that accepts attacker-supplied agent_yaml carrying its own pre-approval, bypassing tool authorization. CVE-2026-57131 covers the same router mounted without authentication or per-job authorization. CVE-2026-57128 covers an SSE server that never consults ServerConfig.auth_token.

    Authentication that fails open when its configuration is missing. CVE-2026-57127 is one. CVE-2026-57132 is the other: setting PRAISONAI_CALL_AUTH to disabled makes verify_token accept agent invocations without authentication. In both, an operator who turned authentication on gets a system that behaves as though they had not.

    Model-controlled values reaching an interpreter. CVE-2026-57129 covers file mentions parsed from “prompt input from users, bots, or workflows” without traversal or symlink checks. CVE-2026-57130 covers email_tools.py interpolating LLM-controlled values into IMAP SEARCH criteria unescaped. CVE-2026-57145 covers multiedit.py passing an LLM-controlled filepath to open with no workspace boundary. CVE-2026-57120 covers a sandbox escape in execute_code via assembled dunder names and str.format. CVE-2026-56839 and CVE-2026-57119 cover path containment that is bypassed or never initialized. CVE-2026-57115 and CVE-2026-57126 cover SSRF filters in SpiderTools that check the initial URL but follow redirects, and that compare literal hostnames without resolving DNS.

    Why it matters

    The 89-day gap is the part worth sitting with. PraisonAI ships constantly: PyPI lists 828 releases of the application and 699 of the library, and 78 application releases landed between 4.6.59 and Monday. Version 4.7.8 went out at 5:13 p.m. UTC on Monday, under an hour after the last CVE in this batch published. Anyone who updates on a normal cadence fixed all sixteen of these in June without knowing they existed.

    That inverts the usual reading of a disclosure. The population at risk is not people who were slow to patch this week; it is people who pinned a version in June and have not moved since, which in an agent framework often means a container image baked once and deployed everywhere. For them the batch is not a patch notice, it is the first notice that the thing they pinned has an unauthenticated process launcher in it.

    The second thing worth saying plainly: a keyword search for PraisonAI in NVD returns 151 records. That number will get quoted as though it measures the project’s security, and it does not. It measures how many advisories got filed, which depends on a maintainer who files them and on researchers who have chosen this target. A comparable framework with no advisory practice would show a smaller number and tell you less. The honest reading of 151 is that this codebase is under active examination and the results are public — which is more than can be said for most of the agent frameworks now running in production.

    What the sixteen do say about the codebase is narrower and more useful than a count. The recurring mistake is a trust boundary that was never drawn. A local development convenience — bind to every interface, skip auth when the token is missing, let the model name a file — becomes a production exposure the moment the same process is reachable from somewhere else. Agent frameworks are unusually prone to this because the thing on the other side of the boundary is a language model whose output is attacker-influenced by design.

    What to do

    If you run PraisonAI or praisonaiagents from a pinned version, check it against 4.6.62 and 1.6.59. Those are the highest fixed versions named across the sixteen; anything below them is inside at least one of them. The current releases are 4.7.8 and 1.7.6, both published Monday afternoon.

    Do not trust a scanner’s verdict on CVE-2026-57127 or CVE-2026-57131. Their affected ranges stop at 4.6.48 while their descriptions say 4.6.58. If you are on any 4.6.x below 4.6.58, treat both as applying regardless of what the range says.

    Check what your agent services are bound to. Several of these are only reachable because the default bind address is 0.0.0.0. On a host with a public interface, or a container with a published port, that is the whole exposure. A bind to 127.0.0.1 plus an authenticated reverse proxy removes the reachability that CVE-2026-57123, CVE-2026-57124 and CVE-2026-57128 depend on.

    Verify that authentication you configured is actually enforced. The fail-open pattern in CVE-2026-57127 and CVE-2026-57132 is invisible from the configuration file. Send one unauthenticated request to a protected endpoint and confirm you get a 401.

    Sourcing note

    The sixteen records were enumerated with a windowed keyword query against the NVD API and read back per record for the two cited with scores, CVE-2026-57124 and CVE-2026-57127, including published and lastModified timestamps, metric blocks, CWEs and affected ranges. Scores are not given for the other fourteen because a windowed read on this API has returned wrong per-CVE scores before, including in a separate check earlier today. All quoted description text is from the NVD copy of the GitHub CNA record.

    Release versions and dates come from the PyPI JSON API for praisonai and praisonaiagents, using each release’s upload_time_iso_8601. The underlying GitHub Security Advisories were not fetched separately; where a GHSA and its CVE record disagree, this account reflects the CVE record, and the ten-release discrepancy in CVE-2026-57127 is reported as it appears there.

    Unresolved: whether the affected ranges on CVE-2026-57127 and CVE-2026-57131 are transcription errors or a deliberate narrowing that the descriptions failed to track; and whether the 4.6.48-to-4.6.57 window is affected, which only the advisory’s author can settle. The count of 151 is a raw keyword-match total from NVD and has not been de-duplicated or checked for false matches. No exploitation of any of these sixteen has been reported by any source checked here, and none is claimed.