Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

5966 vulnerabilities reference this CWE, most recent first.

GHSA-4PFH-PQFV-VHRC

Vulnerability from github – Published: 2022-05-13 01:39 – Updated: 2022-05-13 01:39
VLAI
Details

Unspecified vulnerability in HP Intelligent Management Center (iMC) and HP IMC Service Operation Management Software Module allows remote attackers to bypass authentication via unknown vectors, aka ZDI-CAN-1644.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-4824"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-10-13T10:20:00Z",
    "severity": "HIGH"
  },
  "details": "Unspecified vulnerability in HP Intelligent Management Center (iMC) and HP IMC Service Operation Management Software Module allows remote attackers to bypass authentication via unknown vectors, aka ZDI-CAN-1644.",
  "id": "GHSA-4pfh-pqfv-vhrc",
  "modified": "2022-05-13T01:39:08Z",
  "published": "2022-05-13T01:39:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4824"
    },
    {
      "type": "WEB",
      "url": "https://h20564.www2.hp.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c03943547"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4PJP-5725-8MXH

Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14
VLAI
Details

A vulnerability in access control list (ACL) functionality of the Gigabit Ethernet Management interface of Cisco IOS XE Software could allow an unauthenticated, remote attacker to reach the configured IP addresses on the Gigabit Ethernet Management interface. The vulnerability is due to a logic error that was introduced in the Cisco IOS XE Software 16.1.1 Release, which prevents the ACL from working when applied against the management interface. An attacker could exploit this issue by attempting to access the device via the management interface.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-1759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-28T01:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in access control list (ACL) functionality of the Gigabit Ethernet Management interface of Cisco IOS XE Software could allow an unauthenticated, remote attacker to reach the configured IP addresses on the Gigabit Ethernet Management interface. The vulnerability is due to a logic error that was introduced in the Cisco IOS XE Software 16.1.1 Release, which prevents the ACL from working when applied against the management interface. An attacker could exploit this issue by attempting to access the device via the management interface.",
  "id": "GHSA-4pjp-5725-8mxh",
  "modified": "2022-05-13T01:14:47Z",
  "published": "2022-05-13T01:14:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1759"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190327-mgmtacl"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/107660"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4PPQ-5752-XRXR

Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38
VLAI
Details

A vulnerability in the REST API of the web-based user interface (web UI) of Cisco IOS XE 3.1 through 16.5 could allow an unauthenticated, remote attacker to bypass authentication to the REST API of the web UI of the affected software. The vulnerability is due to insufficient input validation for the REST API of the affected software. An attacker could exploit this vulnerability by sending a malicious API request to an affected device. A successful exploit could allow the attacker to bypass authentication and gain access to the web UI of the affected software. This vulnerability affects Cisco devices that are running a vulnerable release of Cisco IOS XE Software, if the HTTP Server feature is enabled for the device. The newly redesigned, web-based administration UI was introduced in the Denali 16.2 Release of Cisco IOS XE Software. This vulnerability does not affect the web-based administration UI in earlier releases of Cisco IOS XE Software. Cisco Bug IDs: CSCuz46036.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-12229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-29T01:34:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in the REST API of the web-based user interface (web UI) of Cisco IOS XE 3.1 through 16.5 could allow an unauthenticated, remote attacker to bypass authentication to the REST API of the web UI of the affected software. The vulnerability is due to insufficient input validation for the REST API of the affected software. An attacker could exploit this vulnerability by sending a malicious API request to an affected device. A successful exploit could allow the attacker to bypass authentication and gain access to the web UI of the affected software. This vulnerability affects Cisco devices that are running a vulnerable release of Cisco IOS XE Software, if the HTTP Server feature is enabled for the device. The newly redesigned, web-based administration UI was introduced in the Denali 16.2 Release of Cisco IOS XE Software. This vulnerability does not affect the web-based administration UI in earlier releases of Cisco IOS XE Software. Cisco Bug IDs: CSCuz46036.",
  "id": "GHSA-4ppq-5752-xrxr",
  "modified": "2022-05-13T01:38:09Z",
  "published": "2022-05-13T01:38:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12229"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170927-restapi"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101032"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039447"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4PVC-C6R4-QVQ2

Vulnerability from github – Published: 2022-05-17 05:13 – Updated: 2022-05-17 05:13
VLAI
Details

The internal message protocol for Walrus in Eucalyptus 3.2.0 and earlier does not require signatures for unspecified request headers, which allows attackers to (1) delete or (2) upload snapshots.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2012-4066"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-03-08T18:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The internal message protocol for Walrus in Eucalyptus 3.2.0 and earlier does not require signatures for unspecified request headers, which allows attackers to (1) delete or (2) upload snapshots.",
  "id": "GHSA-4pvc-c6r4-qvq2",
  "modified": "2022-05-17T05:13:34Z",
  "published": "2022-05-17T05:13:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-4066"
    },
    {
      "type": "WEB",
      "url": "http://www.eucalyptus.com/eucalyptus-cloud/security/esa-08"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4PW2-X5QF-3FX4

Vulnerability from github – Published: 2022-05-17 03:12 – Updated: 2022-05-17 03:12
VLAI
Details

IBM General Parallel File System (GPFS) 3.4 before 3.4.0.32, 3.5 before 3.5.0.24, and 4.1 before 4.1.0.7 in certain cipherList configurations allows remote attackers to bypass authentication and execute arbitrary programs as root via unspecified vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2015-0198"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2015-03-24T02:01:00Z",
    "severity": "HIGH"
  },
  "details": "IBM General Parallel File System (GPFS) 3.4 before 3.4.0.32, 3.5 before 3.5.0.24, and 4.1 before 4.1.0.7 in certain cipherList configurations allows remote attackers to bypass authentication and execute arbitrary programs as root via unspecified vectors.",
  "id": "GHSA-4pw2-x5qf-3fx4",
  "modified": "2022-05-17T03:12:32Z",
  "published": "2022-05-17T03:12:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-0198"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=isg3T1022062"
    },
    {
      "type": "WEB",
      "url": "http://www-304.ibm.com/support/docview.wss?uid=swg21902662"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/73278"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1032880"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4Q4M-QX69-VCGQ

Vulnerability from github – Published: 2022-05-02 03:12 – Updated: 2022-05-02 03:12
VLAI
Details

NTP 4.2.4 before 4.2.4p5 and 4.2.5 before 4.2.5p150 does not properly check the return value from the OpenSSL EVP_VerifyFinal function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature for DSA and ECDSA keys, a similar vulnerability to CVE-2008-5077.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-0021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-01-07T17:30:00Z",
    "severity": "MODERATE"
  },
  "details": "NTP 4.2.4 before 4.2.4p5 and 4.2.5 before 4.2.5p150 does not properly check the return value from the OpenSSL EVP_VerifyFinal function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature for DSA and ECDSA keys, a similar vulnerability to CVE-2008-5077.",
  "id": "GHSA-4q4m-qx69-vcgq",
  "modified": "2022-05-02T03:12:27Z",
  "published": "2022-05-02T03:12:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0021"
    },
    {
      "type": "WEB",
      "url": "https://lists.ntp.org/pipermail/announce/2009-January/000055.html"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A10035"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2009/May/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2009-03/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2009-04/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/33406"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/33558"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/33648"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/34642"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/35074"
    },
    {
      "type": "WEB",
      "url": "http://slackware.com/security/viewer.php?l=slackware-security\u0026y=2009\u0026m=slackware-security.531177"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT3549"
    },
    {
      "type": "WEB",
      "url": "http://www.ocert.org/advisories/ocert-2008-016.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2009-0046.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/499827/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1021533"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA09-133A.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/0042"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/1297"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4QG4-CVH2-CRGG

Vulnerability from github – Published: 2024-07-18 15:28 – Updated: 2024-07-19 15:27
VLAI
Summary
matrix-sdk-crypto's `UserIdentity::is_verified` not checking verification status of own user identity while performing the check
Details

The UserIdentity::is_verified() method in the matrix-sdk-crypto crate before version 0.7.2 doesn't take into account the verification status of the user's own identity while performing the check and may as a result return a value contrary to what is implied by its name and documentation.

Impact

If the method is used to decide whether to perform sensitive operations towards a user identity, a malicious homeserver could manipulate the outcome in order to make the identity appear trusted. This is not a typical usage of the method, which lowers the impact. The method itself is not used inside the matrix-sdk-crypto crate.

Patches

The 0.7.2 release of the matrix-sdk-crypto crate includes a fix.

Workarounds

None.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "matrix-sdk-crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-40648"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-18T15:28:07Z",
    "nvd_published_at": "2024-07-18T17:15:05Z",
    "severity": "MODERATE"
  },
  "details": "The `UserIdentity::is_verified()` method in the matrix-sdk-crypto crate before version 0.7.2 doesn\u0027t take into account the verification status of the user\u0027s own identity while performing the check and may as a result return a value contrary to what is implied by its name and documentation.\n\n### Impact\n\nIf the method is used to decide whether to perform sensitive operations towards a user identity, a malicious homeserver could manipulate the outcome in order to make the identity appear trusted. This is not a typical usage of the method, which lowers the impact. The method itself is not used inside the `matrix-sdk-crypto` crate.\n\n### Patches\n\nThe 0.7.2 release of the `matrix-sdk-crypto` crate includes a fix.\n\n### Workarounds\n\nNone.\n",
  "id": "GHSA-4qg4-cvh2-crgg",
  "modified": "2024-07-19T15:27:44Z",
  "published": "2024-07-18T15:28:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/matrix-rust-sdk/security/advisories/GHSA-4qg4-cvh2-crgg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40648"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/matrix-rust-sdk/commit/76a7052149bb8f722df12da915b3a06d19a6695a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/matrix-org/matrix-rust-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/matrix-rust-sdk/releases/tag/0.7.2-crypto"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0356.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "matrix-sdk-crypto\u0027s `UserIdentity::is_verified` not checking verification status of own user identity while performing the check"
}

GHSA-4QG5-96HP-HQJF

Vulnerability from github – Published: 2023-08-16 21:31 – Updated: 2024-04-04 07:00
VLAI
Details

Dell BIOS contains an improper authentication vulnerability. A malicious user with physical access to the system may potentially exploit this vulnerability in order to modify a security-critical UEFI variable without knowledge of the BIOS administrator.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-32453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-16T20:15:09Z",
    "severity": "LOW"
  },
  "details": "\nDell BIOS contains an improper authentication vulnerability. A malicious user with physical access to the system may potentially exploit this vulnerability in order to modify a security-critical UEFI variable without knowledge of the BIOS administrator.\n\n",
  "id": "GHSA-4qg5-96hp-hqjf",
  "modified": "2024-04-04T07:00:26Z",
  "published": "2023-08-16T21:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32453"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000215217/dsa-2023-190-dell-client-bios"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4QQ2-2J2X-X62C

Vulnerability from github – Published: 2026-06-18 14:25 – Updated: 2026-06-18 14:25
VLAI
Summary
npm PraisonAI MCPSecurity Basic/OAuth authentication policies accept invalid credentials without validation
Details

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:praisonai@1.7.1 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.

Impact

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.

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.

Suggested Fix

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' };
}

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.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.1"
            },
            {
              "fixed": "1.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-288",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:25:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe published npm package `praisonai` exports an `MCPSecurity` helper described in source as:\n\n```text\nMCP Security - Authentication, authorization, and rate limiting\nProvides security policies for MCP servers.\n```\n\nIts `AuthMethod` type advertises five authentication methods:\n\n```ts\nexport type AuthMethod = \u0027none\u0027 | \u0027api-key\u0027 | \u0027bearer\u0027 | \u0027basic\u0027 | \u0027oauth\u0027;\n```\n\nThe authentication-policy evaluator, however, only validates credentials for `api-key` and `bearer`:\n\n```ts\nif (policy.auth.method === \u0027api-key\u0027 || policy.auth.method === \u0027bearer\u0027) {\n    const valid = policy.auth.validate\n        ? await policy.auth.validate(token)\n        : this.validateApiKey(token);\n\n    if (!valid) {\n        return { allowed: false, reason: \u0027Invalid credentials\u0027 };\n    }\n}\n\nreturn { allowed: true, context: { authenticated: true } };\n```\n\nFor `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.\n\nThis 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.\n\n## Technical Details\n\n`SecurityPolicy.auth` accepts both a method and a validator:\n\n```ts\nauth?: { method: AuthMethod; validate?: (token: string) =\u003e Promise\u003cboolean\u003e };\n```\n\n`extractToken()` parses both Bearer and Basic headers:\n\n```ts\nif (auth.startsWith(\u0027Bearer \u0027)) {\n    return auth.slice(7);\n}\nif (auth.startsWith(\u0027Basic \u0027)) {\n    return auth.slice(6);\n}\nreturn auth;\n```\n\nBut `evaluatePolicy()` only calls `policy.auth.validate()` for two methods:\n\n```ts\nif (policy.auth.method === \u0027api-key\u0027 || policy.auth.method === \u0027bearer\u0027) {\n    const valid = policy.auth.validate\n        ? await policy.auth.validate(token)\n        : this.validateApiKey(token);\n\n    if (!valid) {\n        return { allowed: false, reason: \u0027Invalid credentials\u0027 };\n    }\n}\n```\n\nThere is no validation branch for `basic` or `oauth`. After extracting any non-empty token, those methods fall through to the success return:\n\n```ts\nreturn { allowed: true, context: { authenticated: true } };\n```\n\n`check()` then ignores successful authentication context and returns a generic allowed result:\n\n```ts\nreturn { allowed: true, context: { authenticated: false } };\n```\n\nThat context propagation issue is secondary. The security-relevant flaw is that invalid Basic/OAuth credentials are allowed at all.\n\n### Why This Is Not Intended Behavior\n\nThis 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.\n\nThe control cases prove the intended security behavior:\n\n- Missing Basic credentials are denied as `Authentication required`.\n- Invalid `api-key` credentials are denied as `Invalid credentials`.\n- Invalid `bearer` credentials are denied as `Invalid credentials`.\n\nThe 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.\n\nThis 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.\n\n## PoV\n\nRun from a local reproduction checkout:\n\n```bash\nnode poc/pov_poc.js 1.7.1\n```\n\nThe PoV:\n\n1. Installs `npm:praisonai@1.7.1` into a temporary project with scripts disabled.\n2. Imports `MCPSecurity` from the package root.\n3. Creates one `authenticate` policy per method.\n4. Supplies an `auth.validate` callback that always returns `false`.\n5. Sends invalid `api-key`, `bearer`, `basic`, and `oauth` credentials.\n6. Confirms the missing-header Basic control is still denied.\n\nObserved output summary from `evidence/pov-npm-1.7.1.json`:\n\n```json\n{\n  \"package\": \"praisonai\",\n  \"version\": \"1.7.1\",\n  \"cases\": [\n    {\n      \"method\": \"api-key\",\n      \"validateCalls\": 1,\n      \"allowed\": false,\n      \"reason\": \"Invalid credentials\"\n    },\n    {\n      \"method\": \"bearer\",\n      \"validateCalls\": 1,\n      \"allowed\": false,\n      \"reason\": \"Invalid credentials\"\n    },\n    {\n      \"method\": \"basic\",\n      \"validateCalls\": 0,\n      \"allowed\": true\n    },\n    {\n      \"method\": \"oauth\",\n      \"validateCalls\": 0,\n      \"allowed\": true\n    },\n    {\n      \"method\": \"basic\",\n      \"authorizationHeaderPresent\": false,\n      \"validateCalls\": 0,\n      \"allowed\": false,\n      \"reason\": \"Authentication required\"\n    }\n  ],\n  \"controlsPass\": true,\n  \"vulnerable\": true\n}\n```\n\nThe PoV is local-only. It does not start a server, contact a third-party target, or use live credentials.\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nA 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.\n\nDepending on the protected MCP tools and resources, this can allow an unauthenticated network caller to:\n\n- list protected tools or resources;\n- call tools that were intended to require authentication;\n- read protected MCP resources;\n- trigger agent/workflow actions exposed behind the security helper; and\n- bypass audit assumptions based on the configured validator.\n\nThis 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.\n\n### Severity\n\nSuggested severity: High.\n\nRationale:\n\n- `AV`: the affected helper is intended to protect MCP server requests and equivalent HTTP security checks.\n- `AC`: a single non-empty Basic or OAuth-style Authorization header is sufficient when such a policy is configured.\n- `PR`: the bypass grants access without valid credentials.\n- `UI`: no maintainer or user interaction is required after deployment.\n- `S`: impact is within the PraisonAI-hosting service and its exposed MCP resources/tools.\n- `C`: protected MCP resources or tool outputs may be disclosed.\n- `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.\n- `A`: the PoV does not demonstrate availability impact.\n\nIf a deployment protects high-impact write or execution tools with `MCPSecurity`, maintainers may reasonably score integrity higher.\n\n## Suggested Fix\n\nMake authentication evaluation fail closed for every advertised method.\n\nRecommended:\n\n1. For `authenticate` policies, call `policy.auth.validate(token)` whenever it is provided, regardless of `auth.method`.\n2. If no validator is provided, only fall back to `validateApiKey()` for `api-key` when that behavior is explicitly intended.\n3. For `bearer` and `oauth`, require a validator or a server-side token validation implementation; otherwise deny with a configuration error.\n4. For `basic`, decode the Basic credential safely and pass the decoded username/password or raw credential to a validator; if no validator exists, deny.\n5. Treat unknown or unsupported methods as denied, not allowed.\n6. Return authenticated context from `check()` after a successful authenticate policy instead of replacing it with `{ authenticated: false }`.\n7. Add regression tests proving invalid credentials are rejected for `api-key`, `bearer`, `basic`, and `oauth`, and that each configured validator is called.\n\nMinimal fail-closed shape:\n\n```ts\nif (policy.type === \u0027authenticate\u0027) {\n  if (!policy.auth) return { allowed: false, reason: \u0027Authentication policy is not configured\u0027 };\n\n  const token = request.headers ? this.extractToken(request.headers) : null;\n  if (!token) return { allowed: false, reason: \u0027Authentication required\u0027 };\n\n  if (policy.auth.validate) {\n    const valid = await policy.auth.validate(token);\n    return valid\n      ? { allowed: true, context: { authenticated: true } }\n      : { allowed: false, reason: \u0027Invalid credentials\u0027 };\n  }\n\n  if (policy.auth.method === \u0027api-key\u0027) {\n    return this.validateApiKey(token)\n      ? { allowed: true, context: { authenticated: true } }\n      : { allowed: false, reason: \u0027Invalid credentials\u0027 };\n  }\n\n  return { allowed: false, reason: \u0027Authentication validator required\u0027 };\n}\n```\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Ecosystem: `npm`\n- Package: `praisonai`\n- Component: TypeScript MCP security helper `src/praisonai-ts/src/mcp/security.ts`\n- Published dist path: `node_modules/praisonai/dist/mcp/security.js`\n- Latest npm package validated: `1.7.1`\n- Current `origin/main` validated: `1ad58ca02975ff1398efeda694ea2ab78f20cf3e`\n- `src/praisonai-ts/package.json` at `origin/main`: `praisonai` `1.7.1`\n\nSuggested affected range:\n\n```text\nnpm:praisonai \u003e= 1.5.1, \u003c= 1.7.1\n```\n\nAll published npm `1.x` versions were swept locally:\n\n- `1.0.0` through `1.5.0`: the tested root export was unavailable or `MCPSecurity` was not exported as a constructor.\n- `1.5.1`, `1.5.2`, `1.5.3`, `1.5.4`, `1.6.0`, `1.7.0`, and `1.7.1`: vulnerable.\n\nThe package root re-exports this helper:\n\n```ts\nexport {\n  MCPClient, createMCPClient, getMCPTools,\n  MCPServer, createMCPServer,\n  MCPSession as MCPSessionManager, createMCPSession,\n  MCPSecurity, createMCPSecurity, createApiKeyPolicy, createRateLimitPolicy,\n  type MCPClientConfig, type MCPSession, type MCPTransportType,\n  type MCPServerConfig, type MCPServerTool,\n  type SecurityPolicy, type SecurityResult\n} from \u0027./mcp\u0027;\n```\n\n## Advisory History\n\nVisible PraisonAI advisories and prior submissions were checked. The closest public advisory is `GHSA-98f9-fqg5-hvq5` / `CVE-2026-34953`, but that issue is distinct:\n\n- `GHSA-98f9-fqg5-hvq5` affects the PyPI package and Python `OAuthManager.validate_token()`.\n- This report affects the npm package and TypeScript `src/praisonai-ts/src/mcp/security.ts`.\n- The prior issue accepts arbitrary Bearer tokens because an empty Python token store falls through to `True`.\n- This issue accepts invalid Basic/OAuth credentials because the TypeScript validator callback is never called for those advertised methods.\n- The affected ranges and patched surfaces are different.\n\nThe 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.",
  "id": "GHSA-4qq2-2j2x-x62c",
  "modified": "2026-06-18T14:25:17Z",
  "published": "2026-06-18T14:25:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-4qq2-2j2x-x62c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "npm PraisonAI MCPSecurity Basic/OAuth authentication policies accept invalid credentials without validation"
}

GHSA-4QX9-MWF7-7CX8

Vulnerability from github – Published: 2022-05-17 04:52 – Updated: 2025-04-11 03:58
VLAI
Details

sql/password.c in Oracle MySQL 5.1.x before 5.1.63, 5.5.x before 5.5.24, and 5.6.x before 5.6.6, and MariaDB 5.1.x before 5.1.62, 5.2.x before 5.2.12, 5.3.x before 5.3.6, and 5.5.x before 5.5.23, when running in certain environments with certain implementations of the memcmp function, allows remote attackers to bypass authentication by repeatedly authenticating with the same incorrect password, which eventually causes a token comparison to succeed due to an improperly-checked return value.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2012-2122"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-06-26T18:55:00Z",
    "severity": "MODERATE"
  },
  "details": "sql/password.c in Oracle MySQL 5.1.x before 5.1.63, 5.5.x before 5.5.24, and 5.6.x before 5.6.6, and MariaDB 5.1.x before 5.1.62, 5.2.x before 5.2.12, 5.3.x before 5.3.6, and 5.5.x before 5.5.23, when running in certain environments with certain implementations of the memcmp function, allows remote attackers to bypass authentication by repeatedly authenticating with the same incorrect password, which eventually causes a token comparison to succeed due to an improperly-checked return value.",
  "id": "GHSA-4qx9-mwf7-7cx8",
  "modified": "2025-04-11T03:58:44Z",
  "published": "2022-05-17T04:52:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-2122"
    },
    {
      "type": "WEB",
      "url": "https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql"
    },
    {
      "type": "WEB",
      "url": "http://bugs.mysql.com/bug.php?id=64884"
    },
    {
      "type": "WEB",
      "url": "http://kb.askmonty.org/en/mariadb-5162-release-notes"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2012-08/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/oss-sec/2012/q2/493"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/49417"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/53372"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-201308-06.xml"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1027143"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/19092"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/53911"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.