Skip to content

Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption

High severity GitHub Reviewed Published Jun 8, 2026 in fission/fission • Updated Jul 28, 2026

Package

gomod github.com/fission/fission (Go)

Affected versions

<= 1.24.0

Patched versions

1.25.0

Description

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.goValidateContainerSafety 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.gosanitizeContainerSecurityContext 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.

References

@sanketsudake sanketsudake published to fission/fission Jun 8, 2026
Published by the National Vulnerability Database Jun 10, 2026
Published to the GitHub Advisory Database Jul 28, 2026
Reviewed Jul 28, 2026
Last updated Jul 28, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
None
Integrity
High
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(19th percentile)

Weaknesses

Improper Privilege Management

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

Incorrect Permission Assignment for Critical Resource

The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors. Learn more on MITRE.

CVE ID

CVE-2026-50570

GHSA ID

GHSA-qf5v-m7p4-95rp

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.