Common Weakness Enumeration

CWE-289

Allowed

Authentication Bypass by Alternate Name

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.

60 vulnerabilities reference this CWE, most recent first.

GHSA-HHW8-PPCX-3FJJ

Vulnerability from github – Published: 2023-08-14 06:30 – Updated: 2024-04-04 06:54
VLAI
Details

The Dataprobe iBoot PDU running firmware version 1.43.03312023 or earlier is vulnerable to authentication bypass in the REST API due to the mishandling of special characters when parsing credentials.Successful exploitation allows the malicious agent to obtain a valid authorization token and read information relating to the state of the relays and power distribution.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-3263"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-14T05:15:09Z",
    "severity": "HIGH"
  },
  "details": "The Dataprobe iBoot PDU running firmware version 1.43.03312023 or earlier is vulnerable to authentication bypass in the REST API due to the mishandling of special characters when parsing credentials.Successful exploitation allows the malicious agent to obtain a valid authorization token and read information relating to the state of the relays and power distribution.",
  "id": "GHSA-hhw8-ppcx-3fjj",
  "modified": "2024-04-04T06:54:35Z",
  "published": "2023-08-14T06:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3263"
    },
    {
      "type": "WEB",
      "url": "https://www.trellix.com/en-us/about/newsroom/stories/research/the-threat-lurking-in-data-centers.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MWXV-35WR-4VVJ

Vulnerability from github – Published: 2026-03-03 18:54 – Updated: 2026-03-20 21:12
VLAI
Summary
OpenClaw has gateway plugin auth bypass via encoded dot-segment traversal in protected /api/channels paths
Details

Summary

Gateway plugin route auth protection for /api/channels could be bypassed using encoded dot-segment traversal (for example ..%2f) in path variants that plugin handlers normalize.

Affected Packages / Versions

  • Package: npm openclaw
  • Latest published vulnerable version: 2026.2.25
  • Vulnerable version range: <= 2026.2.25
  • Patched version: 2026.2.26 (planned next release)

Impact

Under affected versions, crafted alternate paths could bypass gateway auth checks for protected plugin channel routes when plugin handlers decode/canonicalize the incoming path and then route to /api/channels/... handlers.

Fix Commit(s)

  • 258d615c45527ffda37cecd08cd268f97461bde0

Release Process Note

patched_versions is pre-set to the planned next release (2026.2.26). After npm publish, maintainers only need to publish the advisory.

OpenClaw thanks @zpbrent for reporting.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N
8.3 (High)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.25"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32036"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-289"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T18:54:35Z",
    "nvd_published_at": "2026-03-19T22:16:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nGateway plugin route auth protection for `/api/channels` could be bypassed using encoded dot-segment traversal (for example `..%2f`) in path variants that plugin handlers normalize.\n\n### Affected Packages / Versions\n- Package: npm `openclaw`\n- Latest published vulnerable version: `2026.2.25`\n- Vulnerable version range: `\u003c= 2026.2.25`\n- Patched version: `2026.2.26` (planned next release)\n\n### Impact\nUnder affected versions, crafted alternate paths could bypass gateway auth checks for protected plugin channel routes when plugin handlers decode/canonicalize the incoming path and then route to `/api/channels/...` handlers.\n\n### Fix Commit(s)\n- `258d615c45527ffda37cecd08cd268f97461bde0`\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.26`). After npm publish, maintainers only need to publish the advisory.\n\nOpenClaw thanks @zpbrent for reporting.",
  "id": "GHSA-mwxv-35wr-4vvj",
  "modified": "2026-03-20T21:12:44Z",
  "published": "2026-03-03T18:54:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-mwxv-35wr-4vvj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32036"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/258d615c45527ffda37cecd08cd268f97461bde0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authentication-bypass-via-encoded-dot-segment-traversal-in-api-channels"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has gateway plugin auth bypass via encoded dot-segment traversal in protected /api/channels paths"
}

GHSA-PCHF-49FH-W34R

Vulnerability from github – Published: 2026-01-21 23:02 – Updated: 2026-01-23 15:46
VLAI
Summary
Soft Serve Affected by an Authentication Bypass
Details

Impact

What kind of vulnerability is it? Who is impacted?

This issue impacts every Soft Serve instance.

A critical authentication bypass allows an attacker to impersonate any user (including Admin) by "offering" the victim's public key during the SSH handshake before authenticating with their own valid key. This occurs because the user identity is stored in the session context during the "offer" phase and is not cleared if that specific authentication attempt fails.

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, please upgrade to version 0.11.3 as soon as possible.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

You need to upgrade

Severity
8.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.11.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/charmbracelet/soft-serve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-21T23:02:07Z",
    "nvd_published_at": "2026-01-22T22:16:21Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nThis issue impacts every Soft Serve instance.\n\nA critical authentication bypass allows an attacker to impersonate any user (including Admin) by \"offering\" the victim\u0027s public key during the SSH handshake before authenticating with their own valid key. This occurs because the user identity is stored in the session context during the \"offer\" phase and is not cleared if that specific authentication attempt fails.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nYes, please upgrade to version 0.11.3 as soon as possible.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nYou need to upgrade",
  "id": "GHSA-pchf-49fh-w34r",
  "modified": "2026-01-23T15:46:52Z",
  "published": "2026-01-21T23:02:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-pchf-49fh-w34r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/commit/8539f9ad39918b67d612a35785a2b4326efc8741"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/charmbracelet/soft-serve"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/releases/tag/v0.11.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Soft Serve Affected by an Authentication Bypass"
}

GHSA-PJWM-PJ3P-43MV

Vulnerability from github – Published: 2026-05-29 15:59 – Updated: 2026-07-09 15:32
VLAI
Summary
axios's shouldBypassProxy does not recognize IPv4-mapped IPv6 addresses, allowing NO_PROXY bypass (incomplete fix for CVE-2025-62718)
Details

Summary

shouldBypassProxy, introduced in v1.15.0 to fix CVE-2025-62718, does not normalise IPv4-mapped IPv6 addresses. When NO_PROXY lists an IPv4 address such as 127.0.0.1 or 169.254.169.254, a request URL using the IPv4-mapped IPv6 form (::ffff:7f00:1, ::ffff:a9fe:a9fe) still routes through the configured proxy. Node.js resolves these addresses to the underlying IPv4 host, so the request reaches the internal service via the proxy rather than being blocked.

Details

lib/helpers/shouldBypassProxy.js (v1.15.0): 

  const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);                                                                                                      
  const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);                                                                                                                    

  // normalizeNoProxyHost strips brackets and trailing dots, but not ::ffff: prefix                                                                                             
  return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));

The WHATWG URL parser canonicalises http://[::ffff:127.0.0.1]/ to hostname [::ffff:7f00:1]. After bracket-stripping: ::ffff:7f00:1. This string does not match 127.0.0.1 in NO_PROXY and is not in LOOPBACK_ADDRESSES, so shouldBypassProxy returns false and the proxy is used. proxy-from-env (called before shouldBypassProxy) has the same gap - it does not equate ::ffff:7f00:1 with 127.0.0.1 - so neither layer catches the bypass.

PoC


// NO_PROXY=127.0.0.1,localhost,::1  HTTP_PROXY=http://attacker:8080
import shouldBypassProxy from 'axios/lib/helpers/shouldBypassProxy.js';                                                                                                       

// All three should return true (bypass proxy). Only the first two do.                                                                                                        
console.log(shouldBypassProxy('http://127.0.0.1/'));          // true  [OK]                                                                                                     
console.log(shouldBypassProxy('http://[::1]/'));               // true  [OK]                                                                                                     
console.log(shouldBypassProxy('http://[::ffff:127.0.0.1]/')); // false <- bypass                                                                                             
console.log(shouldBypassProxy('http://[::ffff:7f00:1]/'));     // false <- bypass

Node.js routes ::ffff:7f00:1 to 127.0.0.1: 

// net.connect({ host: '::ffff:7f00:1', port: 80 }) reaches a service                                                                                                       
// bound to 127.0.0.1:80 — confirmed on Node.js v24, Linux and macOS.

Cloud metadata SSRF: ::ffff:a9fe:a9fe = ::ffff:169.254.169.254. If NO_PROXY=169.254.169.254 is set to block IMDS access, a request to http://[::ffff:a9fe:a9fe]/latest/meta-data/ bypasses it.

Fix

Canonicalise IPv4-mapped IPv6 in normalizeNoProxyHost before any comparison:

```javascript
const ipv4MappedDotted = /^::ffff:(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})$/i;
const ipv4MappedHex = /^::ffff:([0-9a-f]{1,4}):([0-9a-f]{1,4})$/i;

function hexToIPv4(a, b) {
const hi = parseInt(a, 16), lo = parseInt(b, 16);
return ${hi >> 8}.${hi & 0xff}.${lo >> 8}.${lo & 0xff};
}

const normalizeNoProxyHost = (hostname) => {
if (!hostname) return hostname;
if (hostname[0] === '[' && hostname.at(-1) === ']') hostname = hostname.slice(1, -1);
hostname = hostname.replace(/.+$/, '').toLowerCase();

let m;
if ((m = hostname.match(ipv4MappedDotted))) return m[1];
if ((m = hostname.match(ipv4MappedHex))) return hexToIPv4(m[1], m[2]);
return hostname;
};

```

Impact

Any application that sets NO_PROXY to exclude internal or metadata endpoints and uses an HTTP/HTTPS proxy can have those exclusions bypassed by a URL using IPv4-mapped IPv6 notation. The attacker must control the request URL. In cloud environments with instance metadata services, this can lead to credential exfiltration.

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.15.0"
            },
            {
              "fixed": "1.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44492"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T15:59:30Z",
    "nvd_published_at": "2026-06-11T17:16:33Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nshouldBypassProxy, introduced in v1.15.0 to fix CVE-2025-62718, does not normalise IPv4-mapped IPv6 addresses. When NO_PROXY lists an IPv4 address such as `127.0.0.1` or `169.254.169.254`, a request URL using the IPv4-mapped IPv6 form (`::ffff:7f00:1`, `::ffff:a9fe:a9fe`) still routes through the configured proxy. Node.js resolves these addresses to the underlying IPv4 host, so the request reaches the internal service via the proxy rather than being blocked.\n\n### Details\nlib/helpers/shouldBypassProxy.js (v1.15.0):                                                                                                                                   \n\n```javascript                                                                                                                                                                              \n  const LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);                                                                                                      \n  const isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);                                                                                                                    \n                                                                                                                                                                                \n  // normalizeNoProxyHost strips brackets and trailing dots, but not ::ffff: prefix                                                                                             \n  return hostname === entryHost || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost));                                                                                             \n```\n                                                                                                                                                                                \nThe WHATWG URL parser canonicalises `http://[::ffff:127.0.0.1]/` to hostname `[::ffff:7f00:1]`. After bracket-stripping: `::ffff:7f00:1`. This string does not match 127.0.0.1 in NO_PROXY and is not in LOOPBACK_ADDRESSES, so shouldBypassProxy returns false and the proxy is used.  proxy-from-env (called before shouldBypassProxy) has the same gap - it does not equate ::ffff:7f00:1 with 127.0.0.1 - so neither layer catches the bypass.\n\n### PoC\n```javascript\n\n// NO_PROXY=127.0.0.1,localhost,::1  HTTP_PROXY=http://attacker:8080\nimport shouldBypassProxy from \u0027axios/lib/helpers/shouldBypassProxy.js\u0027;                                                                                                       \n                                                                                                                                                                              \n// All three should return true (bypass proxy). Only the first two do.                                                                                                        \nconsole.log(shouldBypassProxy(\u0027http://127.0.0.1/\u0027));          // true  [OK]                                                                                                     \nconsole.log(shouldBypassProxy(\u0027http://[::1]/\u0027));               // true  [OK]                                                                                                     \nconsole.log(shouldBypassProxy(\u0027http://[::ffff:127.0.0.1]/\u0027)); // false \u003c- bypass                                                                                             \nconsole.log(shouldBypassProxy(\u0027http://[::ffff:7f00:1]/\u0027));     // false \u003c- bypass\n\n```                                                                                              \n                                                                                                                                                                              \nNode.js routes ::ffff:7f00:1 to 127.0.0.1:                                                                                                                                    \n\n```                                                                                                                                                                              \n// net.connect({ host: \u0027::ffff:7f00:1\u0027, port: 80 }) reaches a service                                                                                                       \n// bound to 127.0.0.1:80 \u2014 confirmed on Node.js v24, Linux and macOS.                                                                                                         \n```                                                                                                                                                                              \nCloud metadata SSRF: ::ffff:a9fe:a9fe = ::ffff:169.254.169.254. If NO_PROXY=169.254.169.254 is set to block IMDS access, a request to http://[::ffff:a9fe:a9fe]/latest/meta-data/ bypasses it.                                                                                                                      \n                                                                                                                                                                            \n#### Fix                                                                                                                                                                           \n                                                                                                                                                                            \nCanonicalise IPv4-mapped IPv6 in normalizeNoProxyHost before any comparison:                                                                                                  \n \n ```javascript                                                                                                                                                                           \nconst ipv4MappedDotted = /^::ffff:(\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3})$/i;                                                                                                    \nconst ipv4MappedHex    = /^::ffff:([0-9a-f]{1,4}):([0-9a-f]{1,4})$/i;                                                                                                         \n                                                                                                                                                                              \nfunction hexToIPv4(a, b) {                                                                                                                                                    \n  const hi = parseInt(a, 16), lo = parseInt(b, 16);                                                                                                                           \n  return `${hi \u003e\u003e 8}.${hi \u0026 0xff}.${lo \u003e\u003e 8}.${lo \u0026 0xff}`;                                                                                                                   \n}                                                                                                                                                                             \n                                                                                                                                                                              \nconst normalizeNoProxyHost = (hostname) =\u003e {                                                                                                                                  \n  if (!hostname) return hostname;                                                                                                                                           \n  if (hostname[0] === \u0027[\u0027 \u0026\u0026 hostname.at(-1) === \u0027]\u0027)\n    hostname = hostname.slice(1, -1);                                                                                                                                         \n  hostname = hostname.replace(/\\.+$/, \u0027\u0027).toLowerCase();\n                                                                                                                                                                              \n  let m;                                                                                                                                                                    \n  if ((m = hostname.match(ipv4MappedDotted))) return m[1];                                                                                                                    \n  if ((m = hostname.match(ipv4MappedHex)))    return hexToIPv4(m[1], m[2]);                                                                                                   \n  return hostname;                                                                                                                                                            \n};\n\n```\n\n### Impact\nAny application that sets NO_PROXY to exclude internal or metadata endpoints and uses an HTTP/HTTPS proxy can have those exclusions bypassed by a URL using IPv4-mapped IPv6 notation. The attacker must control the request URL. In cloud environments with instance metadata services, this can lead to credential exfiltration.",
  "id": "GHSA-pjwm-pj3p-43mv",
  "modified": "2026-07-09T15:32:12Z",
  "published": "2026-05-29T15:59:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-pjwm-pj3p-43mv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44492"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62718"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44492.json"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2487938"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-44492"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36883"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36882"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36820"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36754"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36108"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:34766"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33574"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33183"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33173"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33163"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33160"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33155"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33005"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30651"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30650"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:29197"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:29082"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:28964"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:27063"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:27044"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26234"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20938"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20889"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "axios\u0027s shouldBypassProxy does not recognize IPv4-mapped IPv6 addresses, allowing NO_PROXY bypass (incomplete fix for CVE-2025-62718)"
}

GHSA-PRV7-JRRF-HWVC

Vulnerability from github – Published: 2025-12-10 03:30 – Updated: 2025-12-10 03:30
VLAI
Details

The Elated Membership plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 1.2. This is due to the plugin not properly logging in a user with the data that was previously verified through the 'eltdf_membership_check_facebook_user' and the 'eltdf_membership_login_user_from_social_network' function. This makes it possible for unauthenticated attackers to log in as administrative users, as long as they have an existing account on the site which can easily be created by default through the temp user functionality, and access to the administrative user's email.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-13613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-10T03:15:46Z",
    "severity": "CRITICAL"
  },
  "details": "The Elated Membership plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 1.2. This is due to the plugin not properly logging in a user with the data that was previously verified through the \u0027eltdf_membership_check_facebook_user\u0027 and the \u0027eltdf_membership_login_user_from_social_network\u0027 function. This makes it possible for unauthenticated attackers to log in as administrative users, as long as they have an existing account on the site which can easily be created by default through the temp user functionality, and access to the administrative user\u0027s email.",
  "id": "GHSA-prv7-jrrf-hwvc",
  "modified": "2025-12-10T03:30:29Z",
  "published": "2025-12-10T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13613"
    },
    {
      "type": "WEB",
      "url": "https://themeforest.net/item/esmarts-a-modern-education-and-lms-theme/20987760"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f15dbce4-2e94-4735-b62b-e32d923c51ce?source=cve"
    }
  ],
  "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-QHRF-5RV2-GPH8

Vulnerability from github – Published: 2026-07-08 06:31 – Updated: 2026-07-08 06:31
VLAI
Details

The Eventer plugin for WordPress is vulnerable to an insecure password reset mechanism in all versions up to, and including, 4.4.2. The plugin stores a plaintext copy of the password reset key in the eventer_verification_code user meta field when a user requests a password reset. The plaintext key stored in wp_usermeta can be used with the plugin's custom reset action to set a new password for any user. Combined with another vulnerability such as SQL Injection (CVE-2026-9700), this makes it possible for unauthenticated attackers to extract the plaintext reset key and take over any user account, including administrators. Note: The password reset function only works up to PHP version 7.4.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-9701"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-08T05:16:28Z",
    "severity": "CRITICAL"
  },
  "details": "The Eventer plugin for WordPress is vulnerable to an insecure password reset mechanism in all versions up to, and including, 4.4.2. The plugin stores a plaintext copy of the password reset key in the `eventer_verification_code` user meta field when a user requests a password reset. The plaintext key stored in `wp_usermeta` can be used with the plugin\u0027s custom reset action to set a new password for any user. Combined with another vulnerability such as SQL Injection (CVE-2026-9700), this makes it possible for unauthenticated attackers to extract the plaintext reset key and take over any user account, including administrators. Note: The password reset function only works up to PHP version 7.4.",
  "id": "GHSA-qhrf-5rv2-gph8",
  "modified": "2026-07-08T06:31:35Z",
  "published": "2026-07-08T06:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9701"
    },
    {
      "type": "WEB",
      "url": "https://codecanyon.net/item/eventer-wordpress-event-manager-plugin/20972534"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/bc656765-1eac-4a96-99e9-c22d64984923?source=cve"
    }
  ],
  "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-QJ64-JJ84-W38J

Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-06-25 09:31
VLAI
Details

When using Apache Shiro with the shiro-guice module in a web servlet context, a specially crafted HTTP request may cause an authentication bypass. This vulnerability is similar to https://www.cve.org/CVERecord?id=CVE-2020-1957 https://www.cve.org/CVERecord , except that it affects the shiro-guice module instead of the shiro-spring module.

This issue affects all Apache Shiro versions through 2.x, and 3.0.0-alpha-1 only when using shiro-guice module in a web servlet context.

Upgrade to version 3.0.0 or later, which fixes the issue.

Severity
8.2 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/S:P/AU:Y/V:D/RE:L/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-56091"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T09:16:46Z",
    "severity": "HIGH"
  },
  "details": "When using Apache Shiro with the shiro-guice module in a web servlet context, a specially crafted HTTP request may cause an authentication bypass.\nThis vulnerability is similar to  https://www.cve.org/CVERecord?id=CVE-2020-1957 https://www.cve.org/CVERecord , except that it affects the `shiro-guice` module instead of the `shiro-spring` module.\n\nThis issue affects all Apache Shiro versions through 2.x, and 3.0.0-alpha-1 only when using `shiro-guice` module in a web servlet context.\n\nUpgrade to version 3.0.0 or later, which fixes the issue.",
  "id": "GHSA-qj64-jj84-w38j",
  "modified": "2026-06-25T09:31:23Z",
  "published": "2026-06-25T09:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56091"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/onmtxmy2qonbpx7xlw3o34x8sctv47r7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:P/AU:Y/R:X/V:D/RE:L/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-QP7R-5RPF-PWXG

Vulnerability from github – Published: 2026-04-03 21:31 – Updated: 2026-04-23 18:32
VLAI
Details

A flaw was found in util-linux. Improper hostname canonicalization in the login(1) utility, when invoked with the -h option, can modify the supplied remote hostname before setting PAM_RHOST. A remote attacker could exploit this by providing a specially crafted hostname, potentially bypassing host-based Pluggable Authentication Modules (PAM) access control rules that rely on fully qualified domain names. This could lead to unauthorized access.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-3184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-03T19:17:23Z",
    "severity": "LOW"
  },
  "details": "A flaw was found in util-linux. Improper hostname canonicalization in the `login(1)` utility, when invoked with the `-h` option, can modify the supplied remote hostname before setting `PAM_RHOST`. A remote attacker could exploit this by providing a specially crafted hostname, potentially bypassing host-based Pluggable Authentication Modules (PAM) access control rules that rely on fully qualified domain names. This could lead to unauthorized access.",
  "id": "GHSA-qp7r-5rpf-pwxg",
  "modified": "2026-04-23T18:32:55Z",
  "published": "2026-04-03T21:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3184"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:7180"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-3184"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2442570"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XFV7-H2QG-RJM7

Vulnerability from github – Published: 2024-11-20 12:30 – Updated: 2024-11-20 21:45
VLAI
Summary
Moodle Lesson activity password bypass through PHP loose comparison
Details

A flaw was found in Moodle. When restricting access to a lesson activity with a password, certain passwords could be bypassed or less secure due to a loose comparison in the password-checking logic. This issue only affected passwords set to "magic hash" values.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0-beta"
            },
            {
              "fixed": "4.2.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0-beta"
            },
            {
              "fixed": "4.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0-beta"
            },
            {
              "fixed": "4.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-289"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-20T18:25:26Z",
    "nvd_published_at": "2024-11-20T11:15:05Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Moodle. When restricting access to a lesson activity with a password, certain passwords could be bypassed or less secure due to a loose comparison in the password-checking logic. This issue only affected passwords set to \"magic hash\" values.",
  "id": "GHSA-xfv7-h2qg-rjm7",
  "modified": "2024-11-20T21:45:02Z",
  "published": "2024-11-20T12:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45691"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/3fc1073d304f660d2552b591c5fb92547ed01e92"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2309940"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=461897#p1854494"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Moodle Lesson activity password bypass through PHP loose comparison"
}

GHSA-XR73-JQ5P-CH8R

Vulnerability from github – Published: 2025-11-19 18:13 – Updated: 2025-11-19 18:59
VLAI
Summary
authentik allows a deactivated Service account to authenticate to OAuth
Details

Summary

When authenticating with client_id and client_secret to an OAuth provider, authentik creates a service account for the provider. In previous authentik versions, authentication for this account was possible even when the account was deactivated. Other permissions are correctly applied and federation with other providers still take assigned policies correctly into account.

Patches

authentik 2025.8.5 and 2025.10.2 fix this issue, for other versions the workaround below can be used.

Workarounds

You can add a policy to your application that explicitly checks if the service account is still valid, and deny access if not.

return request.user.is_active

For more information

If you have any questions or comments about this advisory:

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "goauthentik.io"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20251119140106-9dbdfc3f1be0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64521"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-286",
      "CWE-289"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-19T18:13:03Z",
    "nvd_published_at": "2025-11-19T17:15:52Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen authenticating with `client_id` and `client_secret` to an OAuth provider, authentik creates a service account for the provider. In previous authentik versions, authentication for this account was possible even when the account was deactivated. Other permissions are correctly applied and federation with other providers still take assigned policies correctly into account.\n\n### Patches\n\nauthentik 2025.8.5 and 2025.10.2 fix this issue, for other versions the workaround below can be used.\n\n### Workarounds\n\nYou can add a policy to your application that explicitly checks if the service account is still valid, and deny access if not.\n\n```python\nreturn request.user.is_active\n```\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Email us at [security@goauthentik.io](mailto:security@goauthentik.io).",
  "id": "GHSA-xr73-jq5p-ch8r",
  "modified": "2025-11-19T18:59:53Z",
  "published": "2025-11-19T18:13:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/goauthentik/authentik/security/advisories/GHSA-xr73-jq5p-ch8r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64521"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goauthentik/authentik/commit/9dbdfc3f1be0f1be36f8efce2442897b2a54a71c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/goauthentik/authentik"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "authentik allows a deactivated Service account to authenticate to OAuth"
}
Mitigation MIT-44
Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-20
Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list