Common Weakness Enumeration

CWE-436

Allowed-with-Review

Interpretation Conflict

Abstraction: Class · Status: Incomplete

Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.

263 vulnerabilities reference this CWE, most recent first.

GHSA-2C29-H3HM-8953

Vulnerability from github – Published: 2023-02-16 21:30 – Updated: 2023-02-27 18:32
VLAI
Details

A improper neutralization of crlf sequences in http headers ('http response splitting') in Fortinet FortiOS versions 7.2.0 through 7.2.2, 7.0.0 through 7.0.8, 6.4.0 through 6.4.11, 6.2.0 through 6.2.12, 6.0.0 through 6.0.16, FortiProxy 7.2.0 through 7.2.1, 7.0.0 through 7.0.7, 2.0.0 through 2.0.10, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6 may allow an authenticated and remote attacker to perform an HTTP request splitting attack which gives attackers control of the remaining headers and body of the response.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-42472"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-16T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A improper neutralization of crlf sequences in http headers (\u0027http response splitting\u0027) in Fortinet FortiOS versions 7.2.0 through 7.2.2, 7.0.0 through 7.0.8, 6.4.0 through 6.4.11, 6.2.0 through 6.2.12, 6.0.0 through 6.0.16, FortiProxy 7.2.0 through 7.2.1, 7.0.0 through 7.0.7, 2.0.0 through 2.0.10, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6 may allow an authenticated and remote attacker to perform an HTTP request splitting attack which gives attackers control of the remaining headers and body of the response.",
  "id": "GHSA-2c29-h3hm-8953",
  "modified": "2023-02-27T18:32:01Z",
  "published": "2023-02-16T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42472"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/psirt/FG-IR-22-362"
    }
  ],
  "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"
    }
  ]
}

GHSA-2C2Q-V642-37W6

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

The Sophos AV parsing engine before 2020-01-14 allows virus-detection bypass via a crafted ZIP archive. This affects Endpoint Protection, Cloud Optix, Mobile, Intercept X Endpoint, Intercept X for Server, and Secure Web Gateway.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-9363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-24T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Sophos AV parsing engine before 2020-01-14 allows virus-detection bypass via a crafted ZIP archive. This affects Endpoint Protection, Cloud Optix, Mobile, Intercept X Endpoint, Intercept X for Server, and Secure Web Gateway.",
  "id": "GHSA-2c2q-v642-37w6",
  "modified": "2022-05-24T17:09:34Z",
  "published": "2022-05-24T17:09:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9363"
    },
    {
      "type": "WEB",
      "url": "https://blog.zoller.lu/p/release-mode-coordinated-disclosure-ref.html"
    },
    {
      "type": "WEB",
      "url": "https://community.sophos.com/b/security-blog/posts/sophos-comments-to-cve-2020-9363"
    }
  ],
  "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"
    }
  ]
}

GHSA-2J66-VP53-PHJJ

Vulnerability from github – Published: 2024-06-16 03:30 – Updated: 2025-04-21 12:30
VLAI
Details

url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38428"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-16T03:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.",
  "id": "GHSA-2j66-vp53-phjj",
  "modified": "2025-04-21T12:30:23Z",
  "published": "2024-06-16T03:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38428"
    },
    {
      "type": "WEB",
      "url": "https://git.savannah.gnu.org/cgit/wget.git/commit/?id=ed0c7c7e0e8f7298352646b2fd6e06a11e242ace"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00029.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.gnu.org/archive/html/bug-wget/2024-06/msg00005.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241115-0005"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-33R2-8G93-5HM2

Vulnerability from github – Published: 2024-03-28 15:30 – Updated: 2024-03-28 15:30
VLAI
Details

The console may experience a service interruption when processing file names with invalid characters.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-45715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-28T15:15:45Z",
    "severity": "LOW"
  },
  "details": "The console may experience a service interruption when processing file names with invalid characters.\n",
  "id": "GHSA-33r2-8g93-5hm2",
  "modified": "2024-03-28T15:30:33Z",
  "published": "2024-03-28T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45715"
    },
    {
      "type": "WEB",
      "url": "https://support.hcltechsw.com/csm?id=kb_article\u0026sysparm_article=KB0111972"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-35HP-HQMV-8QG8

Vulnerability from github – Published: 2026-04-28 22:28 – Updated: 2026-05-08 13:42
VLAI
Summary
Fiber's cache middleware default key generator ignores query string, causing response mix-up across distinct query parameters
Details

Summary

Fiber cache middleware's default key generator uses only c.Path() and does not include the query string. As a result, requests like /?id=1 and /?id=2 can map to the same cache key and share the same cached response.

This can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.

Details

Default configuration in cache middleware:

  • KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }

References: - https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92 - https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621

The existing test demonstrates that when handler output depends on query parameter id, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.

PoC

Minimal PoC:

package main

import (
    "log"

    "github.com/gofiber/fiber/v3"
    "github.com/gofiber/fiber/v3/middleware/cache"
)

func main() {
    app := fiber.New()
    app.Use(cache.New()) // default config

    app.Get("/", func(c fiber.Ctx) error {
        return c.SendString(c.Query("id", "1"))
    })

    log.Fatal(app.Listen(":3000"))
}

Reproduction:

  1. GET /?id=1
  2. Cache miss
  3. Response body: 1
  4. GET /?id=2
  5. Cache hit
  6. Response body: 1 (expected 2)

Local verification command used:

go test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1

Observed result: test passes, confirming this is current behavior.

Impact

  • Responses that should vary by query parameters can be mixed between requests.
  • In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.
  • This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.

Suggested remediation

  • Change default cache key generation to include path + normalized query string (or canonicalized original URL).
  • Keep ability for custom key generators.
  • Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gofiber/fiber/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-436",
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-28T22:28:14Z",
    "nvd_published_at": "2026-05-05T13:16:28Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nFiber cache middleware\u0027s default key generator uses only `c.Path()` and does not include the query string.\nAs a result, requests like `/?id=1` and `/?id=2` can map to the same cache key and share the same cached response.\n\nThis can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.\n\n### Details\nDefault configuration in cache middleware:\n\n- `KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }`\n\nReferences:\n- https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92\n- https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621\n\nThe existing test demonstrates that when handler output depends on query parameter `id`, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.\n\n### PoC\nMinimal PoC:\n\n```go\npackage main\n\nimport (\n    \"log\"\n\n    \"github.com/gofiber/fiber/v3\"\n    \"github.com/gofiber/fiber/v3/middleware/cache\"\n)\n\nfunc main() {\n    app := fiber.New()\n    app.Use(cache.New()) // default config\n\n    app.Get(\"/\", func(c fiber.Ctx) error {\n        return c.SendString(c.Query(\"id\", \"1\"))\n    })\n\n    log.Fatal(app.Listen(\":3000\"))\n}\n```\n\nReproduction:\n\n1. `GET /?id=1`\n   - Cache miss\n   - Response body: `1`\n2. `GET /?id=2`\n   - Cache hit\n   - Response body: `1` (expected `2`)\n\nLocal verification command used:\n\n```bash\ngo test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1\n```\n\nObserved result: test passes, confirming this is current behavior.\n\n### Impact\n- Responses that should vary by query parameters can be mixed between requests.\n- In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.\n- This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.\n\n### Suggested remediation\n- Change default cache key generation to include path + normalized query string (or canonicalized original URL).\n- Keep ability for custom key generators.\n- Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.",
  "id": "GHSA-35hp-hqmv-8qg8",
  "modified": "2026-05-08T13:42:45Z",
  "published": "2026-04-28T22:28:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/security/advisories/GHSA-35hp-hqmv-8qg8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30246"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/commit/050ff1ff18511c1475b8ec627460216aaecddd4e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/commit/9a0d12c07ed895b84c72987f9288b04137afe5de"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gofiber/fiber"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fiber\u0027s cache middleware default key generator ignores query string, causing response mix-up across distinct query parameters"
}

GHSA-3632-GRRP-F8WR

Vulnerability from github – Published: 2022-07-29 00:00 – Updated: 2022-08-04 00:00
VLAI
Details

Fossil 2.18 on Windows allows attackers to cause a denial of service (daemon crash) via an XSS payload in a ticket. This occurs because the ticket data is stored in a temporary file, and the product does not properly handle the absence of this file after Windows Defender has flagged it as malware.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-34009"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-28T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Fossil 2.18 on Windows allows attackers to cause a denial of service (daemon crash) via an XSS payload in a ticket. This occurs because the ticket data is stored in a temporary file, and the product does not properly handle the absence of this file after Windows Defender has flagged it as malware.",
  "id": "GHSA-3632-grrp-f8wr",
  "modified": "2022-08-04T00:00:23Z",
  "published": "2022-07-29T00:00:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34009"
    },
    {
      "type": "WEB",
      "url": "https://fossil-scm.org/home/doc/trunk/www/changes.wiki"
    },
    {
      "type": "WEB",
      "url": "https://gainsec.com/2022/07/27/cve-2022-34009"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3635-87F7-GFGJ

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

An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service (host OS crash) or possibly gain host OS privileges because of an interpretation conflict for a union data structure associated with shadow paging. NOTE: this issue exists because of an incorrect fix for CVE-2017-15595.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-19966"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-08T04:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service (host OS crash) or possibly gain host OS privileges because of an interpretation conflict for a union data structure associated with shadow paging. NOTE: this issue exists because of an incorrect fix for CVE-2017-15595.",
  "id": "GHSA-3635-87f7-gfgj",
  "modified": "2022-05-13T01:50:55Z",
  "published": "2022-05-13T01:50:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19966"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/10/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UXC6BME7SXJI2ZIATNXCAH7RGPI4UKTT"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4369"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xen.org/xsa/advisory-280.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00072.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106182"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-36HH-X5P5-JGC8

Vulnerability from github – Published: 2026-05-27 00:37 – Updated: 2026-05-27 00:37
VLAI
Summary
@hapi/content header parser has a parameter smuggling issue that allows upload-filter bypass via duplicate parameters
Details

Impact

The two parsers resolved duplicates inconsistently and silently: - Content.disposition() retained the last occurrence of each parameter. - Content.type() retained the first occurrence of charset and boundary.

Either behavior creates a parameter-smuggling primitive when another component in the request-processing chain (a WAF, reverse proxy, security filter, or alternate parser) resolves duplicates the opposite way. The primary attack vector is upload filename allowlist bypass:

Content-Disposition: form-data; name="file"; filename="safe.txt"; filename="shell.php"

Patches

The issue has been patched in 6.0.2.

Workarounds

Pre or post validate headers looking for duplicates.

Resources

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@hapi/content"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T00:37:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nThe two parsers resolved duplicates inconsistently and silently:\n- `Content.disposition()` retained the last occurrence of each parameter.\n- `Content.type()` retained the first occurrence of charset and boundary.\n\nEither behavior creates a parameter-smuggling primitive when another component in the request-processing chain (a WAF, reverse proxy, security filter, or alternate parser) resolves duplicates the opposite way. The primary attack vector is upload filename allowlist bypass:\n\n`Content-Disposition: form-data; name=\"file\"; filename=\"safe.txt\"; filename=\"shell.php\"`\n\n### Patches\nThe issue has been patched in 6.0.2.\n\n### Workarounds\nPre or post validate headers looking for duplicates.\n\n### Resources\n- [RFC 6266 \u00a74.1 \u2014 Content-Disposition syntax](https://www.rfc-editor.org/rfc/rfc6266#section-4.1)\n- [RFC 7231 \u00a73.1.1.1 \u2014 Content-Type syntax](https://www.rfc-editor.org/rfc/rfc7231#section-3.1.1.1)\n- [RFC 7230 \u00a73.2.6 \u2014 token character set](https://www.rfc-editor.org/rfc/rfc7230#section-3.2.6)",
  "id": "GHSA-36hh-x5p5-jgc8",
  "modified": "2026-05-27T00:37:20Z",
  "published": "2026-05-27T00:37:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hapijs/content/security/advisories/GHSA-36hh-x5p5-jgc8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hapijs/content/commit/3850079550c191d25e3643dc82a6d61144db8c2f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hapijs/content"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@hapi/content header parser has a parameter smuggling issue that allows upload-filter bypass via duplicate parameters"
}

GHSA-392F-GGF5-FP3C

Vulnerability from github – Published: 2026-03-02 21:49 – Updated: 2026-03-02 21:49
VLAI
Summary
OpenClaw: Unicode canonicalization drift in node metadata policy classification could broaden node allowlists
Details

Summary

A paired node could supply Unicode-confusable platform or deviceFamily metadata that passed metadata pinning but classified differently for command policy resolution, broadening default node command allowlists.

Impact

This is a policy-bypass issue within the paired-node trust boundary and can expand node command availability beyond intended defaults.

Fix

Node metadata canonicalization was hardened against confusables, and unknown platform defaults were made conservative (excluding system.run and system.which unless explicitly allowlisted).

Affected and Patched Versions

  • Affected: <= 2026.2.26
  • Patched: 2026.3.1
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-176",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T21:49:33Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA paired node could supply Unicode-confusable `platform` or `deviceFamily` metadata that passed metadata pinning but classified differently for command policy resolution, broadening default node command allowlists.\n\n### Impact\nThis is a policy-bypass issue within the paired-node trust boundary and can expand node command availability beyond intended defaults.\n\n### Fix\nNode metadata canonicalization was hardened against confusables, and unknown platform defaults were made conservative (excluding `system.run` and `system.which` unless explicitly allowlisted).\n\n### Affected and Patched Versions\n- Affected: `\u003c= 2026.2.26`\n- Patched: `2026.3.1`",
  "id": "GHSA-392f-ggf5-fp3c",
  "modified": "2026-03-02T21:49:33Z",
  "published": "2026-03-02T21:49:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-392f-ggf5-fp3c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Unicode canonicalization drift in node metadata policy classification could broaden node allowlists"
}

GHSA-39WR-7Q6H-CF68

Vulnerability from github – Published: 2026-09-18 17:14 – Updated: 2026-09-18 17:14
VLAI
Summary
LMDeploy has an SSRF bypass
Details

Summary

The URL checking logic in lmdeploy has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

Details

The current lmdeploy project uses _is_safe_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks. QQ20260416-203956-16-1 However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _is_safe_url for URL validation, and then using requests.Session().get to send the request. QQ20260416-204053-16-2 The core issue: urlparse() and requests disagree on which host a URL like http://127.0.0.1:6666\@1.1.1.1 points to:

  • urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as 1.1.1.1 (public)
  • requests treats \ as a path character, connecting to 127.0.0.1 (internal)

Below is a test code I wrote following the code.

from urllib.parse import urlparse
import ipaddress
import socket
import requests


def _is_safe_url(url: str) -> tuple[bool, str]:
    """Check if the URL is safe to fetch (not internal/private)."""
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ("http", "https"):
            return False, f"Unsupported scheme: {parsed.scheme}"

        hostname = parsed.hostname
        if not hostname:
            return False, "Could not parse hostname from URL"

        # check all IPs (IPv4 + IPv6) using getaddrinfo
        try:
            infos = socket.getaddrinfo(hostname, None)
        except socket.gaierror:
            return False, "Hostname resolution failed"

        for info in infos:
            ip = ipaddress.ip_address(info[4][0])
            # block any IP that is not globally routable (covers private, loopback,
            # link-local, multicast, reserved, unspecified, etc.)
            if not ip.is_global:
                return False, f"Blocked non-global IP detected: {ip}"

        return True, "URL is safe"
    except Exception as e:
        return False, f"URL validation failed: {str(e)}"


# url = "http://127.0.0.1:6666"
url = "http://127.0.0.1:6666\@1.1.1.1"
is_safe, reason = _is_safe_url(url)
if not is_safe:
    raise ValueError(f"URL is blocked for security reasons: {reason}")

fetch_timeout = 10

client = requests.Session()
client.max_redirects = 3
response = client.get(url, timeout=fetch_timeout, allow_redirects=True)

When an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it. QQ20260416-204234-16-3 However, when an attacker uses http://127.0.0.1:6666\@1.1.1.1, the detection logic resolves the host to 1.1.1.1, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to http://127.0.0.1:6666/, bypassing the detection and achieving an SSRF attack.

QQ20260416-204319-16-4

PoC

http://127.0.0.1:6666\@1.1.1.1

Impact

SSRF

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lmdeploy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.3"
            },
            {
              "fixed": "0.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-18T17:14:06Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nThe URL checking logic in lmdeploy has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.\n\n### Details\nThe current lmdeploy project uses `_is_safe_url` to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.\n\u003cimg width=\"943\" height=\"836\" alt=\"QQ20260416-203956-16-1\" src=\"https://github.com/user-attachments/assets/042faad1-7458-444a-bbc9-525c772b0a4d\" /\u003e\nHowever, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using `_is_safe_url` for URL validation, and then using requests.Session().get to send the request.\n\u003cimg width=\"1086\" height=\"576\" alt=\"QQ20260416-204053-16-2\" src=\"https://github.com/user-attachments/assets/7ffb8a69-b155-483a-90be-016c53e6387a\" /\u003e\nThe core issue:\u00a0`urlparse()`\u00a0and\u00a0`requests`\u00a0disagree on which host a URL like\u00a0`http://127.0.0.1:6666\\@1.1.1.1`\u00a0points to:\n\n- `urlparse()`\u00a0treats\u00a0`\\`\u00a0as a regular character and\u00a0`@`\u00a0as the userinfo-host delimiter, so it extracts hostname as\u00a01.1.1.1\u00a0(public)\n- `requests`\u00a0treats\u00a0`\\`\u00a0as a path character, connecting to\u00a0`127.0.0.1`\u00a0(internal)\n\nBelow is a test code I wrote following the code.\n```\nfrom urllib.parse import urlparse\nimport ipaddress\nimport socket\nimport requests\n\n\ndef _is_safe_url(url: str) -\u003e tuple[bool, str]:\n    \"\"\"Check if the URL is safe to fetch (not internal/private).\"\"\"\n    try:\n        parsed = urlparse(url)\n        if parsed.scheme not in (\"http\", \"https\"):\n            return False, f\"Unsupported scheme: {parsed.scheme}\"\n\n        hostname = parsed.hostname\n        if not hostname:\n            return False, \"Could not parse hostname from URL\"\n\n        # check all IPs (IPv4 + IPv6) using getaddrinfo\n        try:\n            infos = socket.getaddrinfo(hostname, None)\n        except socket.gaierror:\n            return False, \"Hostname resolution failed\"\n\n        for info in infos:\n            ip = ipaddress.ip_address(info[4][0])\n            # block any IP that is not globally routable (covers private, loopback,\n            # link-local, multicast, reserved, unspecified, etc.)\n            if not ip.is_global:\n                return False, f\"Blocked non-global IP detected: {ip}\"\n\n        return True, \"URL is safe\"\n    except Exception as e:\n        return False, f\"URL validation failed: {str(e)}\"\n\n\n# url = \"http://127.0.0.1:6666\"\nurl = \"http://127.0.0.1:6666\\@1.1.1.1\"\nis_safe, reason = _is_safe_url(url)\nif not is_safe:\n    raise ValueError(f\"URL is blocked for security reasons: {reason}\")\n\nfetch_timeout = 10\n\nclient = requests.Session()\nclient.max_redirects = 3\nresponse = client.get(url, timeout=fetch_timeout, allow_redirects=True)\n```\nWhen an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it.\n\u003cimg width=\"1286\" height=\"195\" alt=\"QQ20260416-204234-16-3\" src=\"https://github.com/user-attachments/assets/b921ff01-3b9f-49a5-a410-bd21fe42f9c9\" /\u003e\nHowever, when an attacker uses `http://127.0.0.1:6666\\@1.1.1.1`, the detection logic resolves the host to `1.1.1.1`, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to `http://127.0.0.1:6666/`, bypassing the detection and achieving an SSRF attack.\n\n\u003cimg width=\"2064\" height=\"154\" alt=\"QQ20260416-204319-16-4\" src=\"https://github.com/user-attachments/assets/5da18f35-f400-46e6-9bf3-1330ba424b02\" /\u003e\n\n### PoC\n```\nhttp://127.0.0.1:6666\\@1.1.1.1\n```\n\n### Impact\nSSRF",
  "id": "GHSA-39wr-7q6h-cf68",
  "modified": "2026-09-18T17:14:06Z",
  "published": "2026-09-18T17:14:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/InternLM/lmdeploy/security/advisories/GHSA-39wr-7q6h-cf68"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/InternLM/lmdeploy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/InternLM/lmdeploy/releases/tag/v0.15.0"
    }
  ],
  "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"
    }
  ],
  "summary": "LMDeploy has an SSRF bypass"
}

No mitigation information available for this CWE.

CAPEC-105: HTTP Request Splitting

An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to split a single HTTP request into multiple unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).

See CanPrecede relationships for possible consequences.

CAPEC-273: HTTP Response Smuggling

An adversary manipulates and injects malicious content in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., server).

See CanPrecede relationships for possible consequences.

CAPEC-34: HTTP Response Splitting

An adversary manipulates and injects malicious content, in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., web server) or into an already spoofed HTTP response from an adversary controlled domain/site.

See CanPrecede relationships for possible consequences.