Vulnerability-Lookup

GHSA-7RHF-42QF-VRVC

Vulnerability from github – Published: 2026-09-09 16:34 – Updated: 2026-09-09 16:34

Summary

gix-sec safe.directory protections absent for elevated administrators

Details

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Severity

6.8 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.13.2"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "gix-sec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.13.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-09T16:34:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nIn a process run with full administrative rights on Windows, `gix-sec` wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.\n\n### Details\n\nIn a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of `safe.directory`. [This is because](https://git-scm.com/docs/git.html#_security) of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.\n\nOn Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the `Administrators` group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.\n\nCode in `gix-sec` intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the `Administrators` group, yet instead accidentally examines *itself* again, rather than the directory.\n\nSpecifically, in `gix_sec::identity` the [implementation](https://github.com/GitoxideLabs/gitoxide/blob/main/gix-sec/src/identity.rs#L81) of `is_path_owned_by_current_user` for Windows [finds the owner of the directory](https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L109-L121) (`folder_owner`), [finds the owner of the running thread or process](https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L151-L189) (`token_owner`), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:\n\nhttps://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207\n\nThe [`IsWellKnownSid`](https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-iswellknownsid) call checks if the owner of the current thread or process is the `Administrators` group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the `Administrators` group as the owner, but other [securable objects](https://learn.microsoft.com/en-us/windows/win32/secauthz/securable-objects) as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the *directory* is owned by an administrator. But nothing related to the directory appears in this check.)\n\nThe [`CheckTokenMembership`](https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-checktokenmembership) call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of `NULL`, passed as `0`. But a token handle of `NULL` represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an *administrator*. But nothing related to the `Administrators` group appears in this check.)\n\n### PoC\n\nThese examples use `gix fetch` for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of `gix-sec` checks. \n\n#### Example 1: From inside a shared or user profile directory\n\nOn Windows, running as a limited user account, create a repository in a shared location like `C:\\Users\\Public`, or even within the limited user\u0027s user profile directory. Configure a fake (or, if preferred, real) remote and a value of `core.sshCommand` that runs an arbitrary payload. For example, in PowerShell:\n\n```powershell\ngit init unsafe-repo\ncd unsafe-repo\ngit remote add origin ssh://localhost/repo.git\ngit config core.sshCommand \u0027calc.exe; ssh\u0027\n```\n\nSwitch from the limited account to an administrative account. Then:\n\n1. If gitoxide is not installed, install it, such as with `cargo install gitoxide`.\n2. Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)\n3. This example will not work if the `GIT_SSH_COMMAND` environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running `$env:GIT_SSH_COMMAND = $null`.\n4. `cd` to the limited user\u0027s repository as created above.\n5. Run `gix fetch`. This runs the Windows calculator (the chosen payload).\n\n#### Example 2: From anywhere\n\nOn Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is `C:`--initialize `C:\\` itself as a repository. Set up the repository to run the payload, either by editing `C:\\.git\\config` manually, or by running the `git remote` and `git config` commands from example 1 but passing `-c safe.directory=.`. The second approach is as follows:\n\n```powershell\ncd C:\\\ngit init\ngit -c safe.directory=. remote add origin ssh://localhost/repo.git\ngit -c safe.directory=. config core.sshCommand \u0027calc.exe; ssh\u0027\n```\n\n(`-c safe.directory=.` keeps `git` from refusing to run the `git remote` and `git config` commands on the repository it has just created, whose `.git` directory is under its control but whose working tree is not.)\n\u00a0\nThe entire system drive is now a Git repository due to the presence of `C:\\.git`. The limited user owns this `.git` directory and controls the configuration in it. Normally `safe.directory` protections keep this from being a problem. But they are ineffective for administrators running applications (such as the `gix` command) that use `gix-sec` to enforce those protections.\n\nSwitch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from *any* directory anywhere on the `C:` drive that is not in its own repository. Unless `GIT_CEILING_DIRECTORIES` is set in such a way that keeps `C:\\` from being considered, running `gix fetch` again runs the Windows calculator. This happens even if the command is run from inside the administrator\u0027s own user profile directory.\n\n### Impact\n\nA user is affected only when *all* of the following apply:\n\n- The operating system is Windows.\n- The user is a member of the `Administrators` group.\n- The program is run with the user\u0027s unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)\n- The program uses and relies on information from `gix-sec` about what directories to trust.\n- The program interacts with a repository owned by, and set up or controlled by, another user.\n\nThen operations that would run code present in a repository\u0027s configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.\n\nA malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.\n\nThe specific attack of making the root of the system drive a repository resembles [CVE-2022-24765](https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2). The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.",
  "id": "GHSA-7rhf-42qf-vrvc",
  "modified": "2026-09-09T16:34:36Z",
  "published": "2026-09-09T16:34:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-7rhf-42qf-vrvc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/commit/39e37482d6f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/GitoxideLabs/gitoxide"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gix-sec safe.directory protections absent for elevated administrators"
}

GHSA-7X6Q-3V3M-CWJG

Vulnerability from github – Published: 2023-04-24 16:46 – Updated: 2023-04-24 16:46

Summary

kiwi TCMS has possibility for user to update email address to unverified one

Details

Impact

In previous versions of Kiwi TCMS users were able to update their email addresses via the "My profile" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.

Patches

With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!

Workarounds

No workaround exists.

References

Disclosed by @novemberdad.

Severity

0.0 (None)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "kiwitcms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30544"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-24T16:46:14Z",
    "nvd_published_at": "2023-04-24T17:15:10Z",
    "severity": "LOW"
  },
  "details": "### Impact\nIn previous versions of Kiwi TCMS users were able to update their email addresses via the \"My profile\" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.\n\n### Patches\nWith Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!\n\n### Workarounds\nNo workaround exists.\n\n### References\nDisclosed by [@novemberdad](https://huntr.dev/bounties/1714df73-e639-4d64-ab25-ced82dad9f85/). ",
  "id": "GHSA-7x6q-3v3m-cwjg",
  "modified": "2023-04-24T16:46:14Z",
  "published": "2023-04-24T16:46:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kiwitcms/Kiwi/security/advisories/GHSA-7x6q-3v3m-cwjg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30544"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kiwitcms/Kiwi"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/1714df73-e639-4d64-ab25-ced82dad9f85"
    },
    {
      "type": "WEB",
      "url": "https://kiwitcms.org/blog/kiwi-tcms-team/2023/04/23/kiwi-tcms-122"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kiwi TCMS has possibility for user to update email address to unverified one"
}

GHSA-C73R-QM22-RMXF

Vulnerability from github – Published: 2024-03-15 00:30 – Updated: 2024-03-15 00:30

Details

Zemana AntiLogger v2.74.204.664 is vulnerable to an Arbitrary Process Termination vulnerability by triggering the 0x80002048 IOCTL code of the zam64.sys and zamguard64.sys drivers.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-1853"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-14T23:15:45Z",
    "severity": "MODERATE"
  },
  "details": "Zemana AntiLogger v2.74.204.664 is vulnerable to an Arbitrary Process Termination vulnerability by triggering the 0x80002048 IOCTL code of the zam64.sys and zamguard64.sys drivers.\n\n",
  "id": "GHSA-c73r-qm22-rmxf",
  "modified": "2024-03-15T00:30:22Z",
  "published": "2024-03-15T00:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1853"
    },
    {
      "type": "WEB",
      "url": "https://fluidattacks.com/advisories/ellington"
    },
    {
      "type": "WEB",
      "url": "https://zemana.com/us/antilogger.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FM22-X7F3-GCR6

Vulnerability from github – Published: 2026-09-03 21:31 – Updated: 2026-09-03 21:31

Details

IBM Netezza Software 11.3.0.3 through Interim Fix 002 has operations that are performed without validating bucket ownership using the ExpectedBucketOwner parameter. This omission may allow a remote attacker to exploit misconfigurations or naming collisions to redirect application requests to an unintended S3 bucket under their control.

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-9745"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-03T21:17:24Z",
    "severity": "MODERATE"
  },
  "details": "IBM Netezza Software 11.3.0.3 through Interim Fix 002 has operations that are performed without validating bucket ownership using the ExpectedBucketOwner parameter. This omission may allow a remote attacker to exploit misconfigurations or naming collisions to redirect application requests to an unintended S3 bucket under their control.",
  "id": "GHSA-fm22-x7f3-gcr6",
  "modified": "2026-09-03T21:31:17Z",
  "published": "2026-09-03T21:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9745"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7284359"
    }
  ],
  "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"
    }
  ]
}

GHSA-G7VW-F8P5-C728

Vulnerability from github – Published: 2026-02-17 18:54 – Updated: 2026-02-19 21:30

Summary

Pterodactyl Panel Allows Cross-Node Server Configuration Disclosure via Remote API Missing Authorization

Details

Summary

A missing authorization check in multiple controllers allows any user with access to a node secret token to fetch information about any server on a Pterodactyl instance, even if that server is associated with a different node. This issue stems from missing logic to verify that the node requesting server data is the same node that the server is associated with.

Any authenticated Wings node can retrieve server installation scripts (potentially containing secret values) and manipulate the installation status of servers belonging to other nodes. Wings nodes may also manipulate the transfer status of servers belonging to other nodes.

This vulnerability requires a user to acquire a secret access token for a node. We rated this issue based on potential worst outcome. Unless a user gains access to a Wings secret access token they would not be able to access any of these vulnerable endpoints, as every endpoint requires a valid node access token.

Details

The Remote API endpoint GET /api/remote/servers/{uuid} fetches a server by UUID and returns its complete configuration without verifying that the requesting node owns the server.
Both failure() and success() methods in ServerTransferController fetch servers by UUID without verifying node ownership.
Missing authorization checks in ServerInstallController allow any authenticated Wings node to retrieve egg installation scripts (containing deployment secrets) and manipulate the installation status of servers belonging to other nodes.

Impact

A single compromised Wings node daemon token (stored in plaintext at /etc/pterodactyl/config.yml) grants access to sensitive configuration data of every server on the panel, rather than only to servers that the node has access to. An attacker can use this information to move laterally through the system, send excessive notifications, destroy server data on other nodes, and otherwise exfiltrate secrets that they should not have access to with only a node token.

Additionally, triggering a false transfer success causes the panel to delete the server from the source node, resulting in permanent data loss.

Severity

9.2 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pterodactyl/panel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T18:54:49Z",
    "nvd_published_at": "2026-02-19T17:24:50Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nA missing authorization check in multiple controllers allows any user with access to a node secret token to fetch information about any server on a Pterodactyl instance, even if that server is associated with a different node. This issue stems from missing logic to verify that the node requesting server data is the same node that the server is associated with.\n\nAny authenticated Wings node can retrieve server installation scripts (potentially containing secret values) and manipulate the installation status of servers belonging to other nodes. Wings nodes may also manipulate the transfer status of servers belonging to other nodes.\n\n_This vulnerability requires a user to acquire a secret access token for a node. We rated this issue based on potential worst outcome. Unless a user gains access to a Wings secret access token they would not be able to access any of these vulnerable endpoints, as every endpoint requires a valid node access token._\n\n### Details\n1. The Remote API endpoint `GET /api/remote/servers/{uuid}` fetches a server by UUID and returns its complete configuration without verifying that the requesting node owns the server.\n2. Both failure() and success() methods in `ServerTransferController` fetch servers by UUID without verifying node ownership.\n3. Missing authorization checks in `ServerInstallController` allow any authenticated Wings node to retrieve egg installation scripts (containing deployment secrets) and manipulate the installation status of servers belonging to other nodes.\n\n### Impact\nA single compromised Wings node daemon token (stored in plaintext at `/etc/pterodactyl/config.yml`) grants access to sensitive configuration data of every server on the panel, rather than only to servers that the node has access to. An attacker can use this information to move laterally through the system, send excessive notifications, destroy server data on other nodes, and otherwise exfiltrate secrets that they should not have access to with only a node token.\n\nAdditionally, triggering a false transfer success causes the panel to delete the server from the source node, resulting in permanent data loss.",
  "id": "GHSA-g7vw-f8p5-c728",
  "modified": "2026-02-19T21:30:28Z",
  "published": "2026-02-17T18:54:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/security/advisories/GHSA-g7vw-f8p5-c728"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26016"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pterodactyl/panel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/releases/tag/v1.12.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Pterodactyl Panel Allows Cross-Node Server Configuration Disclosure via Remote API Missing Authorization"
}

GHSA-GFHQ-7499-F3F2

Vulnerability from github – Published: 2026-03-27 15:37 – Updated: 2026-03-27 15:37

Summary

TSPortal: Any user can forge self-deletion requests for any account

Details

Summary

Conversion of empty strings to null allows disguising DPA reports as genuine self-deletion reports.

Details

Creating a DPA report about another user and leaving the evidence field empty causes that report to look like the reported user self-requested deletion of their data. Ingenuine report is not distinguishable from a genuine one.

This can be prevented by disabling convertEmptyStringsToNull in the middleware, or by validating evidence in Http/Controllers/DPAController::store() to not be empty.

PoC

New DPA report -> Select "...someone who I suspect is under the age of 13" for the "The above username is..." field -> Add nothing to the "Evidence" field -> Submit

Impact

Potential unauthorized deletion of any arbitrary user's data both in the current system (TSPortal) and subsequent systems if actioned.

Severity

7.5 (High)


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

8.4 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 29"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "miraheze/ts-portal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "30"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287",
      "CWE-283"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T15:37:10Z",
    "nvd_published_at": "2026-03-06T21:16:15Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nConversion of empty strings to null allows disguising DPA reports as genuine self-deletion reports.\n\n### Details\nCreating a DPA report about another user and leaving the evidence field empty causes that report to look like the reported user self-requested deletion of their data. Ingenuine report is not distinguishable from a genuine one.\n\nThis can be prevented by disabling [convertEmptyStringsToNull](https://api.laravel.com/docs/12.x/Illuminate/Foundation/Configuration/Middleware.html#method_convertEmptyStringsToNull) in the middleware, or by validating `evidence` in Http/Controllers/DPAController::store() to not be empty.\n\n### PoC\nNew DPA report -\u003e Select \"...someone who I suspect is under the age of 13\" for the \"The above username is...\" field -\u003e Add nothing to the \"Evidence\" field -\u003e Submit\n\n### Impact\nPotential unauthorized deletion of any arbitrary user\u0027s data both in the current system (TSPortal) and subsequent systems if actioned.",
  "id": "GHSA-gfhq-7499-f3f2",
  "modified": "2026-03-27T15:37:10Z",
  "published": "2026-03-27T15:37:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/miraheze/TSPortal/security/advisories/GHSA-gfhq-7499-f3f2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29788"
    },
    {
      "type": "WEB",
      "url": "https://api.laravel.com/docs/12.x/Illuminate/Foundation/Configuration/Middleware.html#method_convertEmptyStringsToNull"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/miraheze/TSPortal"
    },
    {
      "type": "WEB",
      "url": "https://issue-tracker.miraheze.org/T15053"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:H/SC:N/SI:L/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "TSPortal: Any user can forge self-deletion requests for any account"
}

GHSA-HJPG-Q85J-GWXX

Vulnerability from github – Published: 2026-09-29 21:33 – Updated: 2026-09-29 21:33

Details

Unverified ownership in Barman snapshot backup deletion allows a principal who can write the backup catalog to cause Barman to delete unrelated cloud snapshots. When a snapshot backup is deleted, either explicitly or by retention policy enforcement, Barman reads the snapshot identifiers from the backup.info file and passes them to the cloud provider's delete API using Barman's own credentials, without verifying that the snapshots belong to that backup. An attacker who can overwrite backup.info but lacks snapshot delete permissions can substitute the identifiers of other snapshots, causing Barman to delete any snapshot its cloud identity can reach on AWS, Microsoft Azure, or Google Cloud. Exploitation requires a deployment where the principal that writes the backup catalog is separate from the identity Barman uses to delete snapshots. Barman versions from 3.4.0 (Google Cloud), 3.6.0 (Azure), and 3.7.0 (AWS) up to and including 3.20.0 are affected. The issue is fixed in Barman 3.20.1.

Severity

7.2 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-93853"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T21:19:39Z",
    "severity": "HIGH"
  },
  "details": "Unverified ownership in Barman snapshot backup deletion allows a principal who can write the backup catalog to cause Barman to delete unrelated cloud snapshots. When a snapshot backup is deleted, either explicitly or by retention policy enforcement, Barman reads the snapshot identifiers from the backup.info file and passes them to the cloud provider\u0027s delete API using Barman\u0027s own credentials, without verifying that the snapshots belong to that backup. An attacker who can overwrite backup.info but lacks snapshot delete permissions can substitute the identifiers of other snapshots, causing Barman to delete any snapshot its cloud identity can reach on AWS, Microsoft Azure, or Google Cloud. Exploitation requires a deployment where the principal that writes the backup catalog is separate from the identity Barman uses to delete snapshots. Barman versions from 3.4.0 (Google Cloud), 3.6.0 (Azure), and 3.7.0 (AWS) up to and including 3.20.0 are affected. The issue is fixed in Barman 3.20.1.",
  "id": "GHSA-hjpg-q85j-gwxx",
  "modified": "2026-09-29T21:33:27Z",
  "published": "2026-09-29T21:33:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93853"
    },
    {
      "type": "WEB",
      "url": "https://www.enterprisedb.com/docs/security/advisories/cve202693853"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-J2VH-3CXM-9W22

Vulnerability from github – Published: 2025-08-27 15:33 – Updated: 2025-08-27 15:33

Details

Dell ThinOS 10, versions prior to 2508_10.0127, contains an Unverified Ownership vulnerability. A local low-privileged attacker could potentially exploit this vulnerability leading to Unauthorized Access.

Severity

7.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-43882"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-27T14:15:51Z",
    "severity": "HIGH"
  },
  "details": "Dell ThinOS 10, versions prior to 2508_10.0127, contains an Unverified Ownership vulnerability. A local low-privileged attacker could potentially exploit this vulnerability leading to Unauthorized Access.",
  "id": "GHSA-j2vh-3cxm-9w22",
  "modified": "2025-08-27T15:33:15Z",
  "published": "2025-08-27T15:33:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43882"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000359619/dsa-2025-331"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J9WF-VVM6-4R9W

Vulnerability from github – Published: 2022-02-08 21:50 – Updated: 2026-06-09 10:51

Summary

Unverified Ownership in Kubernetes

Details

Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.

Severity

5.0 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8554"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-12T21:42:11Z",
    "nvd_published_at": "2021-01-21T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.",
  "id": "GHSA-j9wf-vvm6-4r9w",
  "modified": "2026-06-09T10:51:30Z",
  "published": "2022-02-08T21:50:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8554"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/97076"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/97110"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rdb223e1b82e3d7d8e4eaddce8dd1ab87252e3935cc41c859f49767b6@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rdb223e1b82e3d7d8e4eaddce8dd1ab87252e3935cc41c859f49767b6%40%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcafa485d63550657f068775801aeb706b7a07140a8ebbdef822b3bb3@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcafa485d63550657f068775801aeb706b7a07140a8ebbdef822b3bb3%40%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1975078e44d96f2a199aa90aa874b57a202eaf7f25f2fde6d1c44942@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1975078e44d96f2a199aa90aa874b57a202eaf7f25f2fde6d1c44942%40%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0c76b3d0be348f788cd947054141de0229af00c540564711e828fd40@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0c76b3d0be348f788cd947054141de0229af00c540564711e828fd40%40%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://kubernetes.io/blog/2026/05/26/reconciling-unfixed-kubernetes-cves"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/kubernetes-security-announce/c/iZWsF9nbKE8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubernetes/kubernetes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unverified Ownership in Kubernetes"
}

GHSA-JFV4-H8MC-JCP8

Vulnerability from github – Published: 2026-02-18 17:41 – Updated: 2026-02-23 22:28

Summary

OpenClaw: Process Safety - Unvalidated PID Kill via SIGKILL in Process Cleanup

Details

Summary

OpenClaw CLI process cleanup used system-wide process enumeration and pattern matching to terminate processes without verifying they were owned by the current OpenClaw process. On shared hosts, unrelated processes could be terminated if they matched the pattern.

Affected Packages / Versions

Package: openclaw (npm)
Affected: < 2026.2.14 (including the latest published version 2026.2.13)
Fixed: 2026.2.14 (planned next release)

Details

The CLI runner cleanup helpers could kill processes matched by command-line patterns without validating process ownership.

Fix

Process cleanup is now scoped to owned processes only by filtering to direct child PIDs of the current process (ppid == process.pid) before sending signals.

Hardening follow-ups: - Prefer graceful termination for resume cleanup (SIGTERM, then SIGKILL fallback). - Reduce false negatives from ps argv truncation by preferring wide output (ps -axww) with a fallback. - Tighten command-line token matching to avoid substring matches.

Fix Commit(s)

6084d13b956119e3cf95daaf9a1cae1670ea3557
eb60e2e1b213740c3c587a7ba4dbf10da620ca66

Release Process Note

This advisory is pre-set with patched version 2026.2.14. After 2026.2.14 is published to npm, the remaining step should be to publish this advisory.

Thanks @aether-ai-agent for reporting.

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27486"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-283"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T17:41:09Z",
    "nvd_published_at": "2026-02-21T10:16:12Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nOpenClaw CLI process cleanup used system-wide process enumeration and pattern matching to terminate processes without verifying they were owned by the current OpenClaw process. On shared hosts, unrelated processes could be terminated if they matched the pattern.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected: `\u003c 2026.2.14` (including the latest published version `2026.2.13`)\n- Fixed: `2026.2.14` (planned next release)\n\n## Details\n\nThe CLI runner cleanup helpers could kill processes matched by command-line patterns without validating process ownership.\n\n## Fix\n\nProcess cleanup is now scoped to owned processes only by filtering to direct child PIDs of the current process (`ppid == process.pid`) before sending signals.\n\nHardening follow-ups:\n- Prefer graceful termination for resume cleanup (`SIGTERM`, then `SIGKILL` fallback).\n- Reduce false negatives from `ps` argv truncation by preferring wide output (`ps -axww`) with a fallback.\n- Tighten command-line token matching to avoid substring matches.\n\n## Fix Commit(s)\n\n- 6084d13b956119e3cf95daaf9a1cae1670ea3557\n- eb60e2e1b213740c3c587a7ba4dbf10da620ca66\n\n## Release Process Note\n\nThis advisory is pre-set with patched version `2026.2.14`. After `2026.2.14` is published to npm, the remaining step should be to publish this advisory.\n\nThanks @aether-ai-agent for reporting.",
  "id": "GHSA-jfv4-h8mc-jcp8",
  "modified": "2026-02-23T22:28:47Z",
  "published": "2026-02-18T17:41:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jfv4-h8mc-jcp8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27486"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/6084d13b956119e3cf95daaf9a1cae1670ea3557"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/eb60e2e1b213740c3c587a7ba4dbf10da620ca66"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Process Safety - Unvalidated PID Kill via SIGKILL in Process Cleanup"
}

CWE-283

Unverified Ownership

GHSA-7RHF-42QF-VRVC

Summary

Details

PoC

Example 1: From inside a shared or user profile directory

Example 2: From anywhere

Impact

GHSA-7X6Q-3V3M-CWJG

Impact

Patches

Workarounds

References

GHSA-C73R-QM22-RMXF

GHSA-FM22-X7F3-GCR6

GHSA-G7VW-F8P5-C728

Summary

Details

Impact

GHSA-GFHQ-7499-F3F2

Summary

Details

PoC

Impact

GHSA-HJPG-Q85J-GWXX

GHSA-J2VH-3CXM-9W22

GHSA-J9WF-VVM6-4R9W

GHSA-JFV4-H8MC-JCP8

Summary

Affected Packages / Versions

Details

Fix

Fix Commit(s)

Release Process Note

Mitigation MIT-1

Mitigation MIT-49