Common Weakness Enumeration

CWE-41

Allowed

Improper Resolution of Path Equivalence

Abstraction: Base · Status: Incomplete

The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.

53 vulnerabilities reference this CWE, most recent first.

GHSA-W4H3-GPV2-82QC

Vulnerability from github – Published: 2026-04-01 18:36 – Updated: 2026-04-01 18:36
VLAI
Details

OpenClaw before 2026.3.22 contains a path traversal vulnerability in Windows media loaders that accepts remote-host file URLs and UNC-style paths before local-path validation. Attackers can exploit this by providing network-hosted file targets that are treated as local content, bypassing intended access restrictions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-34510"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-41"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-01T16:23:50Z",
    "severity": "MODERATE"
  },
  "details": "OpenClaw before 2026.3.22 contains a path traversal vulnerability in Windows media loaders that accepts remote-host file URLs and UNC-style paths before local-path validation. Attackers can exploit this by providing network-hosted file targets that are treated as local content, bypassing intended access restrictions.",
  "id": "GHSA-w4h3-gpv2-82qc",
  "modified": "2026-04-01T18:36:36Z",
  "published": "2026-04-01T18:36:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-h3x4-hc5v-v2gm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34510"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/4fd7feb0fd4ec16c48ed983980dba79a09b3aaf5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/93880717f1cd34feaa45e74e939b7a5256288901"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-remote-file-url-acceptance-in-windows-media-loaders"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/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:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-X732-6J76-QMHM

Vulnerability from github – Published: 2025-12-16 21:22 – Updated: 2025-12-16 21:22
VLAI
Summary
Better Auth's rou3 Dependency has Double-Slash Path Normalization which can Bypass disabledPaths Config and Rate Limits
Details

Summary

An issue in the underlying router library rou3 can cause /path and //path to be treated as identical routes. If your environment does not normalize incoming URLs (e.g., by collapsing multiple slashes), this can allow bypasses of disabledPaths and path-based rate limits.

Details

Better Auth uses better-call, which internally relies on rou3 for routing. Affected versions of rou3 normalize paths by removing empty segments. As a result:

  • /sign-in/email
  • //sign-in/email
  • ///sign-in/email

…all resolve to the same route.

Some production setups automatically collapse multiple slashes. This includes:

  • Vercel with Nextjs (default)
  • Cloudflare - when normalize to urls origin is enabled (https://developers.cloudflare.com/rules/normalization/settings/#normalize-urls-to-origin)

In these environments and other configurations where //path reach Better Auth as /path, the issue does not apply.

Fix

Updating rou3 to the latest version resolves the issue:

Better Auth recommends:

  1. Upgrading to Better Auth v1.4.5 or later, which includes the updated rou3.
  2. Ensuring the proxy normalizes URLs.
  3. If project maintainers cannot upgrade yet, they can protect their app by normalizing url before it reaches better-auth handler. See example below:
const req = new Request(...) // this would be the actual request object
const url = new URL(req.url);
const normalizedPath = url.pathname.replace(/\/+/g, "/");

if (url.pathname !== normalizedPath) {
  url.pathname = normalizedPath;
  // Update the raw request pathname
  Object.defineProperty(req, "url", {
    value: url.toString(),
    writable: true,
    configurable: true,
  });
}

Impact

  • Bypass disabledPaths
  • Bypass path-based rate limits

The impact of bypassing disabled paths could vary based on a project's configuration.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "better-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-41"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-16T21:22:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAn issue in the underlying router library **rou3** can cause `/path` and `//path` to be treated as identical routes. If your environment does **not** normalize incoming URLs (e.g., by collapsing multiple slashes), this can allow bypasses of `disabledPaths` and path-based rate limits.\n\n## Details\n\nBetter Auth uses **better-call**, which internally relies on **rou3** for routing. Affected versions of rou3 normalize paths by removing empty segments. As a result:\n\n* `/sign-in/email`\n* `//sign-in/email`\n* `///sign-in/email`\n\n\u2026all resolve to the same route.\n\nSome production setups *automatically* collapse multiple slashes. This includes:\n\n* Vercel with Nextjs (default)\n* Cloudflare - when normalize to urls origin is enabled (https://developers.cloudflare.com/rules/normalization/settings/#normalize-urls-to-origin)\n\nIn these environments and other configurations where `//path` reach Better Auth as `/path`, the issue does not apply.\n\n## Fix\n\nUpdating rou3 to the latest version resolves the issue:\n\n* better-call previously depended on `\"rou3\": \"^0.5.1\"`\n* The fix was introduced after that version\n  (commit: [https://github.com/h3js/rou3/commit/f60b43fa648399534507c9ac7db36d705b8874c3](https://github.com/h3js/rou3/commit/f60b43fa648399534507c9ac7db36d705b8874c3))\n\nBetter Auth recommends:\n\n1. **Upgrading to Better Auth v1.4.5 or later**, which includes the updated rou3.\n2. Ensuring the proxy normalizes URLs.\n3. If project maintainers cannot upgrade yet, they can protect their app by normalizing url before it reaches better-auth handler. See example below:\n```ts\nconst req = new Request(...) // this would be the actual request object\nconst url = new URL(req.url);\nconst normalizedPath = url.pathname.replace(/\\/+/g, \"/\");\n\nif (url.pathname !== normalizedPath) {\n  url.pathname = normalizedPath;\n  // Update the raw request pathname\n  Object.defineProperty(req, \"url\", {\n    value: url.toString(),\n    writable: true,\n    configurable: true,\n  });\n}\n```\n\n## Impact\n\n* Bypass `disabledPaths`\n* Bypass path-based rate limits\n\nThe impact of bypassing disabled paths could vary based on a project\u0027s configuration.",
  "id": "GHSA-x732-6j76-qmhm",
  "modified": "2025-12-16T21:22:45Z",
  "published": "2025-12-16T21:22:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-x732-6j76-qmhm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Better Auth\u0027s rou3 Dependency has Double-Slash Path Normalization which can Bypass disabledPaths Config and Rate Limits"
}

GHSA-XGHP-74WC-WJG3

Vulnerability from github – Published: 2024-09-10 18:30 – Updated: 2024-09-10 18:30
VLAI
Details

Windows Security Zone Mapping Security Feature Bypass Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-30073"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-41"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T17:15:16Z",
    "severity": "HIGH"
  },
  "details": "Windows Security Zone Mapping Security Feature Bypass Vulnerability",
  "id": "GHSA-xghp-74wc-wjg3",
  "modified": "2024-09-10T18:30:44Z",
  "published": "2024-09-10T18:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30073"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30073"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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-30
Implementation

Strategy: Output Encoding

Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

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.

CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters

Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.