Common Weakness Enumeration

CWE-180

Allowed

Incorrect Behavior Order: Validate Before Canonicalize

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.

74 vulnerabilities reference this CWE, most recent first.

GHSA-7RQJ-J65F-68WH

Vulnerability from github – Published: 2026-07-23 14:40 – Updated: 2026-08-12 20:27
VLAI
Summary
Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass
Details

Summary

The default email-address normalizer used by the email/magic-link sign-in flow validates the address before applying Unicode normalization. An address can contain a Unicode character that is not an ASCII @ (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-@ check, but a downstream mail library that normalizes the string then sees two @ separators and may deliver the passwordless sign-in link to a different recipient than intended. This is an instance of validating before canonicalizing.

Am I affected?

You may be affected if all of the following hold:

  • You use next-auth >= 4.0.0, < 4.24.14, or @auth/core >= 0.1.0, < 0.41.3.
  • You have the email / magic-link (passwordless) provider enabled.
  • You rely on the built-in default identifier normalizer (you have not supplied your own normalizeIdentifier).
  • Your sendVerificationRequest implementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do).

You are not affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated.

Impact

  • Account takeover: an attacker who knows a victim's email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim.
  • No victim interaction is required to misroute the link; the attacker initiates the flow.

Patched version

The fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading.

Workarounds

If you cannot upgrade immediately:

  • Supply a custom normalizeIdentifier on the email provider that calls identifier.normalize("NFKC") (and lower-cases/trims) before any validation, and rejects addresses that do not contain exactly one @ after normalization.
  • Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses.

Credit

Reported by @kakashi-kx. Thank you for the responsible disclosure.

Severity
9.1 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/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": "npm",
        "name": "@auth/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "0.41.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.10.3"
            },
            {
              "fixed": "4.24.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.0-beta.31"
      },
      "package": {
        "ecosystem": "npm",
        "name": "next-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-beta.1"
            },
            {
              "fixed": "5.0.0-beta.32"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-23T14:40:15Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe default email-address normalizer used by the email/magic-link sign-in flow validates the address **before** applying Unicode normalization. An address can contain a Unicode character that is not an ASCII `@` (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer\u0027s single-`@` check, but a downstream mail library that normalizes the string then sees two `@` separators and may deliver the passwordless sign-in link to a different recipient than intended. This is an instance of validating before canonicalizing.\n\n## Am I affected?\n\nYou may be affected if **all** of the following hold:\n\n- You use `next-auth` `\u003e= 4.0.0, \u003c 4.24.14`, or `@auth/core` `\u003e= 0.1.0, \u003c 0.41.3`.\n- You have the email / magic-link (passwordless) provider enabled.\n- You rely on the built-in default identifier normalizer (you have not supplied your own `normalizeIdentifier`).\n- Your `sendVerificationRequest` implementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do).\n\nYou are **not** affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated.\n\n## Impact\n\n- Account takeover: an attacker who knows a victim\u0027s email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim.\n- No victim interaction is required to misroute the link; the attacker initiates the flow.\n\n## Patched version\n\nThe fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading.\n\n## Workarounds\n\nIf you cannot upgrade immediately:\n\n- Supply a custom `normalizeIdentifier` on the email provider that calls `identifier.normalize(\"NFKC\")` (and lower-cases/trims) **before** any validation, and rejects addresses that do not contain exactly one `@` after normalization.\n- Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses.\n\n## Credit\n\nReported by @kakashi-kx. Thank you for the responsible disclosure.",
  "id": "GHSA-7rqj-j65f-68wh",
  "modified": "2026-08-12T20:27:03Z",
  "published": "2026-07-23T14:40:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-7rqj-j65f-68wh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/commit/19d2feb24359fa8c79418907fc68d9ec8152ca94"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/commit/a63eee12a1a20cb35209e44195b097868517b9a0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nextauthjs/next-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass"
}

GHSA-86P5-CMGC-C94W

Vulnerability from github – Published: 2026-07-24 09:32 – Updated: 2026-07-24 09:32
VLAI
Details

In Eclipse BaSyx Go Components versions up to and including 1.0.0, ABAC-enabled deployments are vulnerable to an authorization bypass caused by inconsistent trailing-slash handling between the ABAC middleware and the HTTP router.

The shared router configuration used Chi's middleware.StripSlashes, so a request such as GET /shells/ was dispatched to the registered GET /shells route. However, the ABAC middleware evaluated the original request path including the trailing slash. If ABAC route lookup did not find a matching slash-suffixed route, the request was passed onward and the router then stripped the slash and executed the protected handler without the intended ABAC authorization decision and without the expected ABAC query filters.

An unauthenticated or unauthorized network attacker could append a trailing slash to protected API routes to reach handlers that should have been denied by ABAC policy. Depending on the exposed component, HTTP method, and deployed policy, this could allow unauthorized read, create, update, delete, or upload operations.

The issue affects ABAC-enabled deployments of services that use the shared router and ABAC middleware, including AAS Repository, Submodel Repository, AAS Registry, Submodel Registry, Concept Description Repository, Discovery, AAS Environment upload, and related services. The issue is fixed in Eclipse BaSyx Go Components v1.0.1.

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-2026-15704"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-24T09:16:24Z",
    "severity": "CRITICAL"
  },
  "details": "In Eclipse BaSyx Go Components versions up to and including 1.0.0, ABAC-enabled deployments are vulnerable to an authorization bypass caused by inconsistent trailing-slash handling between the ABAC middleware and the HTTP router.\n\n\n\nThe shared router configuration used Chi\u0027s `middleware.StripSlashes`, so a request such as `GET /shells/` was dispatched to the registered `GET /shells` route. However, the ABAC middleware evaluated the original request path including the trailing slash. If ABAC route lookup did not find a matching slash-suffixed route, the request was passed onward and the router then stripped the slash and executed the protected handler without the intended ABAC authorization decision and without the expected ABAC query filters.\n\n\n\nAn unauthenticated or unauthorized network attacker could append a trailing slash to protected API routes to reach handlers that should have been denied by ABAC policy. Depending on the exposed component, HTTP method, and deployed policy, this could allow unauthorized read, create, update, delete, or upload operations.\n\n\n\nThe issue affects ABAC-enabled deployments of services that use the shared router and ABAC middleware, including AAS Repository, Submodel Repository, AAS Registry, Submodel Registry, Concept Description Repository, Discovery, AAS Environment upload, and related services. The issue is fixed in Eclipse BaSyx Go Components v1.0.1.",
  "id": "GHSA-86p5-cmgc-c94w",
  "modified": "2026-07-24T09:32:16Z",
  "published": "2026-07-24T09:32:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15704"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-basyx/basyx-go-components/pull/442"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-basyx/basyx-go-components/releases/tag/v1.0.1"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/164"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/580"
    }
  ],
  "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-89VP-JRXV-24W8

Vulnerability from github – Published: 2026-07-22 23:14 – Updated: 2026-08-12 19:56
VLAI
Summary
JupyterLab: PyPI extension blocklist package-name canonicalization bypass
Details

JupyterLab's PyPI extension manager enforces blocked_extensions_uris by comparing the requested install name to blocklist entries with a custom string normalization that is weaker than PyPI package-name canonicalization. An authenticated user can request a PyPI-equivalent spelling such as JupyterLab.Git for a blocklisted package such as jupyterlab-git; JupyterLab accepts the install request even though pip resolves the variant to the same package.

This has security implications only for deployments that combine all of the following: - an allowlist/blocklist configured with the intent of restricting which packages users can install; - the (default) PyPI Extension Manager enabled; and - kernels and terminals disabled or delegated to remote hosts (otherwise a user with kernel access can install packages directly regardless of this check)

Impact

The vulnerability lets an authenticated user install a package the operator specifically intended to block, defeating the allowlist/blocklist control. Because extensions in principle allow for arbitrary code execution, this vulnerability enables untrusted users to impact the integrity and availability of the jupyter-server instance that was provisioned to them. The user already has access to their own single-user server's data, so installing an extension grants no new read access.

In particular, the integrity of data can be impacted, and any hardening or restrictions on permitted user actions (download/upload limits) within the single-user server can be circumvented. Availability impact on a JupyterHub deployment is limited: while a user can be expected to exhaust their own kernel pod's resources, this vulnerability makes it easier to also exhaust the single-user server resources or generate more requests to shared resources; where limits are absent, resource exhaustion could potentially degrade the wider deployment.

Patches

JupyterLab v4.6.2 and v4.5.10 contain the patch.

Users of applications that depend on JupyterLab, such as Notebook v7+, should update jupyterlab package too.

Workarounds

No action is required for deployments that do not have a custom allow/block list configured. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:

--LabApp.extension_manager=readonly

or the following traitlet:

c.LabApp.extension_manager = 'readonly'

You can confirm that the read-only manager is in use from GUI:

image

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyterlab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.6.0"
            },
            {
              "fixed": "4.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.5.9"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyterlab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.0"
            },
            {
              "fixed": "4.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-180"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T23:14:27Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "JupyterLab\u0027s PyPI extension manager enforces `blocked_extensions_uris` by comparing the requested install name to blocklist entries with a custom string normalization that is weaker than PyPI package-name canonicalization. An authenticated user can request a PyPI-equivalent spelling such as `JupyterLab.Git` for a blocklisted package such as `jupyterlab-git`; JupyterLab accepts the install request even though pip resolves the variant to the same package.\n\nThis has security implications only for deployments that combine all of the following:\n- an allowlist/blocklist configured with the intent of restricting which packages users can install;\n- the (default) PyPI Extension Manager enabled; and\n- kernels and terminals disabled or delegated to remote hosts (otherwise a user with kernel access can install packages directly regardless of this check) \n\n### Impact\n\nThe vulnerability lets an authenticated user install a package the operator specifically intended to block, defeating the allowlist/blocklist control. Because extensions in principle allow for arbitrary code execution, this vulnerability enables untrusted users to impact the integrity and availability of the jupyter-server instance that was provisioned to them. The user already has access to their own single-user server\u0027s data, so installing an extension grants no new read access.\n\nIn particular, the integrity of data can be impacted, and any hardening or restrictions on permitted user actions (download/upload limits) within the single-user server can be circumvented. Availability impact on a JupyterHub deployment is limited: while a user can be expected to exhaust their own kernel pod\u0027s resources, this vulnerability makes it easier to also exhaust the single-user server resources or generate more requests to shared resources; where limits are absent, resource exhaustion could potentially degrade the wider deployment.\n\n### Patches\n\nJupyterLab [`v4.6.2`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2) and [`v4.5.10`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10) contain the patch.\n\nUsers of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.\n\n### Workarounds\n\nNo action is required for deployments that do not have a custom allow/block list configured. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:\n\n```bash\n--LabApp.extension_manager=readonly\n```\n\nor the following traitlet:\n\n```python\nc.LabApp.extension_manager = \u0027readonly\u0027\n```\n\nYou can confirm that the read-only manager is in use from GUI:\n\n\u003cimg width=\"293\" height=\"293\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8016c809-633e-4ed0-a5bc-6bc4793caa0f\" /\u003e",
  "id": "GHSA-89vp-jrxv-24w8",
  "modified": "2026-08-12T19:56:08Z",
  "published": "2026-07-22T23:14:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-89vp-jrxv-24w8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19184"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/commit/be9303f5bcd5308eaeae953c5a3c903046682c2c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/commit/f1beab4a2027af4719d6edc07d52d6cf5a39a432"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyterlab/jupyterlab"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "JupyterLab: PyPI extension blocklist package-name canonicalization bypass"
}

GHSA-8PVW-JCV7-9CMJ

Vulnerability from github – Published: 2026-07-24 16:43 – Updated: 2026-07-24 16:43
VLAI
Summary
@fastify/static vulnerable to Authorization Bypass via Non-Canonical URL Paths
Details

Impact

@fastify/static evaluates the allowedPath callback before normalizing dot segments and duplicate slashes in the pathname used for file resolution. Non-canonical pathnames such as //file, /./file, or /public/../private/file bypass allowedPath filtering while resolving to the intended file on disk.

Applications that use allowedPath as a security boundary to restrict access to specific static files or path subtrees may unintentionally expose files that were intended to be denied.

Patches

Upgrade to @fastify/static >= 10.1.2.

Workarounds

None. Upgrade to the patched version.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@fastify/static"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-7120"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T16:43:44Z",
    "nvd_published_at": "2026-07-23T04:16:33Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`@fastify/static` evaluates the `allowedPath` callback before normalizing dot segments and duplicate slashes in the pathname used for file resolution. Non-canonical pathnames such as `//file`, `/./file`, or `/public/../private/file` bypass `allowedPath` filtering while resolving to the intended file on disk.\n\nApplications that use `allowedPath` as a security boundary to restrict access to specific static files or path subtrees may unintentionally expose files that were intended to be denied.\n\n### Patches\n\nUpgrade to `@fastify/static` \u003e= 10.1.2.\n\n### Workarounds\n\nNone. Upgrade to the patched version.",
  "id": "GHSA-8pvw-jcv7-9cmj",
  "modified": "2026-07-24T16:43:44Z",
  "published": "2026-07-24T16:43:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-static/security/advisories/GHSA-8pvw-jcv7-9cmj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7120"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-static/commit/878c72e920fabacf7e37739bf78057044717bf63"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fastify/fastify-static"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-static/releases/tag/v10.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@fastify/static vulnerable to Authorization Bypass via Non-Canonical URL Paths"
}

GHSA-8R66-VG6C-X88H

Vulnerability from github – Published: 2025-11-25 18:32 – Updated: 2025-11-25 18:32
VLAI
Details

NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper processing of input data. A successful exploit of this vulnerability might lead to information disclosure or denial of service.

Severity
5.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-33194"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-25T18:15:51Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper processing of input data. A successful exploit of this vulnerability might lead to information disclosure or denial of service.",
  "id": "GHSA-8r66-vg6c-x88h",
  "modified": "2025-11-25T18:32:22Z",
  "published": "2025-11-25T18:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33194"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5720"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-33194"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-92H7-Q9M9-98H8

Vulnerability from github – Published: 2025-04-23 15:30 – Updated: 2025-04-23 15:30
VLAI
Details

A directory traversal vulnerability exists in Ivanti LANDesk Management Gateway through 4.2-1.9. By appending %3F.php to the URI of the /client/index.php endpoint, an attacker can bypass access controls and gain unauthorized access to various endpoints such as /client/index.php%3F.php/gsb/firewall.php within the management web panel, potentially exposing sensitive device information. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Severity
5.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-43716"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-23T14:15:29Z",
    "severity": "MODERATE"
  },
  "details": "A directory traversal vulnerability exists in Ivanti LANDesk Management Gateway through 4.2-1.9. By appending %3F.php to the URI of the /client/index.php endpoint, an attacker can bypass access controls and gain unauthorized access to various endpoints such as /client/index.php%3F.php/gsb/firewall.php within the management web panel, potentially exposing sensitive device information. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
  "id": "GHSA-92h7-q9m9-98h8",
  "modified": "2025-04-23T15:30:57Z",
  "published": "2025-04-23T15:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43716"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Graphical-overview-of-the-LANDesk-Management-Gateway-Functionality"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@0xbytehunter/discovery-of-path-traversal-vulnerability-in-landesk-management-gateway-devices-6dba386dd290"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-94VH-GPHV-8PM8

Vulnerability from github – Published: 2025-03-17 21:26 – Updated: 2025-03-19 15:51
VLAI
Summary
zip Incorrectly Canonicalizes Paths during Archive Extraction Leading to Arbitrary File Write
Details

Summary

In the archive extraction routine of affected versions of the zip crate, symbolic links earlier in the archive are allowed to be used for later files in the archive without validation of the final canonicalized path, allowing maliciously crafted archives to overwrite arbitrary files in the file system when extracted.

Details

This is a variant of the zip-slip vulnerability, we can make the extraction logic step outside of the target directory by creating a symlink to the parent directory and then extracting further files through that symlink.

The documentation of the [::zip::read::ZipArchive::extract] method is in my opinion implying this should not happen:

"Paths are sanitized with ZipFile::enclosed_name." ... [::zip::read::FileOptions::enclosed_name] ... is resistant to path-based exploits ... can’t resolve to a path outside the current directory.

Most archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.

PoC

https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85

Impact

Users who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution.

  • zip::unstable::stream::ZipStreamReader::extract
  • zip::read::ZipArchive::extract
Severity
7.3 (High)
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "zip"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-29787"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180",
      "CWE-22",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-17T21:26:32Z",
    "nvd_published_at": "2025-03-17T14:15:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n\nIn the archive extraction routine of affected versions of the `zip` crate, symbolic links earlier in the archive are allowed to be used for later files in the archive without validation of the final canonicalized path, allowing maliciously crafted archives to overwrite arbitrary files in the file system when extracted.\n\n### Details\n\nThis is a variant of the [zip-slip](https://github.com/snyk/zip-slip-vulnerability) vulnerability, we can make the extraction logic step outside of the target directory by creating a symlink to the parent directory and then extracting further files through that symlink.\n\nThe documentation of the [`::zip::read::ZipArchive::extract`] method is in my opinion implying this should not happen:\n\n\u003e \"Paths are sanitized with ZipFile::enclosed_name.\" ...\n\u003e [`::zip::read::FileOptions::enclosed_name`] ... is resistant to path-based exploits ... can\u2019t resolve to a path outside the current directory.\n\n\nMost archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.\n\n### PoC\n\nhttps://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85\n\n### Impact\n\nUsers who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution.\n\n- zip::unstable::stream::ZipStreamReader::extract\n- zip::read::ZipArchive::extract",
  "id": "GHSA-94vh-gphv-8pm8",
  "modified": "2025-03-19T15:51:04Z",
  "published": "2025-03-17T21:26:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zip-rs/zip2/security/advisories/GHSA-94vh-gphv-8pm8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29787"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zip-rs/zip2/commit/a2e062f37066c3b12860a32eb1cb44856cfb7afe"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zip-rs/zip2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zip-rs/zip2/releases/tag/v2.3.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "zip Incorrectly Canonicalizes Paths during Archive Extraction Leading to Arbitrary File Write"
}

GHSA-9RFG-V8G9-9367

Vulnerability from github – Published: 2026-05-26 23:38 – Updated: 2026-06-11 13:30
VLAI
Summary
Fedify has an LD-Signature Bypass via JSON-LD Named-Graph Restructuring
Details

As told on Discord earlier, multiple projects are affected, and we would like to coordinate. For now, we are aiming at a May 6th release date, but this is not set in stone yet.

Summary

An attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received.

Details

The vulnerability essentially boils down to the signature being on the canonical RDF graph representation of the JSON-LD document, and JSON-LD offering many ways to represent the same graph.

One of the issues is that by taking a signed Activity with an embedded object, an attacker can move the top-level Activity to a @graph property and move the activity's object to the top-level. Such a transformation preserves the signature and changes how the payload is interpreted by pretty much all ActivityPub implementations, making them process the object and ignore the formely-top-level activity. This can be used when the graph contains an embedded activity. In Mastodon, that is the case of { "type": "Undo", "object": { "type": "Announce" } }, but other implementations may sign other activities that can be exploited in the same way.

The @reverse keyword can also be used to change the shape of a JSON-LD document without changing the underlying graph, and could be used in a similar way to reverse an Activity and its object.

Another problematic feature is @included, which can be used to “move” properties outside of the normal tree, effectively making them invisible to most ActivityPub implementations, while, again, preserving the signature. This allows removing statuses or actor properties once a signed Create or Update activity is received.

Given that we have seen no use of @graph, @included or @reverse in ActivityPub payloads and that they are very complex to handle correctly (the only JSON-LD API functions that “normalize” @included and @reverse are flattening and framing, which both lose the root node), we have decided to reject them, and recommend you do so as well.

Detection of @graph, @included and @reverse should happen after compacting the incoming activity to your context, as aliases can be used for those keywords.

Additionally, after a quick scan of Fedify's source code, I could not verify that JSON-LD documents with a verified Linked Data Signature were compacted against your local JSON-LD context. Not doing that allows an attacker to rename aliases to non-standard names and use non-mapped aliases to replace existing values, while still leaving the signature intact. This allows an attacker to essentially replace arbitrary portions of any signed JSON-LD document and completely forge any activity while still passing verification. A similar issue was fixed in Mastodon a few years ago: https://github.com/mastodon/mastodon/pull/17426.

Impact

The impact is difficult to assess as this depends on the types of activities that are actually signed and processed in the wild.

The @included keyword allows “removing” arbitrary attributes, thus allowing replaying Create and Update activities while stripping away any attribute, such as content or metadata, which can lead to integrity and availability issues, although confidentiality issues are unlikely.

The @graph and @reverse keywords allow changing the root activity, which in the case of Mastodon allows sending an Announce from a Undo { Announce }, but might have wider consequences depending on what various servers sign.

The lack of compacting can allow rewriting any activity arbitrarily, thus leading to major integrity, availability, and possibly confidentiality issues (e.g. by replacing an actor's inbox).

Severity
7.0 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.10.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42462"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289",
      "CWE-180",
      "CWE-347",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-26T23:38:37Z",
    "nvd_published_at": "2026-06-10T22:16:57Z",
    "severity": "HIGH"
  },
  "details": "As told on Discord earlier, multiple projects are affected, and we would like to coordinate. For now, we are aiming at a May 6th release date, but this is not set in stone yet.\n\n### Summary\n\nAn attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received.\n\n### Details\n\nThe vulnerability essentially boils down to the signature being on the canonical RDF graph representation of the JSON-LD document, and JSON-LD offering many ways to represent the same graph.\n\nOne of the issues is that by taking a signed `Activity` with an embedded `object`, an attacker can move the top-level `Activity` to a `@graph` property and move the activity\u0027s `object` to the top-level. Such a transformation preserves the signature and changes how the payload is interpreted by pretty much all ActivityPub implementations, making them process the object and ignore the formely-top-level activity. This can be used when the graph contains an embedded activity. In Mastodon, that is the case of `{ \"type\": \"Undo\", \"object\": { \"type\": \"Announce\" } }`, but other implementations may sign other activities that can be exploited in the same way.\n\nThe `@reverse` keyword can also be used to change the shape of a JSON-LD document without changing the underlying graph, and could be used in a similar way to reverse an `Activity` and its `object`.\n\nAnother problematic feature is `@included`, which can be used to \u201cmove\u201d properties outside of the normal tree, effectively making them invisible to most ActivityPub implementations, while, again, preserving the signature. This allows removing statuses or actor properties once a signed `Create` or `Update` activity is received.\n\nGiven that we have seen no use of `@graph`, `@included` or `@reverse` in ActivityPub payloads and that they are very complex to handle correctly (the only JSON-LD API functions that \u201cnormalize\u201d `@included` and `@reverse` are flattening and framing, which both lose the root node), we have decided to reject them, and recommend you do so as well.\n\nDetection of `@graph`, `@included` and `@reverse` should happen after compacting the incoming activity to your context, as aliases can be used for those keywords.\n\nAdditionally, after a quick scan of Fedify\u0027s source code, I could not verify that JSON-LD documents with a verified Linked Data Signature were compacted against your local JSON-LD context. Not doing that allows an attacker to rename aliases to non-standard names and use non-mapped aliases to replace existing values, while still leaving the signature intact. This allows an attacker to essentially replace arbitrary portions of any signed JSON-LD document and completely forge any activity while still passing verification. A similar issue was fixed in Mastodon a few years ago: https://github.com/mastodon/mastodon/pull/17426.\n\n### Impact\n\nThe impact is difficult to assess as this depends on the types of activities that are actually signed and processed in the wild.\n\nThe `@included` keyword allows \u201cremoving\u201d arbitrary attributes, thus allowing replaying `Create` and `Update` activities while stripping away any attribute, such as content or metadata, which can lead to integrity and availability issues, although confidentiality issues are unlikely.\n\nThe `@graph` and `@reverse` keywords allow changing the root activity, which in the case of Mastodon allows sending an `Announce` from a `Undo { Announce }`, but might have wider consequences depending on what various servers sign.\n\nThe lack of compacting can allow rewriting any activity arbitrarily, thus leading to major integrity, availability, and possibly confidentiality issues (e.g. by replacing an actor\u0027s `inbox`).",
  "id": "GHSA-9rfg-v8g9-9367",
  "modified": "2026-06-11T13:30:30Z",
  "published": "2026-05-26T23:38:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-9rfg-v8g9-9367"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42462"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fedify-dev/fedify"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fedify-dev/fedify/releases/tag/2.2.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fedify has an LD-Signature Bypass via JSON-LD Named-Graph Restructuring"
}

GHSA-CHQ7-94J8-CJ28

Vulnerability from github – Published: 2026-06-03 21:30 – Updated: 2026-06-03 21:30
VLAI
Summary
Jupyter Enterprise Gateway: ContainerProcessProxy._enforce_prohibited_ids Bypass
Details

Summary

Jupyter Enterprise Gateway has a prohibited UID and GID feature that by default prevents launching kernels with UID or GID 0 (root). This 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.

The feature is described in the documentation:

https://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/docs/source/operators/config-add-env.md?plain=1#L103-L107

https://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/docs/source/operators/config-add-env.md?plain=1#L88-L92

https://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/docs/source/operators/deploy-kubernetes.md?plain=1#L769

Details

The 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.

https://github.com/jupyter-server/enterprise_gateway/blob/152c20f162f2fab700c04c8830ebf8c1e2e2217a/enterprise_gateway/services/processproxies/container.py#L29-L30

The 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).

The 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.

PoC

How it is meant to work

Trying 0 gets denied, as expected.

xh http://enterprise-gateway.bdawg.svc.cluster.local:8888/api/kernels name=python_kubernetes env:='{"KERNEL_POD_NAME":"bdawg", "KERNEL_UID": "0", "KERNEL_GID": "0"}'

HTTP/1.1 403 Kernel's UID value of '0' has been denied via EG_PROHIBITED_UIDS!
Content-Length: 94
Content-Type: application/json
Date: Mon, 14 Jul 2025 12:57:09 GMT
Server: TornadoServer/6.4.1
X-Content-Type-Options: nosniff

{
    "reason": "Kernel's UID value of '0' has been denied via EG_PROHIBITED_UIDS!",
    "message": ""
}

Exploit bypassing the checks

Using 0 with a trailing space, bypasses the check.

xh http://enterprise-gateway.bdawg.svc.cluster.local:8888/api/kernels name=python_kubernetes env:='{"KERNEL_POD_NAME":"bdawg", "KERNEL_UID": "0 ", "KERNEL_GID": "0 "}'

HTTP/1.1 201 Created
Content-Length: 172
Content-Type: application/json
Date: Mon, 14 Jul 2025 14:15:19 GMT
Location: /api/kernels/17eee032-994f-4dd2-8ade-87169c300a40
Server: TornadoServer/6.4.1
X-Content-Type-Options: nosniff

{
    "id": "17eee032-994f-4dd2-8ade-87169c300a40",
    "name": "python_kubernetes",
    "last_activity": "2025-07-14T14:15:21.468155Z",
    "execution_state": "starting",
    "connections": 0
}

The pod is successfully scheduled.

Inspecting the container we can see it is running as root:

kubectl exec -it pod/bdawg -- bash

(base) root@bdawg3:~# id
uid=0(root) gid=0(root) groups=0(root),100(users)

If we had not supplied the KERNEL_UID / KERNEL_GID the container would have been running as UID:GID 1000:100 (jovyan:users).

Impact

This 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.

Organisations running Jupyter Enterprise Gateway to host Jupyter Kernels on at least Kubernetes clusters (I've 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.

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": "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"
}

GHSA-F3MV-W3V5-88QP

Vulnerability from github – Published: 2022-07-21 00:00 – Updated: 2022-08-05 00:00
VLAI
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.

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-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"
    }
  ]
}
Mitigation MIT-20
Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CAPEC-267: Leverage Alternate Encoding

An adversary leverages the possibility to encode potentially harmful input or content used by applications such that the applications are ineffective at validating this encoding standard.

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

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

CAPEC-71: Using Unicode Encoding to Bypass Validation Logic

An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.

CAPEC-78: Using Escaped Slashes in Alternate Encoding

This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.

CAPEC-79: Using Slashes in Alternate Encoding

This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.

CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic

This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters.

← Back to the CWE list