Authentication bypass in PraisonAI MCP server
PraisonAI versions prior to 4.5.97 contain an authentication bypass in OAuthManager.validate_token(). The function returns True for tokens absent from its internal token store, which is empty by default. Consequently, an HTTP request containing an arbitrary unrecognized Bearer token is treated as authenticated by the MCP server, granting access to all registered tools and agent capabilities.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
An unauthenticated network attacker can bypass MCP server authentication and access all registered tools and agent capabilities. This can compromise confidentiality and integrity through unauthorized use of exposed functionality. The specific operations available depend on the tools and capabilities registered with the server; the assigned CVSS vector indicates high confidentiality and integrity impact and no availability impact.
If you can’t patch tonight, do this now.
If immediate upgrade is not possible, restrict network access to the MCP server to trusted clients only, place the service behind a compensating authentication control such as a reverse proxy or API gateway enforcing independent authentication, and monitor for requests using unexpected or arbitrary Bearer tokens. Because the vulnerable logic accepts invalid tokens by design, mitigation should focus on preventing untrusted access until the patched version can be deployed.
Patch, then assume compromise.
Upgrade PraisonAI to version 4.5.97 or later, which includes the fix.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.