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-W956-4FQQ-PMV6

Vulnerability from github – Published: 2022-04-23 00:40 – Updated: 2024-04-03 23:53

Details

The BrowserID (Mozilla Persona) module 7.x-1.x before 7.x-1.3 for Drupal allows remote attackers to hijack the authentication of arbitrary users via the audience identifier.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2012-2714"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-01-09T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The BrowserID (Mozilla Persona) module 7.x-1.x before 7.x-1.3 for Drupal allows remote attackers to hijack the authentication of arbitrary users via the audience identifier.",
  "id": "GHSA-w956-4fqq-pmv6",
  "modified": "2024-04-03T23:53:06Z",
  "published": "2022-04-23T00:40:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-2714"
    },
    {
      "type": "WEB",
      "url": "https://drupal.org/node/1596464"
    },
    {
      "type": "WEB",
      "url": "http://drupal.org/node/1597414"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/06/14/3"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/53673"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W98W-3MJ2-7WJ3

Vulnerability from github – Published: 2022-05-02 03:35 – Updated: 2022-05-02 03:35

Details

The local_handler_callback function in server/responder/pam/pam_LOCAL_domain.c in sssd 0.4.1 does not properly handle blank-password accounts in the SSSD BE database, which allows context-dependent attackers to obtain access by sending the account's username, in conjunction with an arbitrary password, over an ssh connection.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2009-2410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-07-30T18:30:00Z",
    "severity": "HIGH"
  },
  "details": "The local_handler_callback function in server/responder/pam/pam_LOCAL_domain.c in sssd 0.4.1 does not properly handle blank-password accounts in the SSSD BE database, which allows context-dependent attackers to obtain access by sending the account\u0027s username, in conjunction with an arbitrary password, over an ssh connection.",
  "id": "GHSA-w98w-3mj2-7wj3",
  "modified": "2022-05-02T03:35:01Z",
  "published": "2022-05-02T03:35:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-2410"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/attachment.cgi?id=355424"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=514057"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/52210"
    },
    {
      "type": "WEB",
      "url": "https://www.redhat.com/archives/fedora-package-announce/2009-July/msg01236.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/36018"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/35868"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-W9FM-2Q5V-J3WX

Vulnerability from github – Published: 2022-06-03 00:01 – Updated: 2022-06-10 00:00

Details

Barco Control Room Management Suite web application, which is part of TransForm N before 3.14, is exposing a license file upload mechanism. This upload can be executed without authentication.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-26971"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-02T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Barco Control Room Management Suite web application, which is part of TransForm N before 3.14, is exposing a license file upload mechanism. This upload can be executed without authentication.",
  "id": "GHSA-w9fm-2q5v-j3wx",
  "modified": "2022-06-10T00:00:52Z",
  "published": "2022-06-03T00:01:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26971"
    },
    {
      "type": "WEB",
      "url": "https://www.barco.com/en/support/knowledge-base/KB12681"
    },
    {
      "type": "WEB",
      "url": "https://www.barco.com/en/support/transform-n-management-server"
    }
  ],
  "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-W9J2-PVGH-6H63

Vulnerability from github – Published: 2026-05-05 00:21 – Updated: 2026-05-05 00:21

Summary

Axios: Authentication Bypass via Prototype Pollution Gadget in `validateStatus` Merge Strategy

Details

Vulnerability Disclosure: Authentication Bypass via Prototype Pollution Gadget in `validateStatus` Merge Strategy

Summary

The Axios library is vulnerable to a Prototype Pollution "Gadget" attack that allows any Object.prototype pollution to silently suppress all HTTP error responses (401, 403, 500, etc.), causing them to be treated as successful responses. This completely bypasses application-level authentication and error handling.

The root cause is that validateStatus is the only config property using the mergeDirectKeys merge strategy, which uses JavaScript's in operator — an operator that inherently traverses the prototype chain. When Object.prototype.validateStatus is polluted with () => true, all HTTP status codes are accepted as success.

Severity: High (CVSS 8.2) Affected Versions: All versions (v0.x - v1.x including v1.15.0) Vulnerable Component: lib/core/mergeConfig.js (mergeDirectKeys strategy) + lib/core/settle.js

CWE

CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
CWE-287: Improper Authentication

CVSS 3.1

Score: 8.2 (High)

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

Metric	Value	Justification
Attack Vector	Network	PP is triggered remotely
Attack Complexity	Low	Once PP exists, a single property assignment exploits this. Consistent with GHSA-fvcv-3m26-pcqx
Privileges Required	None	No authentication needed
User Interaction	None	No user interaction required
Scope	Unchanged	Impact within the application
Confidentiality	Low	401 treated as success may expose data behind auth gates
Integrity	High	All error handling and auth checks are silently bypassed — application operates on invalid assumptions
Availability	None	The function works correctly (returns true), no crash

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input.

If an attacker can pollute Object.prototype via any other library in the stack, Axios will automatically inherit the polluted validateStatus function during config merge. The in operator in mergeDirectKeys makes this property uniquely susceptible to prototype pollution compared to all other config properties.

Why `validateStatus` Is Uniquely Vulnerable

All other config properties use defaultToConfig2, which reads config2[prop] (traverses prototype). But validateStatus uses mergeDirectKeys, which uses the in operator:

// mergeConfig.js:58-64 — mergeDirectKeys (ONLY used by validateStatus)
function mergeDirectKeys(a, b, prop) {
  if (prop in config2) {           // ← `in` traverses prototype chain!
    return getMergedValue(a, b);
  } else if (prop in config1) {
    return getMergedValue(undefined, a);
  }
}

// mergeConfig.js:94
const mergeMap = {
  // ... all others use defaultToConfig2 ...
  validateStatus: mergeDirectKeys,   // ← ONLY property using this strategy
};

The in operator is a more aggressive prototype traversal than property access. While config2['validateStatus'] also traverses the prototype, the explicit in check makes the intent clearer and the vulnerability more direct.

Proof of Concept

1. The Setup (Simulated Pollution)

Object.prototype.validateStatus = () => true;

2. The Gadget Trigger (Safe Code)

// Application checks authentication via HTTP status codes
try {
  const response = await axios.get('https://api.internal/admin/users');
  // Developer expects: 401 → catch block → redirect to login
  // Reality: 401 → treated as success → displays admin data
  processAdminData(response.data);  // Executes with 401 response body!
} catch (error) {
  redirectToLogin();  // NEVER REACHED for 401/403/500
}

3. The Execution

// mergeConfig.js:58 — 'validateStatus' in config2
// config2 = { url: '/admin/users', method: 'get' }
// 'validateStatus' in config2 → checks prototype → finds () => true → TRUE
// → getMergedValue(defaultValidator, () => true) → returns () => true

// settle.js:16 — ALL status codes resolve
const validateStatus = response.config.validateStatus;  // () => true
if (!response.status || !validateStatus || validateStatus(response.status)) {
  resolve(response);  // 401, 403, 500 all resolve here!
}

4. The Impact

Before pollution:
  HTTP 200 → resolve (success)
  HTTP 401 → reject (auth error) → redirectToLogin()
  HTTP 403 → reject (forbidden) → showAccessDenied()
  HTTP 500 → reject (server error) → showErrorPage()

After pollution:
  HTTP 200 → resolve (success)
  HTTP 401 → resolve (SUCCESS!) → processAdminData() with error body
  HTTP 403 → resolve (SUCCESS!) → application thinks user has access
  HTTP 500 → resolve (SUCCESS!) → application processes error as data

Verified PoC Output

--- Before Pollution ---
401: REJECTED as expected - Request failed with status code 401
500: REJECTED as expected - Request failed with status code 500

--- After Pollution ---
200: RESOLVED as success (status: 200)
301: RESOLVED as success (status: 301)
401: RESOLVED as success (status: 401)
403: RESOLVED as success (status: 403)
404: RESOLVED as success (status: 404)
500: RESOLVED as success (status: 500)
503: RESOLVED as success (status: 503)

--- Authentication Bypass Demo ---
Auth check bypassed! 401 treated as success.
Application proceeds with: { status: 401, message: 'Response with status 401' }

Impact Analysis

Authentication Bypass: Applications relying on axios rejecting 401/403 to enforce auth will silently accept unauthorized responses, allowing unauthenticated access to protected resources.
Silent Error Swallowing: 500-series errors are treated as success, causing applications to process error bodies as valid data — leading to data corruption or logic errors.
Security Control Bypass: Rate limiting (429), WAF blocks (403), and CAPTCHA challenges are suppressed.
Universal Scope: Affects every axios instance in the application, including third-party libraries.

Recommended Fix

Replace the in operator with hasOwnProperty in mergeDirectKeys:

// FIXED: lib/core/mergeConfig.js
function mergeDirectKeys(a, b, prop) {
  if (Object.prototype.hasOwnProperty.call(config2, prop)) {
    return getMergedValue(a, b);
  } else if (Object.prototype.hasOwnProperty.call(config1, prop)) {
    return getMergedValue(undefined, a);
  }
}

Resources

Timeline

Date	Event
2026-04-15	Vulnerability discovered during source code audit
2026-04-15	PoC developed and vulnerability confirmed
2026-04-16	Report revised for accuracy
TBD	Report submitted to vendor via GitHub Security Advisory

Severity

4.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42041"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T00:21:39Z",
    "nvd_published_at": "2026-04-24T18:16:31Z",
    "severity": "MODERATE"
  },
  "details": "# Vulnerability Disclosure: Authentication Bypass via Prototype Pollution Gadget in `validateStatus` Merge Strategy\n\n## Summary\n\nThe Axios library is vulnerable to a Prototype Pollution \"Gadget\" attack that allows any `Object.prototype` pollution to **silently suppress all HTTP error responses** (401, 403, 500, etc.), causing them to be treated as successful responses. This completely bypasses application-level authentication and error handling.\n\nThe root cause is that `validateStatus` is the **only** config property using the `mergeDirectKeys` merge strategy, which uses JavaScript\u0027s `in` operator \u2014 an operator that inherently traverses the prototype chain. When `Object.prototype.validateStatus` is polluted with `() =\u003e true`, all HTTP status codes are accepted as success.\n\n**Severity:** High (CVSS 8.2)\n**Affected Versions:** All versions (v0.x - v1.x including v1.15.0)\n**Vulnerable Component:** `lib/core/mergeConfig.js` (`mergeDirectKeys` strategy) + `lib/core/settle.js`\n\n## CWE\n\n- **CWE-1321:** Improperly Controlled Modification of Object Prototype Attributes (\u0027Prototype Pollution\u0027)\n- **CWE-287:** Improper Authentication\n\n## CVSS 3.1\n\n**Score: 8.2 (High)**\n\nVector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N`\n\n| Metric | Value | Justification |\n|---|---|---|\n| Attack Vector | Network | PP is triggered remotely |\n| Attack Complexity | Low | Once PP exists, a single property assignment exploits this. Consistent with GHSA-fvcv-3m26-pcqx |\n| Privileges Required | None | No authentication needed |\n| User Interaction | None | No user interaction required |\n| Scope | Unchanged | Impact within the application |\n| Confidentiality | Low | 401 treated as success may expose data behind auth gates |\n| Integrity | High | All error handling and auth checks are silently bypassed \u2014 application operates on invalid assumptions |\n| Availability | None | The function works correctly (returns true), no crash |\n\n## Usage of \"Helper\" Vulnerabilities\n\nThis vulnerability requires **Zero Direct User Input**.\n\nIf an attacker can pollute `Object.prototype` via any other library in the stack, Axios will automatically inherit the polluted `validateStatus` function during config merge. The `in` operator in `mergeDirectKeys` makes this property **uniquely susceptible** to prototype pollution compared to all other config properties.\n\n## Why `validateStatus` Is Uniquely Vulnerable\n\nAll other config properties use `defaultToConfig2`, which reads `config2[prop]` (traverses prototype). But `validateStatus` uses `mergeDirectKeys`, which uses the `in` operator:\n\n```javascript\n// mergeConfig.js:58-64 \u2014 mergeDirectKeys (ONLY used by validateStatus)\nfunction mergeDirectKeys(a, b, prop) {\n  if (prop in config2) {           // \u2190 `in` traverses prototype chain!\n    return getMergedValue(a, b);\n  } else if (prop in config1) {\n    return getMergedValue(undefined, a);\n  }\n}\n\n// mergeConfig.js:94\nconst mergeMap = {\n  // ... all others use defaultToConfig2 ...\n  validateStatus: mergeDirectKeys,   // \u2190 ONLY property using this strategy\n};\n```\n\nThe `in` operator is a **more aggressive** prototype traversal than property access. While `config2[\u0027validateStatus\u0027]` also traverses the prototype, the explicit `in` check makes the intent clearer and the vulnerability more direct.\n\n## Proof of Concept\n\n### 1. The Setup (Simulated Pollution)\n\n```javascript\nObject.prototype.validateStatus = () =\u003e true;\n```\n\n### 2. The Gadget Trigger (Safe Code)\n\n```javascript\n// Application checks authentication via HTTP status codes\ntry {\n  const response = await axios.get(\u0027https://api.internal/admin/users\u0027);\n  // Developer expects: 401 \u2192 catch block \u2192 redirect to login\n  // Reality: 401 \u2192 treated as success \u2192 displays admin data\n  processAdminData(response.data);  // Executes with 401 response body!\n} catch (error) {\n  redirectToLogin();  // NEVER REACHED for 401/403/500\n}\n```\n\n### 3. The Execution\n\n```javascript\n// mergeConfig.js:58 \u2014 \u0027validateStatus\u0027 in config2\n// config2 = { url: \u0027/admin/users\u0027, method: \u0027get\u0027 }\n// \u0027validateStatus\u0027 in config2 \u2192 checks prototype \u2192 finds () =\u003e true \u2192 TRUE\n// \u2192 getMergedValue(defaultValidator, () =\u003e true) \u2192 returns () =\u003e true\n\n// settle.js:16 \u2014 ALL status codes resolve\nconst validateStatus = response.config.validateStatus;  // () =\u003e true\nif (!response.status || !validateStatus || validateStatus(response.status)) {\n  resolve(response);  // 401, 403, 500 all resolve here!\n}\n```\n\n### 4. The Impact\n\n```\nBefore pollution:\n  HTTP 200 \u2192 resolve (success)\n  HTTP 401 \u2192 reject (auth error) \u2192 redirectToLogin()\n  HTTP 403 \u2192 reject (forbidden) \u2192 showAccessDenied()\n  HTTP 500 \u2192 reject (server error) \u2192 showErrorPage()\n\nAfter pollution:\n  HTTP 200 \u2192 resolve (success)\n  HTTP 401 \u2192 resolve (SUCCESS!) \u2192 processAdminData() with error body\n  HTTP 403 \u2192 resolve (SUCCESS!) \u2192 application thinks user has access\n  HTTP 500 \u2192 resolve (SUCCESS!) \u2192 application processes error as data\n```\n\n## Verified PoC Output\n\n```\n--- Before Pollution ---\n401: REJECTED as expected - Request failed with status code 401\n500: REJECTED as expected - Request failed with status code 500\n\n--- After Pollution ---\n200: RESOLVED as success (status: 200)\n301: RESOLVED as success (status: 301)\n401: RESOLVED as success (status: 401)\n403: RESOLVED as success (status: 403)\n404: RESOLVED as success (status: 404)\n500: RESOLVED as success (status: 500)\n503: RESOLVED as success (status: 503)\n\n--- Authentication Bypass Demo ---\nAuth check bypassed! 401 treated as success.\nApplication proceeds with: { status: 401, message: \u0027Response with status 401\u0027 }\n```\n\n## Impact Analysis\n\n- **Authentication Bypass:** Applications relying on axios rejecting 401/403 to enforce auth will silently accept unauthorized responses, allowing unauthenticated access to protected resources.\n- **Silent Error Swallowing:** 500-series errors are treated as success, causing applications to process error bodies as valid data \u2014 leading to data corruption or logic errors.\n- **Security Control Bypass:** Rate limiting (429), WAF blocks (403), and CAPTCHA challenges are suppressed.\n- **Universal Scope:** Affects every axios instance in the application, including third-party libraries.\n\n## Recommended Fix\n\nReplace the `in` operator with `hasOwnProperty` in `mergeDirectKeys`:\n\n```javascript\n// FIXED: lib/core/mergeConfig.js\nfunction mergeDirectKeys(a, b, prop) {\n  if (Object.prototype.hasOwnProperty.call(config2, prop)) {\n    return getMergedValue(a, b);\n  } else if (Object.prototype.hasOwnProperty.call(config1, prop)) {\n    return getMergedValue(undefined, a);\n  }\n}\n```\n\n## Resources\n\n- [CWE-1321: Prototype Pollution](https://cwe.mitre.org/data/definitions/1321.html)\n- [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html)\n- [GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios](https://github.com/advisories/GHSA-fvcv-3m26-pcqx)\n- [MDN: `in` operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/in)\n- [Axios GitHub Repository](https://github.com/axios/axios)\n\n## Timeline\n\n| Date | Event |\n|---|---|\n| 2026-04-15 | Vulnerability discovered during source code audit |\n| 2026-04-15 | PoC developed and vulnerability confirmed |\n| 2026-04-16 | Report revised for accuracy |\n| TBD | Report submitted to vendor via GitHub Security Advisory |",
  "id": "GHSA-w9j2-pvgh-6h63",
  "modified": "2026-05-05T00:21:40Z",
  "published": "2026-05-05T00:21:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-w9j2-pvgh-6h63"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42041"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    }
  ],
  "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"
    }
  ],
  "summary": "Axios: Authentication Bypass via Prototype Pollution Gadget in `validateStatus` Merge Strategy"
}

GHSA-W9PP-R77P-J4P3

Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2022-05-24 17:47

Details

A vulnerability of Helpcom could allow an unauthenticated attacker to execute arbitrary command. This vulnerability exists due to insufficient authentication validation.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-7856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-20T13:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability of Helpcom could allow an unauthenticated attacker to execute arbitrary command. This vulnerability exists due to insufficient authentication validation.",
  "id": "GHSA-w9pp-r77p-j4p3",
  "modified": "2022-05-24T17:47:54Z",
  "published": "2022-05-24T17:47:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7856"
    },
    {
      "type": "WEB",
      "url": "https://www.boho.or.kr/krcert/secNoticeView.do?bulletin_writing_sequence=36003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-W9R3-R3V7-MCVC

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

Details

A vulnerability in the mesh code of Cisco Wireless LAN Controller (WLC) software could allow an unauthenticated, remote attacker to impersonate a WLC in a meshed topology. The vulnerability is due to insufficient authentication of the parent access point in a mesh configuration. An attacker could exploit this vulnerability by forcing the target system to disconnect from the correct parent access point and reconnect to a rogue access point owned by the attacker. An exploit could allow the attacker to control the traffic flowing through the impacted access point or take full control of the target system. This vulnerability affects the following products running a vulnerable version of Wireless LAN Controller software and configured for meshed mode: Cisco 8500 Series Wireless Controller, Cisco 5500 Series Wireless Controller, Cisco 2500 Series Wireless Controller, Cisco Flex 7500 Series Wireless Controller, Cisco Virtual Wireless Controller, Wireless Services Module 2 (WiSM2). Note that additional configuration is needed in addition to upgrading to a fixed release. Cisco Bug IDs: CSCuc98992 CSCuu14804.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-3854"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-15T20:59:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the mesh code of Cisco Wireless LAN Controller (WLC) software could allow an unauthenticated, remote attacker to impersonate a WLC in a meshed topology. The vulnerability is due to insufficient authentication of the parent access point in a mesh configuration. An attacker could exploit this vulnerability by forcing the target system to disconnect from the correct parent access point and reconnect to a rogue access point owned by the attacker. An exploit could allow the attacker to control the traffic flowing through the impacted access point or take full control of the target system. This vulnerability affects the following products running a vulnerable version of Wireless LAN Controller software and configured for meshed mode: Cisco 8500 Series Wireless Controller, Cisco 5500 Series Wireless Controller, Cisco 2500 Series Wireless Controller, Cisco Flex 7500 Series Wireless Controller, Cisco Virtual Wireless Controller, Wireless Services Module 2 (WiSM2). Note that additional configuration is needed in addition to upgrading to a fixed release. Cisco Bug IDs: CSCuc98992 CSCuu14804.",
  "id": "GHSA-w9r3-r3v7-mcvc",
  "modified": "2022-05-13T01:05:57Z",
  "published": "2022-05-13T01:05:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3854"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170315-wlc-mesh"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96911"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038041"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W9VH-HV5G-7WMR

Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2024-09-11 21:32

Summary

SaToken authentication bypass vulnerability

Details

An issue in Dromara SaToken version 1.3.50RC and before when using Spring dynamic controllers, a specially crafted request may cause an authentication bypass.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cn.dev33:sa-token-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.36.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-43961"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-27T19:49:44Z",
    "nvd_published_at": "2023-10-25T18:17:32Z",
    "severity": "HIGH"
  },
  "details": "An issue in Dromara SaToken version 1.3.50RC and before when using Spring dynamic controllers, a specially crafted request may cause an authentication bypass.",
  "id": "GHSA-w9vh-hv5g-7wmr",
  "modified": "2024-09-11T21:32:36Z",
  "published": "2023-10-25T18:32:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43961"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dromara/Sa-Token/issues/511"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dromara/Sa-Token"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SaToken authentication bypass vulnerability"
}

GHSA-WC42-38JG-6FV2

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

Details

OpenEvidence 1.0.6 and earlier 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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2009-0048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-01-07T18:30:00Z",
    "severity": "MODERATE"
  },
  "details": "OpenEvidence 1.0.6 and earlier 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-wc42-38jg-6fv2",
  "modified": "2022-05-02T03:12:32Z",
  "published": "2022-05-02T03:12:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0048"
    },
    {
      "type": "WEB",
      "url": "http://www.ocert.org/advisories/ocert-2008-016.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/499827/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/0047"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WC43-73W7-X2F5

Vulnerability from github – Published: 2024-09-26 17:49 – Updated: 2024-09-26 21:11

Summary

Ory Kratos's setting required_aal `highest_available` does not properly respect code + mfa credentials

Details

Preconditions

The code login method is enabled with the passwordless_enabled flag set to true .
A 2FA method such as totp is enabled.
required_aal of the whomai check or the settings flow is set to highest_available. AAL stands for Authenticator Assurance Levels and can range from 0 (no factor) to 2 (two factors).
A user uses the code method as the only login method available. They do not have a password or any other first factor credential enabled.
The user has 2FA enabled.
The user’s available_aal is incorrectly stored in the database as aal1 or aal0 or NULL.
A user signs in using the code method, but does not complete the 2FA challenge.

Example server configuration

Below you will find an vulnerable example configuration. Keep in mind that, for the account to be vulnerable, the account must have no first factor except the code method enabled plus a second factor.

selfservice:
  methods:
    code:
      # The `code` login method is enabled with the `passwordless_enabled` flag set to `true`
      passwordless_enabled: true
    totp:
      # 2FA method such as `totp` is enabled
      enabled: true
  flows:
    settings:
      # This is set
      required_aal: highest_available
session:
  whoami:
    # Or this
    required_aal: highest_available

Impact

Given the preconditions, the highest_available setting will incorrectly assume that the identity’s highest available AAL is aal1 even though it really is aal2. This means that the highest_available configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a aal2 session, even though that should be disallowed.

An attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect available_aal value stored, to exploit this vulnerability.

All other aspects of the session (e.g. the session’s aal) are not impacted by this issue.

On Ory Network, only 0,00066% of registered users were affected by this issue, and most of those users appeared to be test users. Their respective AAL values have since been updated and they are no longer vulnerable to this attack.

Patches

Version 1.3.0 is not affected by this issue.

Workarounds

If you require 2FA please disable the passwordless code login method. If that is not possible, check the sessions aal to identify if the user has aal1 or aal2.

Severity

4.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N

5.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.2.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ory/kratos"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-26T17:49:17Z",
    "nvd_published_at": "2024-09-26T18:15:07Z",
    "severity": "MODERATE"
  },
  "details": "## Preconditions\n\n- The `code` login method is enabled with the `passwordless_enabled` flag set to `true` .\n- A 2FA method such as `totp` is enabled.\n- `required_aal` of the whomai check or the settings flow is set to `highest_available`. AAL stands for Authenticator Assurance Levels and can range from 0 (no factor) to 2 (two factors).\n- A user uses the `code` method as the **only** login method available. They do not have a password or any other first factor credential enabled.\n- The user has 2FA enabled.\n- The user\u2019s `available_aal` is incorrectly stored in the database as `aal1` or `aal0` or `NULL`.\n- A user signs in using the code method, but does not complete the 2FA challenge.\n\n**Example server configuration**\n\nBelow you will find an vulnerable example configuration. Keep in mind that, for the account to be vulnerable, the account must have no first factor except the `code` method enabled plus a second factor.\n\n```\nselfservice:\n  methods:\n    code:\n      # The `code` login method is enabled with the `passwordless_enabled` flag set to `true`\n      passwordless_enabled: true\n    totp:\n      # 2FA method such as `totp` is enabled\n      enabled: true\n  flows:\n    settings:\n      # This is set\n      required_aal: highest_available\nsession:\n  whoami:\n    # Or this\n    required_aal: highest_available\n```\n\n## Impact\n\nGiven the preconditions, the `highest_available` setting will incorrectly assume that the identity\u2019s highest available AAL is `aal1` even though it really is `aal2`. This means that the `highest_available` configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a `aal2` session, even though that should be disallowed.\n\nAn attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect `available_aal` value stored, to exploit this vulnerability.\n\nAll other aspects of the session (e.g. the session\u2019s aal) are not impacted by this issue.\n\nOn Ory Network, only 0,00066% of registered users were affected by this issue, and most of those users appeared to be test users. Their respective AAL values have since been updated and they are no longer vulnerable to this attack.\n\n### Patches\n\nVersion 1.3.0 is not affected by this issue.\n\n### Workarounds\n\nIf you require 2FA please disable the passwordless code login method. If that is not possible, check the sessions `aal` to identify if the user has `aal1` or `aal2`.",
  "id": "GHSA-wc43-73w7-x2f5",
  "modified": "2024-09-26T21:11:01Z",
  "published": "2024-09-26T17:49:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ory/kratos/security/advisories/GHSA-wc43-73w7-x2f5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45042"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ory/kratos"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ory Kratos\u0027s setting required_aal `highest_available` does not properly respect code + mfa credentials"
}

GHSA-WC79-7X8X-2P58

Vulnerability from github – Published: 2025-03-03 19:56 – Updated: 2025-03-03 19:56

Summary

MinIO allows an SFTP authentication bypass due to improperly trusted SSH key

Details

Summary

A bug in evaluating the trust of the SSH key used in an SFTP connection to MinIO allows authentication bypass and unauthorized data access.

Details

On a MinIO server with SFTP access configured and using LDAP as an external identity provider, MinIO supports SSH key based authentication for SFTP connections when the user has the sshPublicKey attribute set in their LDAP server. The server trusts the client's key only when the public key is the same as the sshPublicKey attribute.

Due to the bug, when the user has no sshPublicKey property in LDAP, the server ends up trusting the key allowing the client to perform any FTP operations allowed by the MinIO access policies associated with the LDAP user (or any of their groups).

The bug was introduced in https://github.com/minio/minio/commit/91e1487de45720753c9e9e4c02b1bd16b7e452fa.

Impact

The following requirements must be met to exploit this vulnerability:

MinIO server must be configured to allow SFTP access and use LDAP as an external identity provider.
Knowledge of an LDAP username that does not have the sshPublicKey property set.
Such an LDAP username or one of their groups must also have some MinIO access policy configured.

When this bug is successfully exploited, the attacker can perform any FTP operations (i.e. reading, writing, deleting and listing objects) allowed by the access policy associated with the LDAP user account (and their groups).

Severity

6.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/minio/minio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-20240605075113-91e1487de457"
            },
            {
              "fixed": "0.0.0-20250227184332-4c71f1b4ec0f"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-03T19:56:58Z",
    "nvd_published_at": "2025-02-28T21:15:27Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n_A bug in evaluating the trust of the SSH key used in an SFTP connection to MinIO allows authentication bypass and unauthorized data access._\n\n### Details\n\nOn a MinIO server with SFTP access configured and using LDAP as an external identity provider, MinIO supports SSH key based authentication for SFTP connections when the user has the `sshPublicKey` attribute set in their LDAP server. The server trusts the client\u0027s key only when the public key is the same as the `sshPublicKey` attribute.\n\nDue to the bug, when the user has no `sshPublicKey` property in LDAP, the server ends up trusting the key allowing the client to perform any FTP operations allowed by the MinIO access policies associated with the LDAP user (or any of their groups).\n\nThe bug was introduced in https://github.com/minio/minio/commit/91e1487de45720753c9e9e4c02b1bd16b7e452fa.\n\n### Impact\n\nThe following requirements must be met to exploit this vulnerability:\n\n1. MinIO server must be configured to allow SFTP access and use LDAP as an external identity provider.\n2. Knowledge of an LDAP username that does not have the `sshPublicKey` property set.\n3. Such an LDAP username or one of their groups must also have some MinIO access policy configured.\n\nWhen this bug is successfully exploited, the attacker can perform any FTP operations (i.e. reading, writing, deleting and listing objects) allowed by the access policy associated with the LDAP user account (and their groups).",
  "id": "GHSA-wc79-7x8x-2p58",
  "modified": "2025-03-03T19:56:58Z",
  "published": "2025-03-03T19:56:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/minio/minio/security/advisories/GHSA-wc79-7x8x-2p58"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27414"
    },
    {
      "type": "WEB",
      "url": "https://github.com/minio/minio/commit/4c71f1b4ec0fb2a473ddaac18c20ec9e63f267ec"
    },
    {
      "type": "WEB",
      "url": "https://github.com/minio/minio/commit/91e1487de45720753c9e9e4c02b1bd16b7e452fa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/minio/minio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MinIO allows an SFTP authentication bypass due to improperly trusted SSH key"
}

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.

← Back to the CWE list

CWE-287

Improper Authentication

Vulnerability Disclosure: Authentication Bypass via Prototype Pollution Gadget in validateStatus Merge Strategy

Summary

CWE

CVSS 3.1

Usage of "Helper" Vulnerabilities

Why validateStatus Is Uniquely Vulnerable

Proof of Concept

1. The Setup (Simulated Pollution)

2. The Gadget Trigger (Safe Code)

3. The Execution

4. The Impact

Verified PoC Output

Impact Analysis

Recommended Fix

Resources

Timeline

Preconditions

Impact

Patches

Workarounds

Summary

Details

Impact

Mitigation

CAPEC-114: Authentication Abuse

CAPEC-115: Authentication Bypass

CAPEC-151: Identity Spoofing

CAPEC-194: Fake the Source of Data

CAPEC-22: Exploiting Trust in Client

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

CAPEC-593: Session Hijacking

CAPEC-633: Token Impersonation

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

CAPEC-94: Adversary in the Middle (AiTM)

Vulnerability Disclosure: Authentication Bypass via Prototype Pollution Gadget in `validateStatus` Merge Strategy

Why `validateStatus` Is Uniquely Vulnerable