GHSA-4QQ2-2J2X-X62C

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 false.
5. Sends invalid api-key, bearer, basic, and oauth credentials.
6. Confirms the missing-header Basic control is still denied.

Observed output summary from evidence/pov-npm-1.7.1.json:

{
  "package": "praisonai",
  "version": "1.7.1",
  "cases": [
    {
      "method": "api-key",
      "validateCalls": 1,
      "allowed": false,
      "reason": "Invalid credentials"
    },
    {
      "method": "bearer",
      "validateCalls": 1,
      "allowed": false,
      "reason": "Invalid credentials"
    },
    {
      "method": "basic",
      "validateCalls": 0,
      "allowed": true
    },
    {
      "method": "oauth",
      "validateCalls": 0,
      "allowed": true
    },
    {
      "method": "basic",
      "authorizationHeaderPresent": false,
      "validateCalls": 0,
      "allowed": false,
      "reason": "Authentication required"
    }
  ],
  "controlsPass": true,
  "vulnerable": true
}

The PoV is local-only. It does not start a server, contact a third-party target, or use live credentials.

PoC

The PoV section above contains the local reproduction command, input, and decisive output.

Severity

Suggested severity: High.

Rationale:

• AV: the affected helper is intended to protect MCP server requests and equivalent HTTP security checks.
• AC: a single non-empty Basic or OAuth-style Authorization header is sufficient when such a policy is configured.
• PR: the bypass grants access without valid credentials.
• UI: no maintainer or user interaction is required after deployment.
• S: impact is within the PraisonAI-hosting service and its exposed MCP resources/tools.
• C: protected MCP resources or tool outputs may be disclosed.
• I: protected tool calls may perform state-changing actions depending on the registered tools; the score is conservative because the vulnerable helper is library-level and deployment-dependent.
• A: the PoV does not demonstrate availability impact.

If a deployment protects high-impact write or execution tools with MCPSecurity, maintainers may reasonably score integrity higher.

Affected Package/Versions

• Repository: MervinPraison/PraisonAI
• Ecosystem: npm
• Package: praisonai
• Component: TypeScript MCP security helper src/praisonai-ts/src/mcp/security.ts
• Published dist path: node_modules/praisonai/dist/mcp/security.js
• Latest npm package validated: 1.7.1
• Current origin/main validated: 1ad58ca02975ff1398efeda694ea2ab78f20cf3e
• src/praisonai-ts/package.json at origin/main: praisonai 1.7.1

Suggested affected range:

npm:praisonai >= 1.5.1, <= 1.7.1

All published npm 1.x versions were swept locally:

• 1.0.0 through 1.5.0: the tested root export was unavailable or MCPSecurity was not exported as a constructor.
• 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.6.0, 1.7.0, and 1.7.1: vulnerable.

The package root re-exports this helper:

export {
  MCPClient, createMCPClient, getMCPTools,
  MCPServer, createMCPServer,
  MCPSession as MCPSessionManager, createMCPSession,
  MCPSecurity, createMCPSecurity, createApiKeyPolicy, createRateLimitPolicy,
  type MCPClientConfig, type MCPSession, type MCPTransportType,
  type MCPServerConfig, type MCPServerTool,
  type SecurityPolicy, type SecurityResult
} from './mcp';

Advisory History

Visible PraisonAI advisories and prior submissions were checked. The closest public advisory is GHSA-98f9-fqg5-hvq5 / CVE-2026-34953, but that issue is distinct:

• GHSA-98f9-fqg5-hvq5 affects the PyPI package and Python OAuthManager.validate_token().
• This report affects the npm package and TypeScript src/praisonai-ts/src/mcp/security.ts.
• The prior issue accepts arbitrary Bearer tokens because an empty Python token store falls through to True.
• This issue accepts invalid Basic/OAuth credentials because the TypeScript validator callback is never called for those advertised methods.
• The affected ranges and patched surfaces are different.

The earlier npm MCPServer report is also distinct: it covers missing auth in the HTTP transport by default. This report covers a fail-open branch in the separate exported MCPSecurity helper when users attempt to add Basic/OAuth authentication.

A downstream application that uses MCPSecurity to protect an HTTP MCP transport, gateway, or equivalent tool/resource endpoint can believe it has enabled Basic or OAuth authentication while accepting any non-empty Authorization header.

Depending on the protected MCP tools and resources, this can allow an unauthenticated network caller to:

• list protected tools or resources;
• call tools that were intended to require authentication;
• read protected MCP resources;
• trigger agent/workflow actions exposed behind the security helper; and
• bypass audit assumptions based on the configured validator.

This report does not claim that npm PraisonAI wires MCPSecurity into the default MCPServer.startHttp() path. It is a library-level authentication bypass in an exported security component intended to protect MCP servers.

The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.

GHSA-4QQ2-2J2X-X62C has a CVSS score of 8.2 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.7.2); upgrading removes the vulnerable code path.

Kodem intelligence

Make authentication evaluation fail closed for every advertised method.

Recommended:

1. For authenticate policies, call policy.auth.validate(token) whenever it is provided, regardless of auth.method.
2. If no validator is provided, only fall back to validateApiKey() for api-key when that behavior is explicitly intended.
3. For bearer and oauth, require a validator or a server-side token validation implementation; otherwise deny with a configuration error.
4. For basic, decode the Basic credential safely and pass the decoded username/password or raw credential to a validator; if no validator exists, deny.
5. Treat unknown or unsupported methods as denied, not allowed.
6. Return authenticated context from check() after a successful authenticate policy instead of replacing it with { authenticated: false }.
7. Add regression tests proving invalid credentials are rejected for api-key, bearer, basic, and oauth, and that each configured validator is called.

Minimal fail-closed shape:

if (policy.type === 'authenticate') {
  if (!policy.auth) return { allowed: false, reason: 'Authentication policy is not configured' };

  const token = request.headers ? this.extractToken(request.headers) : null;
  if (!token) return { allowed: false, reason: 'Authentication required' };

  if (policy.auth.validate) {
    const valid = await policy.auth.validate(token);
    return valid
      ? { allowed: true, context: { authenticated: true } }
      : { allowed: false, reason: 'Invalid credentials' };
  }

  if (policy.auth.method === 'api-key') {
    return this.validateApiKey(token)
      ? { allowed: true, context: { authenticated: true } }
      : { allowed: false, reason: 'Invalid credentials' };
  }

  return { allowed: false, reason: 'Authentication validator required' };
}

1. What is GHSA-4QQ2-2J2X-X62C? GHSA-4QQ2-2J2X-X62C is a high-severity improper authentication vulnerability in praisonai (npm), affecting versions >= 1.5.1, <= 1.7.1. It is fixed in 1.7.2. The application does not adequately verify the identity of a user, device, or process before granting access.
2. How severe is GHSA-4QQ2-2J2X-X62C? GHSA-4QQ2-2J2X-X62C has a CVSS score of 8.2 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of praisonai are affected by GHSA-4QQ2-2J2X-X62C? praisonai (npm) versions >= 1.5.1, <= 1.7.1 is affected.
4. Is there a fix for GHSA-4QQ2-2J2X-X62C? Yes. GHSA-4QQ2-2J2X-X62C is fixed in 1.7.2. Upgrade to this version or later.
5. Is GHSA-4QQ2-2J2X-X62C exploitable, and should I be worried? Whether GHSA-4QQ2-2J2X-X62C is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-4QQ2-2J2X-X62C is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-4QQ2-2J2X-X62C? Upgrade praisonai to 1.7.2 or later.