Common Weakness Enumeration

CWE-436

Allowed-with-Review

Interpretation Conflict

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

199 vulnerabilities reference this CWE, most recent first.

GHSA-72H4-MXFC-JX37

Vulnerability from github – Published: 2026-04-25 23:30 – Updated: 2026-05-12 13:28
VLAI
Summary
Heimdall: Case-sensitive host matching may lead to policy bypass
Details

Summary

Heimdall performs host matching in a case-sensitive manner, while HTTP hostnames are case-insensitive. This discrepancy can result in heimdall failing to match a rule for a request host that differs only in letter casing, potentially causing the request to be classified differently than intended.

Note: The issue can only lead to unintended access if heimdall is configured with an "allow all" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled, e.g. via --insecure-skip-secure-default-rule-enforcement or the broader --insecure flag.

Details

This vulnerability can potentially be exploited by an adversary if rule matching relies on the request host.

For example, consider the following rule:

id: rule-1
match:
  hosts:
    - type: exact
      value: admin.example.com
execute: # configured to require authentication and authorization
  # ...

If an adversary now sends a request with the Host header set to Admin.Example.Com, rule-1 will not be matched, and the following will happen instead:

  • If no default rule is configured, the request will result in an error (404 Not Found)
  • If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.

Impact

Bypass of access control policies enforced by heimdall may lead to the following consequences:

  • Access to or modification of data that should be restricted
  • Invocation of functionality that is expected to require authentication or authorization
  • In certain configurations, escalation of privileges depending on the exposed functionality

Workarounds

  • Normalize request hosts to lowercase in the layers in front of heimdall.
  • Do not configure a permissive default rule. Respectively, do not make use of the --insecure or the --insecure-skip-secure-default-rule-enforcement flags.
  • When using regex type for host matching, expressions shall be defined in a case-insensitive manner (e.g. (?i)^admin\.example\.com$)
  • Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project's service.
Severity
7.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dadrus/heimdall"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42273"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-25T23:30:18Z",
    "nvd_published_at": "2026-05-08T04:16:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nHeimdall performs host matching in a case-sensitive manner, while HTTP hostnames are case-insensitive. This discrepancy can result in heimdall failing to match a rule for a request host that differs only in letter casing, potentially causing the request to be classified differently than intended.\n\n**Note:** The issue can only lead to unintended access if heimdall is configured with an \"allow all\" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled, e.g. via `--insecure-skip-secure-default-rule-enforcement` or the broader `--insecure` flag.\n\n### Details\n\nThis vulnerability can potentially be exploited by an adversary if rule matching relies on the request host.\n\nFor example, consider the following rule:\n\n```yaml\nid: rule-1\nmatch:\n  hosts:\n    - type: exact\n      value: admin.example.com\nexecute: # configured to require authentication and authorization\n  # ...\n```\n\nIf an adversary now sends a request with the `Host` header set to `Admin.Example.Com`, rule-1 will not be matched, and the following will happen instead:\n\n* If no default rule is configured, the request will result in an error (`404 Not Found`)\n* If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.\n\n### Impact\n\nBypass of access control policies enforced by heimdall may lead to the following consequences:\n\n* Access to or modification of data that should be restricted\n* Invocation of functionality that is expected to require authentication or authorization\n* In certain configurations, escalation of privileges depending on the exposed functionality\n\n### Workarounds\n\n* Normalize request hosts to lowercase in the layers in front of heimdall.\n* Do not configure a permissive default rule. Respectively, do not make use of the `--insecure` or the `--insecure-skip-secure-default-rule-enforcement` flags.\n* When using `regex` type for host matching, expressions shall be defined in a case-insensitive manner (e.g. `(?i)^admin\\.example\\.com$`)\n* Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project\u0027s service.",
  "id": "GHSA-72h4-mxfc-jx37",
  "modified": "2026-05-12T13:28:54Z",
  "published": "2026-04-25T23:30:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-72h4-mxfc-jx37"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42273"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/pull/3208"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/commit/3d05e56a9e7ef0355f17482b4322054af4e85943"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dadrus/heimdall"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/releases/tag/v0.17.14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Heimdall: Case-sensitive host matching may lead to policy bypass"
}

GHSA-754F-8GM6-C4R2

Vulnerability from github – Published: 2025-03-12 20:54 – Updated: 2025-11-03 21:33
VLAI
Summary
Ruby SAML allows a SAML authentication bypass due to namespace handling (parser differential)
Details

Summary

An authentication bypass vulnerability was found in ruby-saml due to a parser differential. ReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack.

Impact

This issue may lead to authentication bypass.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25292"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-12T20:54:42Z",
    "nvd_published_at": "2025-03-12T21:15:42Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAn authentication bypass vulnerability was found in ruby-saml due to a parser differential.\nReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack.\n\n### Impact\nThis issue may lead to authentication bypass.",
  "id": "GHSA-754f-8gm6-c4r2",
  "modified": "2025-11-03T21:33:11Z",
  "published": "2025-03-12T20:54:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-754f-8gm6-c4r2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/omniauth/omniauth-saml/security/advisories/GHSA-hw46-3hmr-x9xv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25292"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/e76c5b36bac40aedbf1ba7ffaaf495be63328cd9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/e9c1cdbd0f9afa467b585de279db0cbd0fb8ae97"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2025/03/12/patch-release-gitlab-17-9-2-released"
    },
    {
      "type": "WEB",
      "url": "https://github.blog/security/sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SAML-Toolkits/ruby-saml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/releases/tag/v1.12.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/releases/tag/v1.18.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/ruby-saml/CVE-2025-25292.yml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=43374519"
    },
    {
      "type": "WEB",
      "url": "https://portswigger.net/research/saml-roulette-the-hacker-always-wins"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250314-0009"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2024-329_GHSL-2024-330_ruby-saml"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ruby SAML allows a SAML authentication bypass due to namespace handling (parser differential)"
}

GHSA-796M-2973-WC5Q

Vulnerability from github – Published: 2026-03-03 22:23 – Updated: 2026-03-03 22:23
VLAI
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
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
VLAI
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
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
VLAI
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
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-82VX-MM6R-GG8W

Vulnerability from github – Published: 2024-02-01 22:47 – Updated: 2024-02-01 22:47
VLAI
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

  1. Create a new Bref project.
  2. 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();
  1. 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'
  1. 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--
  1. Notice how the body has been parsed.
  2. Create a plain.php file with the following content:
<?php

var_dump($_POST);
  1. Start a PHP server inside the project directory (e.g. php -S 127.0.0.1:8090).
  2. 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--
  1. 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
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
VLAI
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
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-8JR5-V98P-W75M

Vulnerability from github – Published: 2026-06-17 14:02 – Updated: 2026-06-18 14:31
VLAI
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
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.0"
            },
            {
              "last_affected": "0.23.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-06-18T14:31:43Z",
  "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": "PACKAGE",
      "url": "https://github.com/vllm-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
VLAI
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
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"
}

GHSA-8QF3-X8V5-2PJ8

Vulnerability from github – Published: 2025-08-07 20:52 – Updated: 2025-08-08 14:54
VLAI
Summary
uv allows ZIP payload obfuscation through parsing differentials
Details

Impact

In versions 0.8.5 and earlier of uv, remote ZIP archives were handled in a streamwise fashion, and file entries were not reconciled against the archive's central directory. This enabled two parser differentials against other Python package installers:

  1. An attacker could contrive a ZIP archive that would extract with legitimate contents on some package installers, and malicious contents on others due to multiple local file entries. The attacker could choose which installer to target.
  2. An attacker could contrive a "stacked" ZIP input with multiple internal ZIPs, which would be handled differently by different package installers. The attacker could choose which installer to target.

In both cases, the outcome is that an attacker can produce a ZIP with a consistent digest that expands differently with different installers.

The ZIP standard is ambiguous with respect to these behavior differentials. Consequently, these same differentials may be accepted ZIP parsers other than those used in uv. This advisory is for uv in particular, but all consumers of ZIP-based Python package distributions, e.g., pip, are potentially susceptible to similar parser differentials in other ZIP parsers.

The practical impact of these differentials is limited by a number of factors:

  • To be compromised via this vulnerability, user interaction of some sort is required. In particular, the user must run uv install $package with an attacker-controlled $package.
  • When using wheel distributions, installation of the malicious package is not sufficient for execution of malicious code, the vicim would need to perform a separate invocation, e.g., python -c "import $package".
  • If a ZIP-based source distribution (which are less common than tarball source distributions), is encountered, malicious code can be executed during package resolution or installation. uv may invoke the malicious code when building the source distribution into a wheel.
  • The practical impact of these differentials is limited by a coordinated fix to Warehouse, PyPI's backend: Warehouse now rejects ZIPs exhibiting these differentials, limiting the ability of an attacker to distribute malicious ZIP distributions via PyPI. As part of that coordinated fix, a review of Warehouse revealed no evidence of exploitation.

Patches

Versions 0.8.6 and newer of uv address both of the parser differentials above, by refusing to process ZIPs with duplicated local file entries or stacked contents.

Workarounds

Users are advised to upgrade to 0.8.6 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. However, users who do experience breakage should carefully review their distributions for signs of malicious intent. Users may choose to set UV_INSECURE_NO_ZIP_VALIDATION=1 to revert to the previous behavior.

Attribution

This vulnerability was discovered separately by two different individuals: Caleb Brown (Google) and Tim Hatch (Netflix).

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "uv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54368"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-07T20:52:44Z",
    "nvd_published_at": "2025-08-08T00:15:26Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nIn versions 0.8.5 and earlier of uv, remote ZIP archives were handled in a streamwise fashion, and file entries were not reconciled against the archive\u0027s central directory. This enabled two parser differentials against other Python package installers:\n\n1. An attacker could contrive a ZIP archive that would extract with legitimate contents on some package installers, and malicious contents on others due to multiple local file entries. The attacker could choose which installer to target.\n2. An attacker could contrive a \"stacked\" ZIP input with multiple internal ZIPs, which would be handled differently by different package installers. The attacker could choose which installer to target.\n\nIn both cases, the outcome is that an attacker can produce a ZIP with a consistent digest that expands differently with different installers.\n\nThe [ZIP standard](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) is ambiguous with respect to these behavior differentials. Consequently, these same differentials may be accepted ZIP parsers other than those used in uv. This advisory is for uv in particular, but all consumers of ZIP-based Python package distributions, e.g., pip, are potentially susceptible to similar parser differentials in other ZIP parsers.\n\nThe practical impact of these differentials is limited by a number of factors:\n\n- To be compromised via this vulnerability, user interaction of some sort is required. In particular, the user must run `uv install $package` with an attacker-controlled `$package`.\n- When using wheel distributions, installation of the malicious package is not sufficient for execution of malicious code, the vicim would need to perform a separate invocation, e.g., `python -c \"import $package\"`.\n- If a ZIP-based source distribution (which are less common than tarball source distributions), is encountered, malicious code can be executed during package resolution or installation. uv may invoke the malicious code when building the source distribution into a wheel.\n- The practical impact of these differentials is limited by a coordinated fix to [Warehouse](https://github.com/pypi/warehouse), PyPI\u0027s backend: Warehouse now rejects ZIPs exhibiting these differentials, limiting the ability of an attacker to distribute malicious ZIP distributions via PyPI. As part of that coordinated fix, a review of Warehouse revealed no evidence of exploitation.\n\n## Patches\n\nVersions 0.8.6 and newer of uv address both of the parser differentials above, by refusing to process ZIPs with duplicated local file entries or stacked contents.\n\n## Workarounds\n\nUsers are advised to upgrade to 0.8.6 or newer to address this advisory.\n\nMost users should experience no breaking changes as a result of the patch above. However, users who do experience breakage should carefully review their distributions for signs of malicious intent. Users may choose to set `UV_INSECURE_NO_ZIP_VALIDATION=1` to revert to the previous behavior.\n\n## Attribution\n\nThis vulnerability was discovered separately by two different individuals: Caleb Brown (Google) and Tim Hatch (Netflix).",
  "id": "GHSA-8qf3-x8v5-2pj8",
  "modified": "2025-08-08T14:54:11Z",
  "published": "2025-08-07T20:52:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/security/advisories/GHSA-8qf3-x8v5-2pj8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54368"
    },
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/commit/7f1eaf48c193e045ca2c62c4581048765c55505f"
    },
    {
      "type": "WEB",
      "url": "https://astral.sh/blog/uv-security-advisory-cve-2025-54368"
    },
    {
      "type": "WEB",
      "url": "https://blog.pypi.org/posts/2025-08-07-wheel-archive-confusion-attacks"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/astral-sh/uv"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "uv allows ZIP payload obfuscation through parsing differentials"
}

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.

← Back to the CWE list