CVE-2026-57134

PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, MCPSecurity.evaluatePolicy() in src/praisonai-ts/src/mcp/security.ts invokes the configured credential validator only when AuthMethod is api-key or bearer. Basic and OAuth policies accept any non-empty Authorization header without calling auth.validate(), then return an authenticated result, allowing callers with invalid credentials to access MCP tools and resources protected by those policies. This issue is fixed in version 1.7.2.

PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, MCPSecurity.evaluatePolicy() in src/praisonai-ts/src/mcp/security.ts invokes the configured credential validator only when AuthMethod is api-key or bearer. Basic and OAuth policies accept any non-empty Authorization header without calling auth.validate(), then return an authenticated result, allowing callers with invalid credentials to access MCP tools and resources protected by those policies. This issue is fixed in version 1.7.2.

Summary

The published npm package praisonai exports an MCPSecurity helper described in source as:

MCP Security - Authentication, authorization, and rate limiting
Provides security policies for MCP servers.

Its AuthMethod type advertises five authentication methods:

export type AuthMethod = 'none' | 'api-key' | 'bearer' | 'basic' | 'oauth';

The authentication-policy evaluator, however, only validates credentials for api-key and bearer:

if (policy.auth.method === 'api-key' || policy.auth.method === 'bearer') {
    const valid = policy.auth.validate
        ? await policy.auth.validate(token)
        : this.validateApiKey(token);

    if (!valid) {
        return { allowed: false, reason: 'Invalid credentials' };
    }
}

return { allowed: true, context: { authenticated: true } };

For basic and oauth, any non-empty Authorization header skips the supplied validate callback and returns allowed. A local PoV configures auth.validate to always return false; invalid api-key and bearer credentials are rejected, while invalid basic and oauth credentials are accepted without calling the validator.

This is a protection-mechanism failure in the exported npm MCP security helper. It is distinct from the separate issue that the npm MCPServer HTTP transport does not enforce authentication by default.

Technical Details

SecurityPolicy.auth accepts both a method and a validator:

auth?: { method: AuthMethod; validate?: (token: string) => Promise<boolean> };

extractToken() parses both Bearer and Basic headers:

if (auth.startsWith('Bearer ')) {
    return auth.slice(7);
}
if (auth.startsWith('Basic ')) {
    return auth.slice(6);
}
return auth;

But evaluatePolicy() only calls policy.auth.validate() for two methods:

if (policy.auth.method === 'api-key' || policy.auth.method === 'bearer') {
    const valid = policy.auth.validate
        ? await policy.auth.validate(token)
        : this.validateApiKey(token);

    if (!valid) {
        return { allowed: false, reason: 'Invalid credentials' };
    }
}

There is no validation branch for basic or oauth. After extracting any non-empty token, those methods fall through to the success return:

return { allowed: true, context: { authenticated: true } };

check() then ignores successful authentication context and returns a generic allowed result:

return { allowed: true, context: { authenticated: false } };

That context propagation issue is secondary. The security-relevant flaw is that invalid Basic/OAuth credentials are allowed at all.

Why This Is Not Intended Behavior

This is not a claim that every MCPSecurity user must choose Basic or OAuth. The issue is that the API explicitly exposes those methods as authentication methods and accepts a validator callback for the policy, but the implementation does not call the validator for those methods.

The control cases prove the intended security behavior:

• Missing Basic credentials are denied as Authentication required.
• Invalid api-key credentials are denied as Invalid credentials.
• Invalid bearer credentials are denied as Invalid credentials.

The only difference in the vulnerable cases is the selected advertised method. Invalid Basic/OAuth credentials should not become authenticated merely because the method is not listed in the two-method validation branch.

This also matches MCP authorization guidance. MCP servers acting as resource servers must validate received access tokens; receiving a token is not proof that it is valid or intended for the server.

PoV

Run from a local reproduction checkout:

node poc/pov_poc.js 1.7.1

The PoV:

1. Installs npm:[email protected] into a temporary project with scripts disabled.
2. Imports MCPSecurity from the package root.
3. Creates one authenticate policy per method.
4. Supplies an auth.validate callback that always returns…

PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, MCPSecurity.evaluatePolicy() in src/praisonai-ts/src/mcp/security.ts invokes the configured credential validator only when AuthMethod is api-key or bearer. Basic and OAuth policies accept any non-empty Authorization header without calling auth.validate(), then return an authenticated result, allowing callers with invalid credentials to access MCP tools and resources protected by those policies. This issue is fixed in version 1.7.2.

PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, MCPSecurity.evaluatePolicy() in src/praisonai-ts/src/mcp/security.ts invokes the configured credential validator only when AuthMethod is api-key or bearer. Basic and OAuth policies accept any non-empty Authorization header without calling auth.validate(), then return an authenticated result, allowing callers with invalid credentials to access MCP tools and resources protected by those policies. This issue is fixed in version 1.7.2.

Summary

The published npm package praisonai exports an MCPSecurity helper described in source as:

MCP Security - Authentication, authorization, and rate limiting
Provides security policies for MCP servers.

Its AuthMethod type advertises five authentication methods:

export type AuthMethod = 'none' | 'api-key' | 'bearer' | 'basic' | 'oauth';

The authentication-policy evaluator, however, only validates credentials for api-key and bearer:

if (policy.auth.method === 'api-key' || policy.auth.method === 'bearer') {
    const valid = policy.auth.validate
        ? await policy.auth.validate(token)
        : this.validateApiKey(token);

    if (!valid) {
        return { allowed: false, reason: 'Invalid credentials' };
    }
}

return { allowed: true, context: { authenticated: true } };

For basic and oauth, any non-empty Authorization header skips the supplied validate callback and returns allowed. A local PoV configures auth.validate to always return false; invalid api-key and bearer credentials are rejected, while invalid basic and oauth credentials are accepted without calling the validator.

This is a protection-mechanism failure in the exported npm MCP security helper. It is distinct from the separate issue that the npm MCPServer HTTP transport does not enforce authentication by default.

Technical Details

SecurityPolicy.auth accepts both a method and a validator:

auth?: { method: AuthMethod; validate?: (token: string) => Promise<boolean> };

extractToken() parses both Bearer and Basic headers:

if (auth.startsWith('Bearer ')) {
    return auth.slice(7);
}
if (auth.startsWith('Basic ')) {
    return auth.slice(6);
}
return auth;

But evaluatePolicy() only calls policy.auth.validate() for two methods:

if (policy.auth.method === 'api-key' || policy.auth.method === 'bearer') {
    const valid = policy.auth.validate
        ? await policy.auth.validate(token)
        : this.validateApiKey(token);

    if (!valid) {
        return { allowed: false, reason: 'Invalid credentials' };
    }
}

There is no validation branch for basic or oauth. After extracting any non-empty token, those methods fall through to the success return:

return { allowed: true, context: { authenticated: true } };

check() then ignores successful authentication context and returns a generic allowed result:

return { allowed: true, context: { authenticated: false } };

That context propagation issue is secondary. The security-relevant flaw is that invalid Basic/OAuth credentials are allowed at all.

Why This Is Not Intended Behavior

This is not a claim that every MCPSecurity user must choose Basic or OAuth. The issue is that the API explicitly exposes those methods as authentication methods and accepts a validator callback for the policy, but the implementation does not call the validator for those methods.

The control cases prove the intended security behavior:

• Missing Basic credentials are denied as Authentication required.
• Invalid api-key credentials are denied as Invalid credentials.
• Invalid bearer credentials are denied as Invalid credentials.

The only difference in the vulnerable cases is the selected advertised method. Invalid Basic/OAuth credentials should not become authenticated merely because the method is not listed in the two-method validation branch.

This also matches MCP authorization guidance. MCP servers acting as resource servers must validate received access tokens; receiving a token is not proof that it is valid or intended for the server.

PoV

Run from a local reproduction checkout:

node poc/pov_poc.js 1.7.1

The PoV:

1. Installs npm:[email protected] into a temporary project with scripts disabled.
2. Imports MCPSecurity from the package root.
3. Creates one authenticate policy per method.
4. Supplies an auth.validate callback that always returns…