PYSEC-2024-200

Vulnerability from pysec - Published: 2024-08-08 15:15 - Updated: 2025-01-19 16:22
VLAI?
Details

JupyterHub is software that allows one to create a multi-user server for Jupyter notebooks. Prior to versions 4.1.6 and 5.1.0, if a user is granted the admin:users scope, they may escalate their own privileges by making themselves a full admin user. The impact is relatively small in that admin:users is already an extremely privileged scope only granted to trusted users. In effect, admin:users is equivalent to admin=True, which is not intended. Note that the change here only prevents escalation to the built-in JupyterHub admin role that has unrestricted permissions. It does not prevent users with e.g. groups permissions from granting themselves or other users permissions via group membership, which is intentional. Versions 4.1.6 and 5.1.0 fix this issue.

Severity ?
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Impacted products
Name purl
jupyterhub pkg:pypi/jupyterhub
Aliases
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyterhub",
        "purl": "pkg:pypi/jupyterhub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "99e2720b0fc626cbeeca3c6337f917fdacfaa428"
            },
            {
              "fixed": "ff2db557a85b6980f90c3158634bf924063ab8ba"
            }
          ],
          "repo": "https://github.com/jupyterhub/jupyterhub",
          "type": "GIT"
        },
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.1.0",
        "0.2.0",
        "0.3.0",
        "0.4.0",
        "0.4.1",
        "0.5.0",
        "0.6.0",
        "0.6.1",
        "0.7.0",
        "0.7.0b1",
        "0.7.1",
        "0.7.2",
        "0.8.0",
        "0.8.0b1",
        "0.8.0b2",
        "0.8.0b3",
        "0.8.0b4",
        "0.8.0b5",
        "0.8.0rc1",
        "0.8.0rc2",
        "0.8.1",
        "0.9.0",
        "0.9.0b1",
        "0.9.0b2",
        "0.9.0b3",
        "0.9.0rc1",
        "0.9.1",
        "0.9.2",
        "0.9.3",
        "0.9.4",
        "0.9.5",
        "0.9.6",
        "1.0.0",
        "1.0.0b1",
        "1.0.0b2",
        "1.1.0",
        "1.1.0b1",
        "1.2.0",
        "1.2.0b1",
        "1.2.1",
        "1.2.2",
        "1.3.0",
        "1.4.0",
        "1.4.1",
        "1.4.2",
        "1.5.0",
        "1.5.1",
        "2.0.0",
        "2.0.0b1",
        "2.0.0b2",
        "2.0.0b3",
        "2.0.0rc1",
        "2.0.0rc2",
        "2.0.0rc3",
        "2.0.0rc4",
        "2.0.0rc5",
        "2.0.1",
        "2.0.2",
        "2.1.0",
        "2.1.1",
        "2.2.0",
        "2.2.1",
        "2.2.2",
        "2.3.0",
        "2.3.1",
        "3.0.0",
        "3.0.0b1",
        "3.1.0",
        "3.1.1",
        "4.0.0",
        "4.0.0b1",
        "4.0.0b2",
        "4.0.1",
        "4.0.2",
        "4.1.0",
        "4.1.1",
        "4.1.2",
        "4.1.3",
        "4.1.4",
        "4.1.5"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41942",
    "GHSA-9x4q-3gxw-849f"
  ],
  "details": "JupyterHub is software that allows one to create a multi-user server for Jupyter notebooks. Prior to versions 4.1.6 and 5.1.0, if a user is granted the `admin:users` scope, they may escalate their own privileges by making themselves a full admin user. The impact is relatively small in that `admin:users` is already an extremely privileged scope only granted to trusted users.\nIn effect, `admin:users` is equivalent to `admin=True`, which is not intended. Note that the change here only prevents escalation to the built-in JupyterHub admin role that has unrestricted permissions. It does not prevent users with e.g. `groups` permissions from granting themselves or other users permissions via group membership, which is intentional. Versions 4.1.6 and 5.1.0 fix this issue.",
  "id": "PYSEC-2024-200",
  "modified": "2025-01-19T16:22:58.171761+00:00",
  "published": "2024-08-08T15:15:17+00:00",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/jupyterhub/jupyterhub/security/advisories/GHSA-9x4q-3gxw-849f"
    },
    {
      "type": "FIX",
      "url": "https://github.com/jupyterhub/jupyterhub/commit/99e2720b0fc626cbeeca3c6337f917fdacfaa428"
    },
    {
      "type": "FIX",
      "url": "https://github.com/jupyterhub/jupyterhub/commit/ff2db557a85b6980f90c3158634bf924063ab8ba"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.