Vulnerability-Lookup

GHSA-78X9-FHHX-V2G6

Vulnerability from github – Published: 2026-09-03 14:49 – Updated: 2026-09-03 14:49

Summary

CKAN MCP Server: Cache-key canonicalization collision enables cache confusion / poisoning

Details

Summary

The response cache derives its key from an ambiguous string serialization of the request parameters. canonicalizeParams joins sorted ${key}=${value} pairs with & and does not escape &, =, or the | field separators used in buildCacheKey. Two different logical parameter sets can therefore serialize to the same key and share one cache entry. Because the cached value is whatever the upstream returned for whichever request populated the entry first, an attacker can prime a colliding key so a victim's distinct query (same server_url) is served the attacker's cached response.

Affected code

// src/utils/cache.ts
export function canonicalizeParams(params) {
  const keys = Object.keys(params).sort();
  const pairs = [];
  for (const key of keys) {
    const value = params[key];
    if (value === undefined || value === null) continue;
    const serialized = typeof value === "object" ? JSON.stringify(value) : String(value);
    pairs.push(`${key}=${serialized}`);        // value not escaped
  }
  return pairs.join("&");                        // '&' delimiter, injectable
}

export async function buildCacheKey(serverUrl, action, params) {
  const raw = `${serverUrl}|${action}|${canonicalizeParams(params)}`;  // '|' also unescaped
  return sha1Hex(raw);
}

Confirmed collisions (identical key):

{ q: "budget", rows: 10 } ≡ { q: "budget&rows=10" } → both canonicalize to q=budget&rows=10
{ filters: { a: "b" } } ≡ { filters: '{"a":"b"}' } → both canonicalize to filters={"a":"b"} (object-vs-string ambiguity)

An attacker can reproduce any target canonical string by injecting it into the alphabetically-first parameter, so the collision is general, not incidental.

Impact

Cache poisoning / confusion. On a shared cache (caching is enabled by default; the Cloudflare Workers deployment uses the shared caches.default, and a Node HTTP instance shares one in-process LRU across all clients), an attacker primes a colliding entry so that another client's genuinely different query receives the attacker-chosen response for the same portal.
Integrity of results. Victims receive data for a query they did not make (wrong dataset list, wrong record set), undermining trust in tool output.
Chains with indirect prompt injection (advisory #07). The attacker's colliding request can be one whose upstream response surfaces an attacker-controlled dataset (with malicious notes/title); the victim's benign query then serves that poisoned content to the model — delivering prompt injection via the cache, without the victim ever querying the malicious dataset.

Confidentiality impact is low (same-portal public data); the primary damage is integrity. AC:H reflects the need for caching to be enabled and a shared instance plus priming before the victim's request populates the entry.

Proof of concept

poc/cache-collision-poc.mjs primes a single-param request and shows a victim's distinct two-param request being served the attacker-primed entry:

attacker canonical : q=budget&rows=10
victim   canonical : q=budget&rows=10
same cache key      : true
victim served from cache: true
victim RECEIVED    : RESULT_FOR({"q":"budget&rows=10"})
victim EXPECTED    : RESULT_FOR({"q":"budget","rows":10})

Remediation

Build the cache key from an unambiguous, injection-proof encoding: hash a structured, canonical JSON (with typed values) or percent-encode/escape each key and value before joining, and use a separator that cannot appear in the encoded fields. Include a type tag so {a:{...}} (object) and {a:"..."} (string) never coincide.
Consider partitioning the cache per client/tenant on shared deployments so one client cannot influence another's entries.

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@aborruso/ckan-mcp-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.112"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73846"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-03T14:49:22Z",
    "nvd_published_at": "2026-08-14T17:20:36Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe response cache derives its key from an ambiguous string serialization of the request parameters. `canonicalizeParams` joins sorted `${key}=${value}` pairs with `\u0026` and does not escape `\u0026`, `=`, or the `|` field separators used in `buildCacheKey`. Two **different** logical parameter sets can therefore serialize to the **same** key and share one cache entry. Because the cached value is whatever the upstream returned for whichever request populated the entry first, an attacker can prime a colliding key so a victim\u0027s distinct query (same `server_url`) is served the attacker\u0027s cached response.\n\n## Affected code\n\n```js\n// src/utils/cache.ts\nexport function canonicalizeParams(params) {\n  const keys = Object.keys(params).sort();\n  const pairs = [];\n  for (const key of keys) {\n    const value = params[key];\n    if (value === undefined || value === null) continue;\n    const serialized = typeof value === \"object\" ? JSON.stringify(value) : String(value);\n    pairs.push(`${key}=${serialized}`);        // value not escaped\n  }\n  return pairs.join(\"\u0026\");                        // \u0027\u0026\u0027 delimiter, injectable\n}\n\nexport async function buildCacheKey(serverUrl, action, params) {\n  const raw = `${serverUrl}|${action}|${canonicalizeParams(params)}`;  // \u0027|\u0027 also unescaped\n  return sha1Hex(raw);\n}\n```\n\nConfirmed collisions (identical key):\n\n- `{ q: \"budget\", rows: 10 }`  \u2261  `{ q: \"budget\u0026rows=10\" }`  \u2192 both canonicalize to `q=budget\u0026rows=10`\n- `{ filters: { a: \"b\" } }`  \u2261  `{ filters: \u0027{\"a\":\"b\"}\u0027 }`  \u2192 both canonicalize to `filters={\"a\":\"b\"}` (object-vs-string ambiguity)\n\nAn attacker can reproduce **any** target canonical string by injecting it into the alphabetically-first parameter, so the collision is general, not incidental.\n\n## Impact\n\n- **Cache poisoning / confusion.** On a shared cache (caching is enabled by\n  default; the Cloudflare Workers deployment uses the shared `caches.default`, and\n  a Node HTTP instance shares one in-process LRU across all clients), an attacker\n  primes a colliding entry so that another client\u0027s genuinely different query\n  receives the attacker-chosen response for the same portal.\n- **Integrity of results.** Victims receive data for a query they did not make\n  (wrong dataset list, wrong record set), undermining trust in tool output.\n- **Chains with indirect prompt injection (advisory #07).** The attacker\u0027s\n  colliding request can be one whose upstream response surfaces an\n  attacker-controlled dataset (with malicious `notes`/`title`); the victim\u0027s\n  benign query then serves that poisoned content to the model \u2014 delivering prompt\n  injection via the cache, without the victim ever querying the malicious dataset.\n\nConfidentiality impact is low (same-portal public data); the primary damage is\nintegrity. `AC:H` reflects the need for caching to be enabled and a shared\ninstance plus priming before the victim\u0027s request populates the entry.\n\n## Proof of concept\n\n`poc/cache-collision-poc.mjs` primes a single-param request and shows a victim\u0027s\ndistinct two-param request being served the attacker-primed entry:\n\n```\nattacker canonical : q=budget\u0026rows=10\nvictim   canonical : q=budget\u0026rows=10\nsame cache key      : true\nvictim served from cache: true\nvictim RECEIVED    : RESULT_FOR({\"q\":\"budget\u0026rows=10\"})\nvictim EXPECTED    : RESULT_FOR({\"q\":\"budget\",\"rows\":10})\n```\n\n## Remediation\n\n- Build the cache key from an unambiguous, injection-proof encoding: hash a\n  structured, canonical JSON (with typed values) or percent-encode/escape each key\n  and value before joining, and use a separator that cannot appear in the encoded\n  fields. Include a type tag so `{a:{...}}` (object) and `{a:\"...\"}` (string)\n  never coincide.\n- Consider partitioning the cache per client/tenant on shared deployments so one\n  client cannot influence another\u0027s entries.",
  "id": "GHSA-78x9-fhhx-v2g6",
  "modified": "2026-09-03T14:49:22Z",
  "published": "2026-09-03T14:49:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ondata/ckan-mcp-server/security/advisories/GHSA-78x9-fhhx-v2g6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73846"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ondata/ckan-mcp-server/commit/8e1522f9bbfa1f3b21550f17887f60f133e24151"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ondata/ckan-mcp-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ondata/ckan-mcp-server/releases/tag/v0.4.112"
    }
  ],
  "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"
    }
  ],
  "summary": "CKAN MCP Server: Cache-key canonicalization collision enables cache confusion / poisoning"
}

GHSA-796M-2973-WC5Q

Vulnerability from github – Published: 2026-03-03 22:23 – Updated: 2026-03-03 22:23

Summary

OpenClaw has exec allowlist/safeBins policy-runtime mismatch via env -S wrapper interpretation

Details

Summary

tools.exec allowlist/safe-bins evaluation could diverge from runtime execution for wrapper commands using GNU env -S/--split-string semantics. This allowed policy checks to treat a command as a benign safe-bin invocation while runtime executed a different payload.

Affected Packages / Versions

Package: openclaw (npm)
Vulnerable versions: <= 2026.2.22-2 (latest currently published npm version)
Patched version (released): 2026.2.23

Impact

An attacker able to influence tool command text (for example via untrusted prompt/content injection reaching an exec-capable flow) could bypass allowlist/safe-bins intent and execute unexpected commands.

Technical Details

Root cause was policy/runtime interpretation mismatch for dispatch wrappers: - analysis resolved an effective executable from wrapper-unwrapped argv, - execution could still run original wrapper argv semantics, - safe-bin short-flag handling also allowed unknown short options in clusters.

Remediation

The fix hardens exec approvals to fail closed and enforce analysis/runtime parity: - introduce wrapper execution planning with semantic-wrapper blocking, - carry planned effectiveArgv + policyBlocked metadata through resolution, - evaluate allowlist/safe-bins against planned argv, - enforce canonical rebuilt shell command from planned argv for allowlist auto-paths, - use planned argv for node-host/mac exec-host invocation paths, - reject unknown short safe-bin flags, - add regression tests for semantic env wrappers and parity fixtures.

Fix Commit(s)

a1c4bf07c6baad3ef87a0e710fe9aef127b1f606

Release Process Note

patched_versions is pre-set to the released version (2026.2.23). Patched in 2026.2.23 and published.

OpenClaw thanks @jiseoung for reporting.

Severity

5.7 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T22:23:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n`tools.exec` allowlist/safe-bins evaluation could diverge from runtime execution for wrapper commands using GNU `env -S/--split-string` semantics. This allowed policy checks to treat a command as a benign safe-bin invocation while runtime executed a different payload.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Vulnerable versions: `\u003c= 2026.2.22-2` (latest currently published npm version)\n- Patched version (released): `2026.2.23`\n\n### Impact\nAn attacker able to influence tool command text (for example via untrusted prompt/content injection reaching an exec-capable flow) could bypass allowlist/safe-bins intent and execute unexpected commands.\n\n### Technical Details\nRoot cause was policy/runtime interpretation mismatch for dispatch wrappers:\n- analysis resolved an effective executable from wrapper-unwrapped argv,\n- execution could still run original wrapper argv semantics,\n- safe-bin short-flag handling also allowed unknown short options in clusters.\n\n### Remediation\nThe fix hardens exec approvals to fail closed and enforce analysis/runtime parity:\n- introduce wrapper execution planning with semantic-wrapper blocking,\n- carry planned `effectiveArgv` + `policyBlocked` metadata through resolution,\n- evaluate allowlist/safe-bins against planned argv,\n- enforce canonical rebuilt shell command from planned argv for allowlist auto-paths,\n- use planned argv for node-host/mac exec-host invocation paths,\n- reject unknown short safe-bin flags,\n- add regression tests for semantic `env` wrappers and parity fixtures.\n\n### Fix Commit(s)\n- `a1c4bf07c6baad3ef87a0e710fe9aef127b1f606`\n\n### Release Process Note\n`patched_versions` is pre-set to the released version (`2026.2.23`). Patched in `2026.2.23` and published.\n\nOpenClaw thanks @jiseoung for reporting.",
  "id": "GHSA-796m-2973-wc5q",
  "modified": "2026-03-03T22:23:45Z",
  "published": "2026-03-03T22:23:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-796m-2973-wc5q"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a1c4bf07c6baad3ef87a0e710fe9aef127b1f606"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has exec allowlist/safeBins policy-runtime mismatch via env -S wrapper interpretation"
}

GHSA-7CXR-H8WM-FG4C

Vulnerability from github – Published: 2023-01-14 12:30 – Updated: 2023-08-31 18:47

Summary

Apache Shiro Interpretation Conflict vulnerability

Details

When using Apache Shiro before 1.11.0 together with Spring Boot 2.6+, a specially crafted HTTP request may cause an authentication bypass. The authentication bypass occurs when Shiro and Spring Boot are using different pattern-matching techniques. Both Shiro and Spring Boot < 2.6 default to Ant style pattern matching. Mitigation: Update to Apache Shiro 1.11.0, or set the following Spring Boot configuration value: spring.mvc.pathmatch.matching-strategy = ant_path_matcher

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.shiro:shiro-root"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-22602"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-20T21:50:25Z",
    "nvd_published_at": "2023-01-14T10:15:00Z",
    "severity": "HIGH"
  },
  "details": "When using Apache Shiro before 1.11.0 together with Spring Boot 2.6+, a specially crafted HTTP request may cause an authentication bypass. The authentication bypass occurs when Shiro and Spring Boot are using different pattern-matching techniques. Both Shiro and Spring Boot \u003c 2.6 default to Ant style pattern matching. Mitigation: Update to Apache Shiro 1.11.0, or set the following Spring Boot configuration value: `spring.mvc.pathmatch.matching-strategy = ant_path_matcher` ",
  "id": "GHSA-7cxr-h8wm-fg4c",
  "modified": "2023-08-31T18:47:04Z",
  "published": "2023-01-14T12:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22602"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/shiro"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/dzj0k2smpzzgj6g666hrbrgsrlf9yhkl"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Shiro Interpretation Conflict vulnerability"
}

GHSA-7M2H-6596-W2G6

Vulnerability from github – Published: 2022-05-24 17:02 – Updated: 2024-03-21 03:33

Details

The Lever PDF Embedder plugin 4.4 for WordPress does not block the distribution of polyglot PDF documents that are valid JAR archives.

Severity

9.8 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2019-19589"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-12-05T04:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Lever PDF Embedder plugin 4.4 for WordPress does not block the distribution of polyglot PDF documents that are valid JAR archives.",
  "id": "GHSA-7m2h-6596-w2g6",
  "modified": "2024-03-21T03:33:47Z",
  "published": "2022-05-24T17:02:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19589"
    },
    {
      "type": "WEB",
      "url": "https://sejalivre.org/usando-arquivos-polyglot-para-distribuir-malwares"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/pdf-embedder/#developers"
    }
  ],
  "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-7P8R-X3MC-P8W7

Vulnerability from github – Published: 2026-08-03 19:16 – Updated: 2026-08-03 19:16

Summary

fast-uri vulnerable to host confusion via backslash authority introducer

Details

Impact

fast-uri v4.1.1 and earlier require a literal // to recognize a URI authority, so a reference that uses \\, /\, or \/ as the authority introducer (in place of //, after an optional scheme) is parsed with no authority: the sequence and everything after it fold into the path. Node's native WHATWG URL (used by fetch(), undici, and Node's http/https clients) instead treats \ as interchangeable with / for special schemes (http, https, ws, wss, ftp, file), so the two parsers extract different hosts from the same input.

For example, fast-uri resolves \\evil.com/path against base https://allowed.com/ to https://allowed.com/%5C%5Cevil.com/path (confined to the trusted host), while Node's WHATWG URL resolves the same reference to https://evil.com/path.

Applications that use fast-uri to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination.

Patches

Upgrade to fast-uri v4.1.2, v3.1.5, v2.4.4.

Workarounds

None. Upgrade to the patched version.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-uri"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-uri"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-uri"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-18446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-03T19:16:43Z",
    "nvd_published_at": "2026-07-31T15:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`fast-uri` v4.1.1 and earlier require a literal `//` to recognize a URI authority, so a reference that uses `\\\\`, `/\\`, or `\\/` as the authority introducer (in place of `//`, after an optional scheme) is parsed with no authority: the sequence and everything after it fold into the path. Node\u0027s native WHATWG `URL` (used by `fetch()`, `undici`, and Node\u0027s `http`/`https` clients) instead treats `\\` as interchangeable with `/` for special schemes (`http`, `https`, `ws`, `wss`, `ftp`, `file`), so the two parsers extract different hosts from the same input.\n\nFor example, `fast-uri` resolves `\\\\evil.com/path` against base `https://allowed.com/` to `https://allowed.com/%5C%5Cevil.com/path` (confined to the trusted host), while Node\u0027s WHATWG URL resolves the same reference to `https://evil.com/path`.\n\nApplications that use `fast-uri` to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node\u0027s URL or `fetch()` consumers see a policy/use desync and can be steered to an unintended destination.\n\n### Patches\n\nUpgrade to `fast-uri` v4.1.2, v3.1.5, v2.4.4.\n\n### Workarounds\n\nNone. Upgrade to the patched version.",
  "id": "GHSA-7p8r-x3mc-p8w7",
  "modified": "2026-08-03T19:16:43Z",
  "published": "2026-08-03T19:16:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/security/advisories/GHSA-7p8r-x3mc-p8w7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/commit/f3c6c905f47831007490f466c5945012e905cc52"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fastify/fast-uri"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/releases/tag/v4.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "fast-uri vulnerable to host confusion via backslash authority introducer"
}

GHSA-82VX-MM6R-GG8W

Vulnerability from github – Published: 2024-02-01 22:47 – Updated: 2024-02-01 22:47

Summary

Bref vulnerable to Body Parsing Inconsistency in Event-Driven Functions

Details

Impacted Resources

bref/src/Event/Http/Psr7Bridge.php:130-168

Description

When Bref is used with the Event-Driven Function runtime and the handler is a RequestHandlerInterface, then the Lambda event is converted to a PSR7 object. During the conversion process, if the request is a MultiPart, each part is parsed and its content added in the $files or $parsedBody arrays. To do that, the following method is called with as first argument the result array ($files or $parsedBody), as second argument the part name, and as third argument the part content:

/**
 * Parse a string key like "files[id_cards][jpg][]" and do $array['files']['id_cards']['jpg'][] = $value
 */
private static function parseKeyAndInsertValueInArray(array &$array, string $key, mixed $value): void
{
    if (! str_contains($key, '[')) {
        $array[$key] = $value;

        return;
    }

    $parts = explode('[', $key); // files[id_cards][jpg][] => [ 'files',  'id_cards]', 'jpg]', ']' ]
    $pointer = &$array;

    foreach ($parts as $k => $part) {
        if ($k === 0) {
            $pointer = &$pointer[$part];

            continue;
        }

        // Skip two special cases:
        // [[ in the key produces empty string
        // [test : starts with [ but does not end with ]
        if ($part === '' || ! str_ends_with($part, ']')) {
            // Malformed key, we use it "as is"
            $array[$key] = $value;

            return;
        }

        $part = substr($part, 0, -1); // The last char is a ] => remove it to have the real key

        if ($part === '') { // [] case
            $pointer = &$pointer[];
        } else {
            $pointer = &$pointer[$part];
        }
    }

    $pointer = $value;
}

The conversion process produces a different output compared to the one of plain PHP when keys ending with and open square bracket ([) are used.

Let's take for example the following part:

------WebKitFormBoundary
Content-Disposition: form-data; name="key0[key1][key2]["

value
------WebKitFormBoundary--

In plain PHP it would be converted to Array( [key0] => Array ( [key1] => Array ( [key2] => value) ) ), while in Bref it would be converted to Array( [key0] => Array ( [key1] => Array ( [key2] => ) ) [key0[key1][key2][] => value ).

Impact

Based on the application logic the difference in the body parsing might lead to vulnerabilities and/or undefined behaviors.

PoC

Create a new Bref project.
Create an index.php file with the following content:

<?php

namespace App;

require __DIR__ . '/vendor/autoload.php';

use Nyholm\Psr7\Response;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\RequestHandlerInterface;

class MyHttpHandler implements RequestHandlerInterface
{
    public function handle(ServerRequestInterface $request): ResponseInterface
    {

        return new Response(200, [], var_export($request->getParsedBody(),true));
    }
}

return new MyHttpHandler();

Use the following serverless.yml to deploy the Lambda:

service: app

provider:
    name: aws
    region: eu-central-1

plugins:
    - ./vendor/bref/bref

# Exclude files from deployment
package:
    patterns:
        - '!node_modules/**'
        - '!tests/**'

functions:
    api:
        handler: index.php
        runtime: php-83
        events:
            - httpApi: 'ANY /upload'

Replay the following request after having replaced the <HOST> placeholder with the deployed Lambda domain:

POST /upload HTTP/2
Host: <HOST>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryQqDeSZSSvmn2rfjb
Content-Length: 180

------WebKitFormBoundaryQqDeSZSSvmn2rfjb
Content-Disposition: form-data; name="key0[key1][key2]["

value
------WebKitFormBoundaryQqDeSZSSvmn2rfjb--

Notice how the body has been parsed.
Create a plain.php file with the following content:

<?php

var_dump($_POST);

Start a PHP server inside the project directory (e.g. php -S 127.0.0.1:8090).
Replay the following request after having replaced the <HOST> placeholder with the PHP server address:

POST /plain.php HTTP/1.1
Host: <HOST>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryQqDeSZSSvmn2rfjb
Content-Length: 180

------WebKitFormBoundaryQqDeSZSSvmn2rfjb
Content-Disposition: form-data; name="key0[key1][key2]["

value
------WebKitFormBoundaryQqDeSZSSvmn2rfjb--

Notice the differences in the parsing compared to what observed at step 5.

Suggested Remediation

Use the PHP function parse_str to parse the body parameters to mimic the plain PHP behavior.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "bref/bref"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-24754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-01T22:47:29Z",
    "nvd_published_at": "2024-02-01T16:17:14Z",
    "severity": "LOW"
  },
  "details": "## Impacted Resources\n\nbref/src/Event/Http/Psr7Bridge.php:130-168\n\n## Description\n\nWhen Bref is used with the Event-Driven Function runtime and the handler is a `RequestHandlerInterface`, then the Lambda event is converted to a PSR7 object.\nDuring the conversion process, if the request is a MultiPart, each part is parsed and its content added in the `$files` or `$parsedBody` arrays.\nTo do that, the following method is called with as first argument the result array (`$files` or `$parsedBody`), as second argument the part name, and as third argument the part content:\n\n```php\n/**\n * Parse a string key like \"files[id_cards][jpg][]\" and do $array[\u0027files\u0027][\u0027id_cards\u0027][\u0027jpg\u0027][] = $value\n */\nprivate static function parseKeyAndInsertValueInArray(array \u0026$array, string $key, mixed $value): void\n{\n    if (! str_contains($key, \u0027[\u0027)) {\n        $array[$key] = $value;\n\n        return;\n    }\n\n    $parts = explode(\u0027[\u0027, $key); // files[id_cards][jpg][] =\u003e [ \u0027files\u0027,  \u0027id_cards]\u0027, \u0027jpg]\u0027, \u0027]\u0027 ]\n    $pointer = \u0026$array;\n\n    foreach ($parts as $k =\u003e $part) {\n        if ($k === 0) {\n            $pointer = \u0026$pointer[$part];\n\n            continue;\n        }\n\n        // Skip two special cases:\n        // [[ in the key produces empty string\n        // [test : starts with [ but does not end with ]\n        if ($part === \u0027\u0027 || ! str_ends_with($part, \u0027]\u0027)) {\n            // Malformed key, we use it \"as is\"\n            $array[$key] = $value;\n\n            return;\n        }\n\n        $part = substr($part, 0, -1); // The last char is a ] =\u003e remove it to have the real key\n\n        if ($part === \u0027\u0027) { // [] case\n            $pointer = \u0026$pointer[];\n        } else {\n            $pointer = \u0026$pointer[$part];\n        }\n    }\n\n    $pointer = $value;\n}\n```\n\nThe conversion process produces a different output compared to the one of plain PHP when keys ending with and open square bracket (`[`) are used.\n\nLet\u0027s take for example the following part:\n```\n------WebKitFormBoundary\nContent-Disposition: form-data; name=\"key0[key1][key2][\"\n\nvalue\n------WebKitFormBoundary--\n```\n\nIn plain PHP it would be converted to `Array( [key0] =\u003e Array ( [key1] =\u003e Array ( [key2] =\u003e value) ) )`, while in Bref it would be converted to `Array( [key0] =\u003e Array ( [key1] =\u003e Array ( [key2] =\u003e  ) ) [key0[key1][key2][] =\u003e value )`.\n\n## Impact\n\nBased on the application logic the difference in the body parsing might lead to vulnerabilities and/or undefined behaviors.\n\n## PoC\n\n1. Create a new Bref project.\n2. Create an `index.php` file with the following content:\n```php\n\u003c?php\n\nnamespace App;\n\nrequire __DIR__ . \u0027/vendor/autoload.php\u0027;\n\nuse Nyholm\\Psr7\\Response;\nuse Psr\\Http\\Message\\ResponseInterface;\nuse Psr\\Http\\Message\\ServerRequestInterface;\nuse Psr\\Http\\Server\\RequestHandlerInterface;\n\nclass MyHttpHandler implements RequestHandlerInterface\n{\n    public function handle(ServerRequestInterface $request): ResponseInterface\n    {\n\n        return new Response(200, [], var_export($request-\u003egetParsedBody(),true));\n    }\n}\n\nreturn new MyHttpHandler();\n\n```\n3. Use the following `serverless.yml` to deploy the Lambda:\n```yaml\nservice: app\n\nprovider:\n    name: aws\n    region: eu-central-1\n\nplugins:\n    - ./vendor/bref/bref\n\n# Exclude files from deployment\npackage:\n    patterns:\n        - \u0027!node_modules/**\u0027\n        - \u0027!tests/**\u0027\n\nfunctions:\n    api:\n        handler: index.php\n        runtime: php-83\n        events:\n            - httpApi: \u0027ANY /upload\u0027\n```\n4. Replay the following request after having replaced the `\u003cHOST\u003e` placeholder with the deployed Lambda domain:\n```\nPOST /upload HTTP/2\nHost: \u003cHOST\u003e\nContent-Type: multipart/form-data; boundary=----WebKitFormBoundaryQqDeSZSSvmn2rfjb\nContent-Length: 180\n\n------WebKitFormBoundaryQqDeSZSSvmn2rfjb\nContent-Disposition: form-data; name=\"key0[key1][key2][\"\n\nvalue\n------WebKitFormBoundaryQqDeSZSSvmn2rfjb--\n```\n5. Notice how the body has been parsed.\n6. Create a `plain.php` file with the following content:\n```php\n\u003c?php\n\nvar_dump($_POST);\n```\n7. Start a PHP server inside the project directory (e.g. `php -S 127.0.0.1:8090`).\n8. Replay the following request after having replaced the `\u003cHOST\u003e` placeholder with the PHP server address:\n```\nPOST /plain.php HTTP/1.1\nHost: \u003cHOST\u003e\nContent-Type: multipart/form-data; boundary=----WebKitFormBoundaryQqDeSZSSvmn2rfjb\nContent-Length: 180\n\n------WebKitFormBoundaryQqDeSZSSvmn2rfjb\nContent-Disposition: form-data; name=\"key0[key1][key2][\"\n\nvalue\n------WebKitFormBoundaryQqDeSZSSvmn2rfjb--\n```\n9. Notice the differences in the parsing compared to what observed at step 5.\n\n## Suggested Remediation\n\nUse the PHP function [`parse_str`](https://www.php.net/manual/en/function.parse-str.php) to parse the body parameters to mimic the plain PHP behavior.",
  "id": "GHSA-82vx-mm6r-gg8w",
  "modified": "2024-02-01T22:47:29Z",
  "published": "2024-02-01T22:47:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/brefphp/bref/security/advisories/GHSA-82vx-mm6r-gg8w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24754"
    },
    {
      "type": "WEB",
      "url": "https://github.com/brefphp/bref/commit/c77d9f5abf021f29fa96b5720b7b84adbd199092"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/brefphp/bref"
    },
    {
      "type": "WEB",
      "url": "https://github.com/brefphp/bref/blob/2.1.12/src/Event/Http/Psr7Bridge.php#L130-L168"
    }
  ],
  "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"
    }
  ],
  "summary": "Bref vulnerable to Body Parsing Inconsistency in Event-Driven Functions"
}

GHSA-86C2-4X57-WC8G

Vulnerability from github – Published: 2025-01-14 19:40 – Updated: 2025-01-14 21:59

Summary

Git Credential Manager carriage-return character in remote URL allows malicious repository to leak credentials

Details

Description

The Git credential protocol is text-based over standard input/output, and consists of a series of lines of key-value pairs in the format key=value. Git's documentation restricts the use of the NUL (\0) character and newlines to form part of the keys[^1] or values.

When Git reads from standard input, it considers both LF and CRLF[^2] as newline characters for the credential protocol by virtue of calling strbuf_getline that calls to strbuf_getdelim_strip_crlf. Git also validates that a newline is not present in the value by checking for the presence of the line-feed character (LF, \n), and errors if this is the case. This captures both LF and CRLF-type newlines.

Git Credential Manager uses the .NET standard library StreamReader class to read the standard input stream line-by-line and parse the key=value credential protocol format. The implementation of the ReadLineAsync method considers LF, CRLF, and CR as valid line endings. This is means that .NET considers a single CR as a valid newline character, whereas Git does not.

This mismatch of newline treatment between Git and GCM means that an attacker can craft a malicious remote URL such as:

https://\rhost=targethost@badhost

..which will be interpreted by Git as:

protocol=https
host=badhost
username=\rhost=targethost

This will instead be parsed by GCM as if the following has been passed by Git:

protocol=https
host=badhost
username=
host=targethost

This results in the host field being resolved to the targethost value. GCM will then return a credential for targethost to Git, which will then send this credential to the badhost host.

Impact

When a user clones or otherwise interacts[^3] with a malicious repository that requires authentication, the attacker can capture credentials for another Git remote. The attack is also heightened when cloning from repositories with submodules when using the --recursive clone option as the user is not able to inspect the submodule remote URLs beforehand.

Patches

https://github.com/git-ecosystem/git-credential-manager/compare/749e287571c78a2b61f926ccce6a707050871ab8...99e2f7f60e7364fe807e7925f361a81f3c47bd1b

Workarounds

Only interacting with trusted remote repositories, and do not clone with --recursive to allow inspection of any submodule URLs before cloning those submodules.

Fixed versions

This issue is fixed as of version 2.6.1.

[^1]: The = character is also forbidden to form part of the key. [^2]: Carriage-return character (CR, \r), followed by a line-feed character. [^3]: Any remote operation such as fetch, ls-remote, etc.

Severity

7.4 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.6.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "git-credential-manager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-50338"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-14T19:40:54Z",
    "nvd_published_at": "2025-01-14T19:15:31Z",
    "severity": "HIGH"
  },
  "details": "### Description\nThe [Git credential protocol](https://git-scm.com/docs/git-credential#IOFMT) is text-based over standard input/output, and consists of a series of lines of key-value pairs in the format `key=value`. Git\u0027s documentation restricts the use of the NUL (`\\0`) character and newlines to form part of the keys[^1] or values.\n\nWhen Git reads from standard input, it considers both LF and CRLF[^2] as newline characters for the credential protocol by virtue of [calling `strbuf_getline`](https://github.com/git/git/blob/6a11438f43469f3815f2f0fc997bd45792ff04c0/credential.c#L311) that calls to `strbuf_getdelim_strip_crlf`. Git also validates that a newline is not present in the value by checking for the presence of the line-feed character (LF, `\\n`), and errors if this is the case. This captures both LF and CRLF-type newlines.\n\nGit Credential Manager uses the .NET standard library [`StreamReader`](https://learn.microsoft.com/en-us/dotnet/api/system.io.streamreader?view=net-8.0) class to [read the standard input stream line-by-line](https://github.com/git-ecosystem/git-credential-manager/blob/ae009e11a0fbef804ad9f78816d84a0bc7e052fe/src/shared/Core/StreamExtensions.cs#L138-L141) and parse the `key=value` credential protocol format. The [implementation of the `ReadLineAsync` method](https://github.com/dotnet/runtime/blob/e476b43b5cb42eb44ce23b1c7b793aa361624cf6/src/libraries/System.Private.CoreLib/src/System/IO/StreamReader.cs#L926) considers LF, CRLF, and CR as valid line endings. This is means that .NET considers a single CR as a valid newline character, whereas Git does not.\n\nThis mismatch of newline treatment between Git and GCM means that an attacker can craft a malicious remote URL such as:\n\n```\nhttps://\\rhost=targethost@badhost\n```\n\n..which will be interpreted by Git as:\n\n```\nprotocol=https\nhost=badhost\nusername=\\rhost=targethost\n```\n\nThis will instead be parsed by GCM as if the following has been passed by Git:\n\n```\nprotocol=https\nhost=badhost\nusername=\nhost=targethost\n```\n\nThis results in the `host` field being resolved to the `targethost` value. GCM will then return a credential for `targethost` to Git, which will then send this credential to the `badhost` host.\n\n### Impact\nWhen a user clones or otherwise interacts[^3] with a malicious repository that requires authentication, the attacker can capture credentials for another Git remote. The attack is also heightened when cloning from repositories with submodules when using the `--recursive` clone option as the user is not able to inspect the submodule remote URLs beforehand.\n\n### Patches\nhttps://github.com/git-ecosystem/git-credential-manager/compare/749e287571c78a2b61f926ccce6a707050871ab8...99e2f7f60e7364fe807e7925f361a81f3c47bd1b\n\n### Workarounds\nOnly interacting with trusted remote repositories, and do not clone with `--recursive` to allow inspection of any submodule URLs before cloning those submodules.\n\n### Fixed versions\nThis issue is fixed as of [version 2.6.1](https://github.com/git-ecosystem/git-credential-manager/releases/tag/v2.6.1).\n\n[^1]: The `=` character is also forbidden to form part of the key.\n[^2]: Carriage-return character (CR, `\\r`), followed by a line-feed character.\n[^3]: Any remote operation such as `fetch`, `ls-remote`, etc.",
  "id": "GHSA-86c2-4x57-wc8g",
  "modified": "2025-01-14T21:59:51Z",
  "published": "2025-01-14T19:40:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/git-ecosystem/git-credential-manager/security/advisories/GHSA-86c2-4x57-wc8g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50338"
    },
    {
      "type": "WEB",
      "url": "https://git-scm.com/docs/git-credential#IOFMT"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/runtime/blob/e476b43b5cb42eb44ce23b1c7b793aa361624cf6/src/libraries/System.Private.CoreLib/src/System/IO/StreamReader.cs#L926"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/git-ecosystem/git-credential-manager"
    },
    {
      "type": "WEB",
      "url": "https://github.com/git-ecosystem/git-credential-manager/blob/ae009e11a0fbef804ad9f78816d84a0bc7e052fe/src/shared/Core/StreamExtensions.cs#L138-L141"
    },
    {
      "type": "WEB",
      "url": "https://github.com/git-ecosystem/git-credential-manager/compare/749e287571c78a2b61f926ccce6a707050871ab8...99e2f7f60e7364fe807e7925f361a81f3c47bd1b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/git-ecosystem/git-credential-manager/releases/tag/v2.6.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/git/git/blob/6a11438f43469f3815f2f0fc997bd45792ff04c0/credential.c#L311"
    },
    {
      "type": "WEB",
      "url": "https://learn.microsoft.com/en-us/dotnet/api/system.io.streamreader?view=net-8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Git Credential Manager carriage-return character in remote URL allows malicious repository to leak credentials"
}

GHSA-8FWH-72QQ-GR52

Vulnerability from github – Published: 2026-09-08 21:34 – Updated: 2026-09-08 21:34

Details

Roo-Code through 3.54.0 contains an auto-approve bypass vulnerability that allows attackers to execute denied shell commands by exploiting a word-boundary mismatch in comment handling between the approval gate's shell parser and bash. Attackers can craft a command string with an allowlisted word immediately followed by a hash character, separator, and denied command to pass the approval gate while bash executes the denied command with the agent's auto-execute privileges on the developer's machine.

Severity

8.8 (High)


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

7.7 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-82537"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T19:20:00Z",
    "severity": "HIGH"
  },
  "details": "Roo-Code through 3.54.0 contains an auto-approve bypass vulnerability that allows attackers to execute denied shell commands by exploiting a word-boundary mismatch in comment handling between the approval gate\u0027s shell parser and bash. Attackers can craft a command string with an allowlisted word immediately followed by a hash character, separator, and denied command to pass the approval gate while bash executes the denied command with the agent\u0027s auto-execute privileges on the developer\u0027s machine.",
  "id": "GHSA-8fwh-72qq-gr52",
  "modified": "2026-09-08T21:34:18Z",
  "published": "2026-09-08T21:34:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82537"
    },
    {
      "type": "WEB",
      "url": "https://github.com/7rah/oss-cve/blob/main/roocode-group06-comment-boundary.md"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/roo-code-auto-approve-bypass-via-shell-parser-word-boundary-mismatch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/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-8JR5-V98P-W75M

Vulnerability from github – Published: 2026-06-17 14:02 – Updated: 2026-07-17 16:38

Summary

vLLM: image EXIF Rotation & PNG tRNS Transparency Not Normalized, Causing Mismatch Between Model Input and Expectations

Details

Summary

Issue 1: EXIF orientation not normalized → The image orientation processed by the model differs from how humans view it, introducing interpretation bias.

Issue 2: PNG tRNS not explicitly flattened before converting to RGB → After conversion, transparent/semi-transparent pixels are rendered unexpectedly, making otherwise subtle overlay elements visible and distorting the input content. (This attack is similar to AlphaDog: RGBA handling is already correct in vLLM, but since tRNS permits RGB images, the correct processing path isn’t taken.)

Issue 3 : Pillow only loads the first frame when loading APNG or GIF files.

Root Cause

Rotation: After opening an image, ImageOps.exif_transpose is not called to normalize EXIF orientation.
Transparency: Only RGBA→RGB is flattened with a background; PNGs carrying tRNS in P/L/RGB + tRNS and other non-RGBA modes take the image.convert("RGB") path, which implicitly discards/remaps transparency semantics.

Affected Code

https://github.com/vllm-project/vllm/blob/16b37f3119918c1e5a39f303e0d0892c65c07a90/vllm/multimodal/image.py#L77-L84

https://github.com/vllm-project/vllm/blob/16b37f3119918c1e5a39f303e0d0892c65c07a90/vllm/multimodal/image.py#L37-L43

https://github.com/vllm-project/vllm/blob/16b37f3119918c1e5a39f303e0d0892c65c07a90/vllm/multimodal/image.py#L26-L34

Current state: ImageOps.exif_transpose is not used. (Although the rescale_image_size function (https://github.com/vllm-project/vllm/blob/main/vllm/multimodal/image.py#L14) exists and includes a transpose parameter, I’ve found that it doesn’t seem to be called anywhere outside the test directory.）

Call order: _convert_image_mode runs first; if the conditions are met, convert_image_mode is called.

Issue: Only the “RGBA → RGB” path is explicitly flattened. P, L, or RGB with tRNS all fall back to image.convert("RGB"). For PNGs that include tRNS, convert("RGB") directly produces 24-bit RGB, leading to:

P mode: The transparent index becomes an actual RGB color (often black, white, or an undefined background), so transparency is lost.

L/LA and RGB + tRNS: convert("RGB") doesn’t composite against a chosen background first, so elements that relied on transparency to be hidden or softened become solid.

Impact & Scope

Impact: Pixels the model sees can diverge from operator expectations (due to orientation or transparency handling), potentially altering downstream reasoning.
Scope: The image I/O and mode-conversion paths in vllm/multimodal/image.py. The existing RGBA→RGB flattening is correct; the issues center on missing EXIF normalization and non-RGBA tRNS not being explicitly composited.

Case

EXIF： http://qiniu.funxingzuo.top/exif_orient_180.jpg tRNS: http://qiniu.funxingzuo.top/hello.png

Fix

A fix for this vulnerability was merged here: https://github.com/vllm-project/vllm/pull/44974

Severity

4.8 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.0"
            },
            {
              "fixed": "0.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-12491"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T14:02:42Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nIssue 1: EXIF orientation not normalized \u2192 The image orientation processed by the model differs from how humans view it, introducing interpretation bias.\n\nIssue 2: PNG tRNS not explicitly flattened before converting to RGB \u2192 After conversion, transparent/semi-transparent pixels are rendered unexpectedly, making otherwise subtle overlay elements visible and distorting the input content. (This attack is similar to AlphaDog: RGBA handling is already correct in vLLM, but since tRNS permits RGB images, the correct processing path isn\u2019t taken.)\n\nIssue 3 : Pillow only loads the first frame when loading APNG or GIF files.\n\n---\n\n## Root Cause\n\n* **Rotation**: After opening an image, `ImageOps.exif_transpose` is not called to normalize EXIF orientation.\n* **Transparency**: Only **RGBA\u2192RGB** is flattened with a background; PNGs carrying **`tRNS`** in **`P`/`L`/`RGB + tRNS`** and other non-RGBA modes take the `image.convert(\"RGB\")` path, which implicitly discards/remaps transparency semantics.\n\n---\n\n## Affected Code\n\n\nhttps://github.com/vllm-project/vllm/blob/16b37f3119918c1e5a39f303e0d0892c65c07a90/vllm/multimodal/image.py#L77-L84\n\nhttps://github.com/vllm-project/vllm/blob/16b37f3119918c1e5a39f303e0d0892c65c07a90/vllm/multimodal/image.py#L37-L43\n\nhttps://github.com/vllm-project/vllm/blob/16b37f3119918c1e5a39f303e0d0892c65c07a90/vllm/multimodal/image.py#L26-L34\n\u003e Current state: `ImageOps.exif_transpose` is not used. (Although the `rescale_image_size` function ([https://github.com/vllm-project/vllm/blob/main/vllm/multimodal/image.py#L14](https://github.com/vllm-project/vllm/blob/main/vllm/multimodal/image.py#L14)) exists and includes a `transpose` parameter, I\u2019ve found that it doesn\u2019t seem to be called anywhere outside the `test` directory.\uff09\n\n\u003e **Call order**: `_convert_image_mode` runs first; if the conditions are met, `convert_image_mode` is called.\n\u003e \n\u003e **Issue**: Only the \u201cRGBA \u2192 RGB\u201d path is explicitly flattened. `P`, `L`, or `RGB` with `tRNS` all fall back to `image.convert(\"RGB\")`. For PNGs that include `tRNS`, `convert(\"RGB\")` directly produces 24-bit RGB, leading to:\n\u003e \n\u003e * **`P` mode**: The transparent index becomes an actual RGB color (often black, white, or an undefined background), so transparency is lost.\n\u003e * **`L/LA` and `RGB + tRNS`**: `convert(\"RGB\")` doesn\u2019t composite against a chosen background first, so elements that relied on transparency to be hidden or softened become solid.\n\n\n## Impact \u0026 Scope\n\n* **Impact**: Pixels the model sees can diverge from operator expectations (due to orientation or transparency handling), potentially altering downstream reasoning.\n* **Scope**: The image I/O and mode-conversion paths in `vllm/multimodal/image.py`. The existing **RGBA\u2192RGB** flattening is correct; the issues center on **missing EXIF normalization** and **non-RGBA `tRNS` not being explicitly composited**.\n\n## Case\nEXIF\uff1a http://qiniu.funxingzuo.top/exif_orient_180.jpg\ntRNS:  http://qiniu.funxingzuo.top/hello.png\n\n## Fix\n\nA fix for this vulnerability was merged here: https://github.com/vllm-project/vllm/pull/44974",
  "id": "GHSA-8jr5-v98p-w75m",
  "modified": "2026-07-17T16:38:58Z",
  "published": "2026-06-17T14:02:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-8jr5-v98p-w75m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12491"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/44974"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/cf1c90672404548aa3bc51f92c4745576a65ee26"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-12491"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2489786"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-8jr5-v98p-w75m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-3406.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/vllm"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vLLM: image EXIF Rotation \u0026 PNG tRNS Transparency Not Normalized, Causing Mismatch Between Model Input and Expectations"
}

GHSA-8Q38-W56M-QQ2C

Vulnerability from github – Published: 2023-02-04 09:30 – Updated: 2023-02-14 21:26

Summary

Header injection in TurboGears

Details

A vulnerability classified as critical has been found in OnShift TurboGears 1.0.11.10. This affects an unknown part of the file turbogears/controllers.py of the component HTTP Header Handler. The manipulation leads to http response splitting. It is possible to initiate the attack remotely. Upgrading to version 1.0.11.11 is able to address this issue. The name of the patch is f68bbaba47f4474e1da553aa51564a73e1d92a84. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-220059.

Severity

9.8 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "TurboGears"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.11.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-25101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-14T21:26:39Z",
    "nvd_published_at": "2023-02-04T08:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability classified as critical has been found in OnShift TurboGears 1.0.11.10. This affects an unknown part of the file turbogears/controllers.py of the component HTTP Header Handler. The manipulation leads to http response splitting. It is possible to initiate the attack remotely. Upgrading to version 1.0.11.11 is able to address this issue. The name of the patch is f68bbaba47f4474e1da553aa51564a73e1d92a84. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-220059.",
  "id": "GHSA-8q38-w56m-qq2c",
  "modified": "2023-02-14T21:26:39Z",
  "published": "2023-02-04T09:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25101"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OnShift/turbogears/pull/18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OnShift/turbogears/commit/f68bbaba47f4474e1da553aa51564a73e1d92a84"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OnShift/turbogears"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OnShift/turbogears/releases/tag/v1.0.11.11"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.220059"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.220059"
    }
  ],
  "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"
    }
  ],
  "summary": "Header injection in TurboGears"
}

CWE-436

Interpretation Conflict

Summary

Affected code

Impact

Proof of concept

Remediation

Summary

Affected Packages / Versions

Impact

Technical Details

Remediation

Fix Commit(s)

Release Process Note

Impact

Patches

Workarounds

Impacted Resources

Description

Impact

PoC

Suggested Remediation

Description

Impact

Patches

Workarounds

Fixed versions

Summary

Root Cause

Affected Code

Impact & Scope

Case

Fix

CAPEC-105: HTTP Request Splitting

CAPEC-273: HTTP Response Smuggling

CAPEC-34: HTTP Response Splitting