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

Fission's six-entry capability denylist omitted CAP_SYS_TIME, letting a tenant add it to a Function/Environment PodSpec and rewrite the shared node realtime clock.

- Payout: Research
- Severity: high
- Program: Fission
- Found by: Yanchon918s
- Disclosed: 2026-07-28
- CVE: CVE-2026-50570
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-qf5v-m7p4-95rp
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-qf5v-m7p4-95rp
- Tags: area:cloud domain:cloud domain:infra impact:integrity impact:privesc kind:research platform:ghsa sev:high tech:go tech:kubernetes technique:source-review vuln:access-control vuln:misconfiguration vuln:privilege-escalation

**Target:** Kubernetes admission webhook and executor merge layer for Environment/Function CRDs (podspec_safety.go, merge.go)
**Root cause:** v1.24.0 PodSpec safety validation enforced a fixed denylist of six Linux capabilities on securityContext.capabilities.add instead of an allowlist, omitting SYS_TIME, SYS_RAWIO, BPF, SYS_RESOURCE and MAC_ADMIN; a denylist also cannot constrain OCI default-granted caps like DAC_OVERRIDE.
**Steps:**
1. Create a Function or Environment CRD with `securityContext.capabilities.add: ["SYS_TIME"]` in the container spec.
2. Admission webhook `ValidatePodSpecSafety`/`ValidateContainerSafety` passes because SYS_TIME is not in `dangerousCapabilities`.
3. Executor merge layer `sanitizeContainerSecurityContext`/`dangerousMergeContainerCapabilities` also passes it through.
4. Resulting function/runtime container runs with CAP_SYS_TIME.
5. From inside the container call `clock_settime(CLOCK_REALTIME)` to rewrite the node wall clock.
**How found:** Code review of the newly added v1.24.0 PodSpec safety validation: noticed the capability check was a hardcoded six-entry denylist rather than an allowlist, then reasoned about which dangerous capabilities were missing and which are not namespaced (REALTIME clock) to establish real impact.
**Exploitation:** Tenant with CRD-create rights submits a Function/Environment requesting CAP_SYS_TIME; after admission and merge sanitization the container holds the capability and can set CLOCK_REALTIME, since time namespaces virtualize only MONOTONIC/BOOTTIME. This corrupts TLS/cert validity, Kubernetes lease renewal, token expiry and scheduling for all workloads on the node. Precondition: no restrictive PSA profile on the function-pod namespace.
**Escalation:** Single tenant capability grant escalates to cross-tenant node-wide integrity damage affecting every workload's time-dependent security controls.
**Insight:** When a project ships a security denylist for a securityContext field, enumerate the full kernel capability set (and OCI default cap set) against it — omissions like SYS_TIME are exploitable because REALTIME is never namespaced; also note denylists on capabilities.add can't remove OCI defaults, so only drop:ALL + allowlist is sound.