CWE-863

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.22-2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T22:13:53Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nIn `openclaw` versions up to and including `2026.2.22-2`, a non-default exec-approval configuration could allow a skill-name collision to bypass an `ask=on-miss` prompt.\n\nWhen `autoAllowSkills=true`, a path-scoped executable such as `./skill-bin` could resolve to basename `skill-bin`, satisfy the `skills` allowlist segment, and run without prompting for approval.\n\n### Affected Packages / Versions\n- Package: `npm openclaw`\n- Affected versions: `\u003c= 2026.2.22-2`\n- Patched versions: `\u003e= 2026.2.23` (released)\n\n### Configuration Scope (Not Default)\nThis behavior requires non-default settings and does not affect default installs.\n\nRequired conditions:\n- `autoAllowSkills=true` (default is `false`)\n- `system.run` with `security=allowlist`\n- `ask=on-miss`\n\n### Technical Details\nThe allowlist evaluator accepted `skills` satisfaction by bin-name match, so `./skill-bin` could match `skillBins.has(\"skill-bin\")` after resolution.\n\nThe fix hardens skill auto-allow matching by requiring:\n- a pathless invocation token (no `/` or `\\\\`), and\n- a trusted resolved executable path for that skill bin on the machine where skills run.\n\nThis preserves normal `skill-bin ...` behavior while preventing `./\u003cskill-bin\u003e` and absolute-path basename collisions from auto-satisfying `skills`.\n\n### Impact\nIn affected non-default configurations, approval prompts could be skipped for commands that should have required operator confirmation.\n\n### Fix Commit(s)\n- `ffd63b7a2c4c6d5aeb4710ef951d5794ad7ad77b` (`fix(security): trust resolved skill-bin paths in allowlist auto-allow`)\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-7ff8-xjh3-mgh6",
  "modified": "2026-03-03T22:13:53Z",
  "published": "2026-03-03T22:13:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-7ff8-xjh3-mgh6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/ffd63b7a2c4c6d5aeb4710ef951d5794ad7ad77b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s non-default autoAllowSkills setting could bypass on-miss exec prompt"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-26442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T18:15:43Z",
    "severity": "MODERATE"
  },
  "details": "In onCreate of NotificationAccessConfirmationActivity.java, there is a possible incorrect verification of proper intent filters in NLS due to a logic error in the code. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-7fgj-rhf2-g7v4",
  "modified": "2025-09-05T21:32:36Z",
  "published": "2025-09-05T18:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26442"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/packages/apps/Settings/+/63f8849244d1817be2729f522a75424c219e9ecb"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-05-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-14666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-22T15:29:00Z",
    "severity": "HIGH"
  },
  "details": "An improper authorization flaw was found in the Smart Class feature of Foreman. An attacker can use it to change configuration of any host registered in Red Hat Satellite, independent of the organization the host belongs to. This flaw affects all Red Hat Satellite 6 versions.",
  "id": "GHSA-7fqh-mgxh-pgrj",
  "modified": "2022-05-13T01:34:29Z",
  "published": "2022-05-13T01:34:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14666"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14666"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106490"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-37598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-19T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "WP Cerber before 8.9.3 allows bypass of /wp-json access control via a trailing ? character.",
  "id": "GHSA-7fw3-2wmp-j43f",
  "modified": "2022-05-24T19:11:39Z",
  "published": "2022-05-24T19:11:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fireeye/Vulnerability-Disclosures"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fireeye/Vulnerability-Disclosures/blob/master/FEYE-2021-0024/FEYE-2021-0024.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.33.0"
            },
            {
              "fixed": "2.33.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.39.0"
            },
            {
              "fixed": "2.39.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.40.0"
            },
            {
              "fixed": "2.41.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T16:23:45Z",
    "nvd_published_at": "2026-05-28T22:16:59Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPortainer offers an environment-level **Disable bind mounts for non-administrators** security setting that blocks regular users from binding host paths into containers they create through the Portainer-mediated Docker API. The check that enforces this setting only inspected the legacy `HostConfig.Binds` array on the container-create proxy and never looked at the equivalent `HostConfig.Mounts` array. Any authenticated user with rights to create containers on a Docker environment where the restriction is enabled could submit a `bind`-typed entry under `HostConfig.Mounts` and mount any host path into their container.\n\nThe two fields are interchangeable on the Docker daemon \u2014 both produce real bind mounts at runtime \u2014 so a check that inspects only one is functionally equivalent to no check at all. The same primitive is correctly enforced on Swarm service create against `TaskTemplate.ContainerSpec.Mounts`; the gap was specific to the `POST /containers/create` proxy path.\n\nExploitation requires a regular user with container-create rights on an environment that has the restriction enabled. Such a user can mount any host path read-write or read-only into a container they own and use the resulting view of the host filesystem to read or write anything the Docker daemon\u0027s user can \u2014 typically `root`. Bind-mount restriction is the primary defence against host filesystem exposure on shared environments where regular users are otherwise permitted to deploy containers.\n\n## Severity\n\n**High**\n\nThe vulnerability is exploitable over the network with low attack complexity, no attack requirement, and no user interaction. It requires a low-privilege authenticated session \u2014 any regular user with container-create rights on an environment where the bind-mount restriction is enabled. The vulnerable system (the Portainer container-create proxy) suffers a confidentiality and integrity breach by virtue of the bypass itself, but the dominant impact is on the subsequent system: the Docker host\u0027s filesystem and any container running alongside the attacker\u0027s. This is a restriction bypass rather than a cross-authority escalation \u2014 the user already had container-create rights, and the bind-mount restriction is a defence-in-depth control on top of that capability \u2014 which is the reason the rating is held at High rather than promoted to Critical despite the host-level reach.\n\n## Affected Versions\n\nThe vulnerability has existed since the `AllowBindMountsForRegularUsers` security setting was introduced. The `HostConfig.Mounts` field has never been inspected by the container-create proxy on any release line.\n\nFixes are included in the following releases:\n\n| Branch       | First vulnerable | Fixed in   |\n|--------------|------------------|------------|\n| 2.33.x (LTS) | 2.33.0           | **2.33.8** |\n| 2.39.x (LTS) | 2.39.0           | **2.39.2** |\n| 2.41.x (STS) | all prior        | **2.41.0** |\n\nPortainer releases prior to 2.33.0 are end-of-life and will not receive a fix. Users on EOL versions should upgrade to a supported LTS branch.\n\n## Workarounds\n\nAdministrators who cannot immediately upgrade can reduce exposure by:\n\n- **Revoke container-create rights from non-administrator accounts on affected environments.** If the bind-mount restriction is being relied on as a hard guarantee, audit which non-administrator accounts have container-create rights on environments where it is set, and downgrade those accounts to roles that lack container-create until the patched release is deployed. Stack and service deployment that depends on container-create will stop working for those users until the patched release is in place.\n- **Audit recent container creations for `HostConfig.Mounts` of `Type: bind` from non-admin Portainer users.** Inspect Docker daemon logs and `docker inspect` output on affected environments. Any non-admin-created container with a bind-typed `Mounts` entry should be treated as a potential incident.\n- **Segregate tenants by environment.** Where the per-environment toggle was being used to share an environment between tenants of different trust levels, splitting the workloads onto separate environments is a stronger control than the toggle and remains in place after upgrade.\n\nNone of these replace the fix.\n\n## Affected Code\n\nThe enforcement lives in `decorateContainerCreationOperation` in `package/server-ce/api/http/proxy/factory/docker/containers.go`. The `PartialContainer` struct used to deserialise the request body for inspection only contained `HostConfig.Binds`:\n\n```\n// package/server-ce/api/http/proxy/factory/docker/containers.go\ntype PartialContainer struct {\n    HostConfig struct {\n        Privileged bool           `json:\"Privileged\"`\n        PidMode    string         `json:\"PidMode\"`\n        Devices    []any          `json:\"Devices\"`\n        Sysctls    map[string]any `json:\"Sysctls\"`\n        CapAdd     []string       `json:\"CapAdd\"`\n        CapDrop    []string       `json:\"CapDrop\"`\n        Binds      []string       `json:\"Binds\"`\n    } `json:\"HostConfig\"`\n}\n\nif !securitySettings.AllowBindMountsForRegularUsers \u0026\u0026 len(partialContainer.HostConfig.Binds) \u003e 0 {\n    for _, bind := range partialContainer.HostConfig.Binds {\n        if strings.HasPrefix(bind, \"/\") {\n            return forbiddenResponse, ErrBindMountsForbidden\n        }\n    }\n}\n```\n\nThe fix adds a `Mounts` field to `PartialContainer` and a parallel check that rejects any entry whose `Type` equals `bind`, mirroring the existing logic on the Swarm service-create proxy. The container-update path is unaffected \u2014 the Docker daemon does not accept mount changes via container update \u2014 and Swarm service create was already covered. Compose-stack deployment is not in scope of this advisory; the bind-mount restriction is a daemon-mediated container-create control, and Compose deployment runs Docker through a separate path that is not currently subject to the same restriction.\n\nThe same change applies cleanly on each LTS branch \u2014 the surrounding code shape on `release/2.33` and `release/2.39` is identical to develop on the points the patch touches, so the LTS backports are byte-equivalent additions of the `Mounts` field and the parallel check.\n\n## Impact\n\nA regular user who has been explicitly restricted from using bind mounts can bypass the restriction and:\n\n- **Read or write any path on the Docker host filesystem.** The mount runs as the daemon user (typically `root`), so any path is reachable. Sensitive examples include `/etc/shadow`, host SSH keys under `/root/.ssh` and `/home/*/.ssh`, and TLS material under `/etc/docker`.\n- **Compromise other containers on the same host.** The host\u0027s `/var/lib/docker` (or equivalent) is reachable from within the bound mount, exposing the layers, volumes, and live state of every container the daemon manages.\n- **Reach the Docker socket.** Mounting `/var/run/docker.sock` into the attacker\u0027s container hands them full Docker API access on the host, regardless of any authorisation enforced by Portainer above the proxy.\n- **Write persistence to the host.** Without `ReadOnly`, the attacker can drop SSH keys into `authorized_keys`, install systemd units, or modify cron, achieving persistence outside of any container the daemon supervises.\n\nThe bind-mount restriction was the primary defence against this class of host exposure for non-administrator container creators; bypassing it removes the only enforcement point above the daemon for tenants who were granted container-create rights.\n\n## Timeline\n\n- 2026-03-04: Reported via GitHub Security Advisory by **offensiveee** (Assaf Alassaf).\n- 2026-03-04 \u2013 2026-04-17: Six further independent reports of the same primitive received via GitHub Security Advisory (alexwaira, ffulbtech, Proscan-one, jeroengui, AyushParkara, marduc812) and consolidated against this advisory.\n- 2026-04-18: Fix merged to `develop`.\n- 2026-06-04: Backports merged to `release/2.33` and `release/2.39`.\n- 2026-04-29: 2.41.0 released with fix.\n- 2026-05-07: 2.33.8, 2.39.2, released with fix.\n\n## Credit\n\n- **offensiveee** (Assaf Alassaf) \u2014 initial report identifying the `HostConfig.Mounts` bypass on container create and the divergence from the Swarm service-create check.\n- **alexwaira** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **ffulbtech** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **Proscan-one** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **jeroengui** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **AyushParkara** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **marduc812** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.",
  "id": "GHSA-7fw3-x4r2-g7wc",
  "modified": "2026-06-09T10:25:08Z",
  "published": "2026-05-14T16:23:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/security/advisories/GHSA-7fw3-x4r2-g7wc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44850"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/portainer/portainer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.33.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.39.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.41.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Portainer has a bind-mount restriction bypass via HostConfig.Mounts"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.2.0"
            },
            {
              "fixed": "7.7.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.8.0"
            },
            {
              "fixed": "7.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.9.0"
            },
            {
              "fixed": "7.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-2515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-12T20:17:25Z",
    "nvd_published_at": "2023-05-12T09:15:10Z",
    "severity": "HIGH"
  },
  "details": "Mattermost fails to restrict a user with permissions to edit other users and to create personal access tokens from elevating their privileges to system admin\n",
  "id": "GHSA-7g2v-2frm-rg94",
  "modified": "2023-05-23T22:39:22Z",
  "published": "2023-05-12T09:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2515"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost-server"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost Incorrect Authorization vulnerability"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/akuity/kargo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.0-rc.1"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/akuity/kargo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.0-rc.1"
            },
            {
              "fixed": "1.8.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/akuity/kargo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.7.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27112"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-19T15:16:46Z",
    "nvd_published_at": "2026-02-20T22:16:29Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe batch resource creation endpoints of both Kargo\u0027s legacy gRPC API and newer REST API accept multi-document YAML payloads. When either endpoint creates a `Project` resource, creation of subsequent resources from that same payload belonging in that Project\u0027s underlying Kubernetes namespace, by design, proceeds using the API server\u0027s own permissions. The creator of a new Project automatically becomes its administrator, but those permissions are granted asynchronously by the management controller. The design choice to create the affected resources using the API server\u0027s own permissions averts a race and is contextually appropriate.\n\nSpecially crafted payloads can manifest a bug present in the logic of both endpoints to inject arbitrary resources (of specific types only) into the underlying namespace of an _existing_ Project using the API server\u0027s own permissions when that behavior was _not_ intended. Critically, an attacker may exploit this as a vector for elevating their own permissions, which can then be leveraged to achieve remote code execution or secret exfiltration. Exfiltrated artifact repository credentials can be leveraged, in turn, to execute further attacks.\n\nIn some configurations of the Kargo control plane\u0027s underlying Kubernetes cluster, elevated permissions may additionally be leveraged to achieve remote code execution or secret exfiltration using `kubectl`. This can reduce the complexity of the attack, however, worst case scenarios remain entirely achievable even without this.\n\n## Base Metrics\n\nThe following sections provide the rationale for the values selected for each of CVSS v4\u0027s base metrics.\n\n### Attack Vector (AV): Network\n\nThe affected endpoints are served by the Kargo API server over HTTP/HTTPS. No local or physical access is required.\n\n### Attack Complexity (AC): Low\n\nExploitation requires only a specially crafted YAML payload sent to an affected API endpoint.\n\n### Attack Requirements (AT): None\n\nNo specific environmental conditions are required beyond those that are typical for any Kargo instance.\n\n### Privileges Required (PR): Low\n\nThe attack relies only on the ability to authenticate to the Kargo API server along with basic permissions that are typically granted to all Kargo users.\n\n### User Interaction (UI): None\n\nThe attack is fully automated via API calls. No other user needs to take any action.\n\n### Confidentiality Impact to Vulnerable System (VC): High\n\nElevated permissions enable secret exfiltration from any Kargo Project.\n\n### Integrity Impact to Vulnerable System (VI): High\n\nElevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the integrity of the vulnerable system, including Kargo Projects, Kargo control plane components, and the Kargo control plane\u0027s underlying Kubernetes cluster.\n\nNote: Because it is an integral component of Kargo\u0027s control plane, the underlying Kubernetes cluster has been counted as a component of the vulnerable system instead of a subsequent system.\n\n### Availability Impact to Vulnerable System (VA): High\n\nElevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the availability of the vulnerable system, including Kargo control plane components and the Kargo control plane\u0027s underlying Kubernetes cluster.\n\n### Confidentiality Impact to Subsequent Systems (SC): High\n\nSecrets exfiltrated from Project namespaces typically contain credentials for external systems. These may enable exfiltration of further confidential information from those systems.\n\n### Integrity Impact to Subsequent Systems (SI): High\n\nElevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the integrity of subsequent systems.\n\n### Availability Impact to Subsequent Systems (SA): High\n\nElevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the availability of subsequent systems.\n\n## Mitigating Factors\n\n- Exploitation requires authentication to the Kargo API server. Anonymous access is not sufficient.\n\n- The most severe consequences of this vulnerability depend on a privilege escalation path (via `RoleBinding` injection) that was not identified by the original reporter, suggesting it is not immediately obvious from the bug alone.\n\n- There is no evidence of exploitation in the wild.",
  "id": "GHSA-7g9x-cp9g-92mr",
  "modified": "2026-02-23T22:21:26Z",
  "published": "2026-02-19T15:16:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/akuity/kargo/security/advisories/GHSA-7g9x-cp9g-92mr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27112"
    },
    {
      "type": "WEB",
      "url": "https://github.com/akuity/kargo/commit/155c6852ffbffa2902f18e6c7add91a846e8d344"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/akuity/kargo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kargo has an Authorization Bypass Vulnerability in Batch Resource Creation API Endpoints"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "cross-fetch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "cross-fetch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-1365"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-04-28T20:45:25Z",
    "nvd_published_at": "2022-04-15T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "## Withdrawn Advisory\nThis advisory has been withdrawn because the vulnerability originates from a dependency. For more information, see the `Maintainer` comments in https://huntr.com/bounties/ab55dfdd-2a60-437a-a832-e3efe3d264ac.\n\n## Original Description\nWhen fetching a remote url with Cookie if it get Location response header then it will follow that url and try to fetch that url with provided cookie . So cookie is leaked here to thirdparty.\nEx: you try to fetch example.com with cookie and if it get redirect url to attacker.com then it fetch that redirect url with provided cookie .",
  "id": "GHSA-7gc6-qh9x-w6h8",
  "modified": "2025-10-08T19:22:14Z",
  "published": "2022-04-17T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1365"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lquixada/cross-fetch/pull/135"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lquixada/cross-fetch/commit/a3b3a9481091ddd06b8f83784ba9c4e034dc912a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lquixada/cross-fetch"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/ab55dfdd-2a60-437a-a832-e3efe3d264ac"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Withdrawn Advisory: Incorrect Authorization in cross-fetch",
  "withdrawn": "2025-10-08T19:22:14Z"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.5.5"
            },
            {
              "fixed": "14.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-51479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-17T15:09:06Z",
    "nvd_published_at": "2024-12-17T19:15:06Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nIf a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.\n\n### Patches\nThis issue was patched in Next.js `14.2.15` and later.\n\nIf your Next.js application is hosted on Vercel, this vulnerability has been automatically mitigated, regardless of Next.js version.\n\n### Workarounds\nThere are no official workarounds for this vulnerability.\n\n#### Credits\nWe\u0027d like to thank [tyage](http://github.com/tyage) (GMO CyberSecurity by IERAE) for responsible disclosure of this issue.",
  "id": "GHSA-7gfc-8cq8-jh5f",
  "modified": "2025-09-10T21:12:24Z",
  "published": "2024-12-17T15:09:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-7gfc-8cq8-jh5f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/1c8234eb20bc8afd396b89999a00f06b61d72d7b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/releases/tag/v14.2.15"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Next.js authorization bypass vulnerability"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-20332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-06T17:15:38Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the web-based management interface of Cisco ISE could allow an authenticated, remote attacker to modify parts of the configuration on an affected device.\n\nThis vulnerability is due to the lack of server-side validation of Administrator permissions. An attacker could exploit this vulnerability by submitting a crafted HTTP request to an affected system. A successful exploit could allow the attacker to modify descriptions of files on a specific page. To exploit this vulnerability, an attacker would need valid read-only Administrator\u0026nbsp;credentials.",
  "id": "GHSA-7ggc-8fv3-qjpj",
  "modified": "2025-08-06T18:31:21Z",
  "published": "2025-08-06T18:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20332"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise_xss_acc_cont-YsR4uT4U"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}