Common Weakness Enumeration

CWE-269

Discouraged

Improper Privilege Management

Abstraction: Class · Status: Draft

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

6487 vulnerabilities reference this CWE, most recent first.

GHSA-QCR8-X47X-6HRG

Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2024-01-04 03:30
VLAI
Details

An elevation of privilege vulnerability exists when the Windows Backup Service improperly handles file operations.To exploit this vulnerability, an attacker would first have to gain execution on the victim system, aka 'Windows Backup Service Elevation of Privilege Vulnerability'.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-1534"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-17T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An elevation of privilege vulnerability exists when the Windows Backup Service improperly handles file operations.To exploit this vulnerability, an attacker would first have to gain execution on the victim system, aka \u0027Windows Backup Service Elevation of Privilege Vulnerability\u0027.",
  "id": "GHSA-qcr8-x47x-6hrg",
  "modified": "2024-01-04T03:30:34Z",
  "published": "2022-05-24T17:25:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1534"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1534"
    }
  ],
  "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-QCRH-JQXF-MGM4

Vulnerability from github – Published: 2024-11-18 06:30 – Updated: 2024-12-24 21:30
VLAI
Details

Delinea Privilege Manager before 12.0.2 mishandles the security of the Windows agent.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-52926"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-276"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-18T04:15:05Z",
    "severity": "HIGH"
  },
  "details": "Delinea Privilege Manager before 12.0.2 mishandles the security of the Windows agent.",
  "id": "GHSA-qcrh-jqxf-mgm4",
  "modified": "2024-12-24T21:30:41Z",
  "published": "2024-11-18T06:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52926"
    },
    {
      "type": "WEB",
      "url": "https://docs.delinea.com/online-help/privilege-manager/release-notes/12.0.2-combined.htm"
    },
    {
      "type": "WEB",
      "url": "https://trust.delinea.com/?tcuUid=3be1a12c-97c9-431e-a51a-0c25da19ec86"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QCVG-4GCH-P3W8

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30
VLAI
Details

Improper privilege management in Azure Entra ID allows an unauthorized attacker to elevate privileges over a network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-23663"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-22T23:16:41Z",
    "severity": "HIGH"
  },
  "details": "Improper privilege management in Azure Entra ID allows an unauthorized attacker to elevate privileges over a network.",
  "id": "GHSA-qcvg-4gch-p3w8",
  "modified": "2026-05-26T13:30:21Z",
  "published": "2026-05-26T13:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23663"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-23663"
    }
  ],
  "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"
    }
  ]
}

GHSA-QCX3-RJRP-J9G7

Vulnerability from github – Published: 2023-08-25 21:30 – Updated: 2024-04-04 07:13
VLAI
Details

Inappropriate implementation in OS in Google Chrome on ChromeOS prior to 75.0.3770.80 allowed a remote attacker to perform OS-level privilege escalation via a malicious file. (Chromium security severity: High)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-13690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-25T19:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "Inappropriate implementation in OS in Google Chrome on ChromeOS prior to 75.0.3770.80 allowed a remote attacker to perform OS-level privilege escalation via a malicious file. (Chromium security severity: High)",
  "id": "GHSA-qcx3-rjrp-j9g7",
  "modified": "2024-04-04T07:13:11Z",
  "published": "2023-08-25T21:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13690"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/chromium/issues/detail?id=960111"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/960111"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QF29-P5HQ-GMJ9

Vulnerability from github – Published: 2025-06-26 06:31 – Updated: 2025-06-26 06:31
VLAI
Details

A potential security vulnerability has been identified in HPE OneView for VMware vCenter (OV4VC). This vulnerability could be exploited allowing an attacker with read only privilege to cause Vertical Privilege Escalation (operator can perform admin actions).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-37101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-26T06:15:23Z",
    "severity": "HIGH"
  },
  "details": "A potential security vulnerability has been identified in HPE OneView for VMware vCenter (OV4VC). This vulnerability could be exploited allowing an attacker with read only privilege to cause Vertical Privilege Escalation (operator can perform admin actions).",
  "id": "GHSA-qf29-p5hq-gmj9",
  "modified": "2025-06-26T06:31:04Z",
  "published": "2025-06-26T06:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37101"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbgn04876en_us\u0026docLocale=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QF34-295C-26V8

Vulnerability from github – Published: 2026-07-14 20:29 – Updated: 2026-07-14 20:29
VLAI
Summary
Woodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend
Details

Impact

A privilege escalation vulnerability affects Woodpecker instances using the Kubernetes backend.

The pipeline option backend_options.kubernetes.serviceAccountName was passed directly to the pod spec without any admin gating.

Who is impacted: any operator running the Kubernetes backend. Any user with Push permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account's RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover.

Patches

https://github.com/woodpecker-ci/woodpecker/pull/6792

Workarounds

Operators who cannot upgrade immediately can mitigate by any of:

  • Restrict Push access on repositories connected to the Kubernetes-backed instance to trusted users only.
  • Harden the pipeline namespace: ensure no privileged ServiceAccount exists or is bound in the namespace where pipeline pods run; keep the default ServiceAccount minimally privileged.
  • Disable ServiceAccount token automounting for ServiceAccounts that should not be used by pipelines.
  • Enforce an admission policy (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy) that rejects pipeline pods setting an unexpected serviceAccountName.
  • Use a dedicated, isolated namespace per org/instance with no sensitive RBAC bindings.

Resources

  • Vulnerable option introduced in commit 609ba481b5e912f59aaae8ca7bc22b44523c5e37
  • Affected versions: v1.0.0 through v3.15.0
  • Source: pipeline/backend/kubernetes/backend_options.go (field ServiceAccountName), pipeline/backend/kubernetes/pod.go (assigned to pod spec with no gating)
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.woodpecker-ci.org/woodpecker/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/woodpecker-ci/woodpecker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "last_affected": "1.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.woodpecker-ci.org/woodpecker/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61549"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T20:29:32Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA privilege escalation vulnerability affects Woodpecker instances using the **Kubernetes backend**.\n\nThe pipeline option `backend_options.kubernetes.serviceAccountName` was passed directly to the pod spec without any admin gating.\n\n**Who is impacted:** any operator running the Kubernetes backend. Any user with **Push** permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account\u0027s RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover.\n\n### Patches\n\nhttps://github.com/woodpecker-ci/woodpecker/pull/6792\n\n### Workarounds\n\nOperators who cannot upgrade immediately can mitigate by any of:\n\n- **Restrict Push access** on repositories connected to the Kubernetes-backed instance to\n  trusted users only.\n- **Harden the pipeline namespace**: ensure no privileged ServiceAccount exists or is bound in\n  the namespace where pipeline pods run; keep the `default` ServiceAccount minimally privileged.\n- **Disable ServiceAccount token automounting** for ServiceAccounts that should not be used by\n  pipelines.\n- **Enforce an admission policy** (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy)\n  that rejects pipeline pods setting an unexpected `serviceAccountName`.\n- **Use a dedicated, isolated namespace** per org/instance with no sensitive RBAC bindings.\n\n### Resources\n\n- Vulnerable option introduced in commit `609ba481b5e912f59aaae8ca7bc22b44523c5e37`\n- Affected versions: `v1.0.0` through `v3.15.0`\n- Source: `pipeline/backend/kubernetes/backend_options.go` (field `ServiceAccountName`),\n  `pipeline/backend/kubernetes/pod.go` (assigned to pod spec with no gating)",
  "id": "GHSA-qf34-295c-26v8",
  "modified": "2026-07-14T20:29:32Z",
  "published": "2026-07-14T20:29:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/woodpecker-ci/woodpecker/security/advisories/GHSA-qf34-295c-26v8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/woodpecker-ci/woodpecker/pull/6792"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/woodpecker-ci/woodpecker"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Woodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend"
}

GHSA-QF3P-7JH5-JMR8

Vulnerability from github – Published: 2022-12-13 21:30 – Updated: 2022-12-13 21:30
VLAI
Details

DirectX Graphics Kernel Elevation of Privilege Vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-44710"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-13T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "DirectX Graphics Kernel Elevation of Privilege Vulnerability.",
  "id": "GHSA-qf3p-7jh5-jmr8",
  "modified": "2022-12-13T21:30:27Z",
  "published": "2022-12-13T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44710"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-44710"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-44710"
    },
    {
      "type": "WEB",
      "url": "https://www.secpod.com/blog/https-www-secpod-com-blog-microsofts-november-2022-patch-tuesday-fixes-48-vulnerabilities-including-2-zero-days"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QF46-MCCV-C8HV

Vulnerability from github – Published: 2022-05-24 17:19 – Updated: 2022-05-24 17:19
VLAI
Details

An elevation of privilege vulnerability exists when the Diagnostics Hub Standard Collector Service improperly handles file operations, aka 'Diagnostics Hub Standard Collector Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-1278, CVE-2020-1293.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-1257"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-09T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An elevation of privilege vulnerability exists when the Diagnostics Hub Standard Collector Service improperly handles file operations, aka \u0027Diagnostics Hub Standard Collector Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2020-1278, CVE-2020-1293.",
  "id": "GHSA-qf46-mccv-c8hv",
  "modified": "2022-05-24T17:19:54Z",
  "published": "2022-05-24T17:19:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1257"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1257"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QF5P-C774-J224

Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2026-08-19 18:31
VLAI
Details

An elevation of privilege vulnerability exists when the Windows Common Log File System (CLFS) driver improperly handles objects in memory, aka 'Windows Common Log File System Driver Elevation of Privilege Vulnerability'.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-1154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-21T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "An elevation of privilege vulnerability exists when the Windows Common Log File System (CLFS) driver improperly handles objects in memory, aka \u0027Windows Common Log File System Driver Elevation of Privilege Vulnerability\u0027.",
  "id": "GHSA-qf5p-c774-j224",
  "modified": "2026-08-19T18:31:24Z",
  "published": "2022-05-24T17:18:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1154"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-1154"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1154"
    }
  ],
  "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-QF5V-M7P4-95RP

Vulnerability from github – Published: 2026-07-28 20:12 – Updated: 2026-07-28 20:12
VLAI
Summary
Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption
Details

Fission v1.24.0 added PodSpec safety validation for tenant-facing Environment and Function CRDs (ValidatePodSpecSafety / ValidateContainerSafety admission webhook + sanitizeContainerSecurityContext executor merge layer), but the capability check was implemented as a fixed denylist of six Linux capabilities (SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE, DAC_READ_SEARCH, DAC_OVERRIDE). The denylist omitted CAP_SYS_TIME, among others. As a result, a tenant who could create a Function or Environment CRD could request securityContext.capabilities.add: ["SYS_TIME"], pass Fission's admission validation and merge-layer sanitization, and run attacker-controlled code with CAP_SYS_TIME in the resulting function or runtime container.

Demonstrated consequence: cross-tenant node integrity damage via CAP_SYS_TIME. The Linux real-time clock is not namespaced — time namespaces virtualize only MONOTONIC and BOOTTIME, never REALTIME — so a tenant container holding CAP_SYS_TIME could call clock_settime(CLOCK_REALTIME) and rewrite the shared node wall clock. That corrupts TLS / certificate validity windows, Kubernetes lease renewal, token expiry, scheduling, and time-series for every workload on the node.

The denylist also omitted SYS_RAWIO, BPF, SYS_RESOURCE, and MAC_ADMIN. Those are documented as evidence that the denylist is structurally incomplete (their practical impact is kernel-, LSM-, or device-cgroup-dependent and is not exercised in this report).

The deeper structural problem: a denylist on capabilities.add cannot constrain capabilities the OCI runtime grants by default — DAC_OVERRIDE is in the OCI default cap set and reaches the container regardless of any add check, partially mooting the denylist for its own entries. A capability allowlist (with drop:["ALL"] to remove the default set) is the only model that addresses both problems.

Affected

  • Project: github.com/fission/fission
  • Versions: <= 1.24.0
  • Audited commits: v1.24.0 tag (ce617120) and current HEAD at audit time
  • Component: pkg/apis/core/v1/podspec_safety.go (dangerousCapabilities) and pkg/executor/util/merge.go (dangerousMergeContainerCapabilities)
  • Pre-condition: cluster does not enforce a restrictive Pod Security Admission (PSA) profile on the function-pod namespace. With PSA restricted in force the API server's PodSecurity admission rejects the pod at creation and this finding does not apply. Fission added its own PodSpec validation precisely because it cannot assume PSA enforcement.

Fix section (paste into the Fix / Patches field)

Fixed in v1.25.0 by:

  • PR #3465 (commit 2569b42b) — replace the denylist with a PSA-restricted allowlist (NET_BIND_SERVICE only) at both enforcement layers:
  • pkg/apis/core/v1/podspec_safety.go — ValidateContainerSafety now rejects any capabilities.add entry not in allowedCapabilities. The container check is invoked from ValidatePodSpecSafety for every PodSpec container / init-container and from Environment.validateForAdmission for the bare Runtime.Container / Builder.Container.
  • pkg/executor/util/merge.go — sanitizeContainerSecurityContext filters capabilities.add through the same allowlist at every merge site (poolmgr / newdeploy / container executor / builder).
  • The same PR adds 21 bounded CEL XValidation rules covering the cheap pod-level invariants (hostNetwork / hostPID / hostIPC / serviceAccountName / serviceAccount override) on FunctionSpec, Runtime, and Builder, plus the bare-Container SecurityContext checks (privileged != true, allowPrivilegeEscalation != true, capabilities.add ⊆ {NET_BIND_SERVICE}) on Runtime and Builder. The API server now short-circuits those attack vectors per CRD apply before the webhook is invoked. Per-container PodSpec iteration stays in the webhook because it exceeds the API server's CEL cost budget.
  • The same PR also adds two forward-compat regression guards in pkg/apis/core/v1/podspec_safety_test.go:
  • TestAllTenantContainerSurfacesAreValidated walks every CRD root type via reflection and fails if any reachable *apiv1.PodSpec or *apiv1.Container field is missing from the hand-maintained known-covered set.
  • TestTenantContainerSurfaces_RejectSysAdmin end-to-end exercises each covered surface and asserts ValidateForAdmission rejects a SYS_ADMIN injection at that exact path.

Not addressed in v1.25.0

The advisory's structural recommendation to force capabilities.drop: ["ALL"] at the merge layer is not part of this fix. Fission's own sidecar containers (fission-fetcher, builder) were authored against the OCI default capability set and need a per-container cap audit before drop:["ALL"] can be applied uniformly. The allowlist on capabilities.add closes the demonstrated CAP_SYS_TIME impact; the OCI-default-cap concern (which the advisory itself marks as conditional / not demonstrated) is tracked separately.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.24.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fission/fission"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-732"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T20:12:45Z",
    "nvd_published_at": "2026-06-10T18:17:13Z",
    "severity": "HIGH"
  },
  "details": "Fission v1.24.0 added PodSpec safety validation for tenant-facing Environment and Function CRDs (`ValidatePodSpecSafety` / `ValidateContainerSafety` admission webhook + `sanitizeContainerSecurityContext` executor merge layer), but the\ncapability check was implemented as a fixed **denylist of six Linux capabilities** (SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE, DAC_READ_SEARCH, DAC_OVERRIDE). The denylist omitted **CAP_SYS_TIME**, among others. As a result, a tenant\nwho could create a Function or Environment CRD could request `securityContext.capabilities.add: [\"SYS_TIME\"]`, pass Fission\u0027s admission validation and merge-layer sanitization, and run attacker-controlled code with `CAP_SYS_TIME` in the\nresulting function or runtime container.\n\nDemonstrated consequence: cross-tenant node integrity damage via `CAP_SYS_TIME`. The Linux real-time clock is not namespaced \u2014 time namespaces virtualize only `MONOTONIC` and `BOOTTIME`, never `REALTIME` \u2014 so a tenant container holding\n`CAP_SYS_TIME` could call `clock_settime(CLOCK_REALTIME)` and rewrite the shared node wall clock. That corrupts TLS / certificate validity windows, Kubernetes lease renewal, token expiry, scheduling, and time-series for every workload on\nthe node.\n\nThe denylist also omitted `SYS_RAWIO`, `BPF`, `SYS_RESOURCE`, and `MAC_ADMIN`. Those are documented as evidence that the denylist is structurally incomplete (their practical impact is kernel-, LSM-, or device-cgroup-dependent and is not\nexercised in this report).\n\nThe deeper structural problem: a denylist on `capabilities.add` cannot constrain capabilities the OCI runtime grants by default \u2014 `DAC_OVERRIDE` is in the OCI default cap set and reaches the container regardless of any `add` check,\npartially mooting the denylist for its own entries. A capability allowlist (with `drop:[\"ALL\"]` to remove the default set) is the only model that addresses both problems.\n\n### Affected\n\n- Project: `github.com/fission/fission`\n- Versions: `\u003c= 1.24.0`\n- Audited commits: v1.24.0 tag (`ce617120`) and current HEAD at audit time\n- Component: `pkg/apis/core/v1/podspec_safety.go` (`dangerousCapabilities`) and `pkg/executor/util/merge.go` (`dangerousMergeContainerCapabilities`)\n- Pre-condition: cluster does not enforce a restrictive Pod Security Admission (PSA) profile on the function-pod namespace. With PSA `restricted` in force the API server\u0027s PodSecurity admission rejects the pod at creation and this\nfinding does not apply. Fission added its own PodSpec validation precisely because it cannot assume PSA enforcement.\n\n\nFix section (paste into the Fix / Patches field)\n\nFixed in [v1.25.0](https://github.com/fission/fission/releases/tag/v1.25.0) by:\n\n- [PR #3465](https://github.com/fission/fission/pull/3465) (commit [`2569b42b`](https://github.com/fission/fission/commit/2569b42b)) \u2014 replace the denylist with a PSA-restricted allowlist (`NET_BIND_SERVICE` only) at both enforcement\nlayers:\n  - `pkg/apis/core/v1/podspec_safety.go` \u2014 `ValidateContainerSafety` now rejects any `capabilities.add` entry not in `allowedCapabilities`. The container check is invoked from `ValidatePodSpecSafety` for every PodSpec container /\ninit-container and from `Environment.validateForAdmission` for the bare `Runtime.Container` / `Builder.Container`.\n  - `pkg/executor/util/merge.go` \u2014 `sanitizeContainerSecurityContext` filters `capabilities.add` through the same allowlist at every merge site (poolmgr / newdeploy / container executor / builder).\n- The same PR adds 21 bounded CEL `XValidation` rules covering the cheap pod-level invariants (`hostNetwork` / `hostPID` / `hostIPC` / `serviceAccountName` / `serviceAccount` override) on `FunctionSpec`, `Runtime`, and `Builder`, plus\nthe bare-Container `SecurityContext` checks (`privileged != true`, `allowPrivilegeEscalation != true`, `capabilities.add \u2286 {NET_BIND_SERVICE}`) on `Runtime` and `Builder`. The API server now short-circuits those attack vectors per CRD\napply before the webhook is invoked. Per-container PodSpec iteration stays in the webhook because it exceeds the API server\u0027s CEL cost budget.\n- The same PR also adds two forward-compat regression guards in `pkg/apis/core/v1/podspec_safety_test.go`:\n  - `TestAllTenantContainerSurfacesAreValidated` walks every CRD root type via reflection and fails if any reachable `*apiv1.PodSpec` or `*apiv1.Container` field is missing from the hand-maintained known-covered set.\n  - `TestTenantContainerSurfaces_RejectSysAdmin` end-to-end exercises each covered surface and asserts `ValidateForAdmission` rejects a `SYS_ADMIN` injection at that exact path.\n\n### Not addressed in v1.25.0\n\nThe advisory\u0027s structural recommendation to force `capabilities.drop: [\"ALL\"]` at the merge layer is **not** part of this fix. Fission\u0027s own sidecar containers (`fission-fetcher`, builder) were authored against the OCI default capability\nset and need a per-container cap audit before `drop:[\"ALL\"]` can be applied uniformly. The allowlist on `capabilities.add` closes the demonstrated `CAP_SYS_TIME` impact; the OCI-default-cap concern (which the advisory itself marks as\nconditional / not demonstrated) is tracked separately.",
  "id": "GHSA-qf5v-m7p4-95rp",
  "modified": "2026-07-28T20:12:45Z",
  "published": "2026-07-28T20:12:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/security/advisories/GHSA-qf5v-m7p4-95rp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50570"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/pull/3465"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/commit/2569b42bfadbcb7d78b55a00a60f77937e522699"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fission/fission"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/releases/tag/v1.25.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption"
}

Mitigation MIT-1
Architecture and Design Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Mitigation MIT-48
Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Mitigation MIT-49
Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

CAPEC-122: Privilege Abuse

An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.

CAPEC-233: Privilege Escalation

An adversary exploits a weakness enabling them to elevate their privilege and perform an action that they are not supposed to be authorized to perform.

CAPEC-58: Restful Privilege Elevation

An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.