Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption (CVE-2026-50570)
Fission versions up to 1.24.0 implemented PodSpec validation with a fixed denylist of Linux capabilities but omitted CAP_SYS_TIME. This omission allows tenants to add CAP_SYS_TIME to their function or environment containers, enabling them to alter the node's real-time clock. Since the Linux real-time clock is shared across the node, this can corrupt time-dependent operations for all workloads on that node. The vulnerability is fixed in Fission 1.25.0 by replacing the denylist with a restrictive allowlist for capabilities. The issue does not apply if a restrictive Pod Security Admission profile is enforced on the function-pod namespace.
AI Analysis
Technical Summary
Fission v1.24.0 introduced PodSpec safety validation for tenant-facing Environment and Function CRDs using a denylist of six Linux capabilities. However, the denylist omitted CAP_SYS_TIME, allowing tenants to request this capability in their container security context. With CAP_SYS_TIME, tenant containers can call clock_settime(CLOCK_REALTIME) to modify the node's shared wall clock, affecting TLS validity, Kubernetes leases, token expiry, scheduling, and time-series data for all node workloads. The denylist also omitted other capabilities, indicating structural incompleteness. The underlying problem is that the denylist approach cannot constrain default OCI runtime capabilities. The fix in v1.25.0 replaces the denylist with a strict allowlist (NET_BIND_SERVICE only) enforced at multiple layers, including admission webhook and executor merge layer, and adds CEL validation rules to reject unsafe configurations. The fix does not yet enforce capabilities.drop:["ALL"] due to compatibility concerns with Fission sidecar containers.
Potential Impact
An attacker tenant able to create Function or Environment CRDs can gain CAP_SYS_TIME in their container, allowing them to modify the node's real-time clock. This compromises node-wide time integrity, disrupting TLS and certificate validation, Kubernetes lease renewals, token expirations, scheduling, and time-series data for all workloads on the node. This represents a high integrity impact with limited availability impact. Other omitted capabilities in the denylist may pose additional risks but were not demonstrated.
Mitigation Recommendations
A fix is available in Fission version 1.25.0, which replaces the capability denylist with a restrictive allowlist and adds admission webhook and API server CEL validation rules to reject unsafe capability additions. Users should upgrade to v1.25.0 or later. Additionally, enforcing a restrictive Pod Security Admission (PSA) profile such as 'restricted' on the function-pod namespace prevents this vulnerability by rejecting pods with unsafe capabilities at creation. The vendor does not currently enforce capabilities.drop:["ALL"] due to sidecar compatibility but plans further improvements.
Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption (CVE-2026-50570)
Description
Fission versions up to 1.24.0 implemented PodSpec validation with a fixed denylist of Linux capabilities but omitted CAP_SYS_TIME. This omission allows tenants to add CAP_SYS_TIME to their function or environment containers, enabling them to alter the node's real-time clock. Since the Linux real-time clock is shared across the node, this can corrupt time-dependent operations for all workloads on that node. The vulnerability is fixed in Fission 1.25.0 by replacing the denylist with a restrictive allowlist for capabilities. The issue does not apply if a restrictive Pod Security Admission profile is enforced on the function-pod namespace.
CVSS v3.1
Score 8.5high
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Fission v1.24.0 introduced PodSpec safety validation for tenant-facing Environment and Function CRDs using a denylist of six Linux capabilities. However, the denylist omitted CAP_SYS_TIME, allowing tenants to request this capability in their container security context. With CAP_SYS_TIME, tenant containers can call clock_settime(CLOCK_REALTIME) to modify the node's shared wall clock, affecting TLS validity, Kubernetes leases, token expiry, scheduling, and time-series data for all node workloads. The denylist also omitted other capabilities, indicating structural incompleteness. The underlying problem is that the denylist approach cannot constrain default OCI runtime capabilities. The fix in v1.25.0 replaces the denylist with a strict allowlist (NET_BIND_SERVICE only) enforced at multiple layers, including admission webhook and executor merge layer, and adds CEL validation rules to reject unsafe configurations. The fix does not yet enforce capabilities.drop:["ALL"] due to compatibility concerns with Fission sidecar containers.
Potential Impact
An attacker tenant able to create Function or Environment CRDs can gain CAP_SYS_TIME in their container, allowing them to modify the node's real-time clock. This compromises node-wide time integrity, disrupting TLS and certificate validation, Kubernetes lease renewals, token expirations, scheduling, and time-series data for all workloads on the node. This represents a high integrity impact with limited availability impact. Other omitted capabilities in the denylist may pose additional risks but were not demonstrated.
Mitigation Recommendations
A fix is available in Fission version 1.25.0, which replaces the capability denylist with a restrictive allowlist and adds admission webhook and API server CEL validation rules to reject unsafe capability additions. Users should upgrade to v1.25.0 or later. Additionally, enforcing a restrictive Pod Security Admission (PSA) profile such as 'restricted' on the function-pod namespace prevents this vulnerability by rejecting pods with unsafe capabilities at creation. The vendor does not currently enforce capabilities.drop:["ALL"] due to sidecar compatibility but plans further improvements.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-qf5v-m7p4-95rp
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-50570"]
- Ecosystems
- ["Go"]
- Database Specific Severity
- HIGH
- Cvss Version
- 3.1
Threat ID: 6a6940a49c2644c7f8686379
Added to database: 07/28/2026, 23:52:04 UTC
Last enriched: 07/29/2026, 11:37:50 UTC
Last updated: 09/10/2026, 19:36:54 UTC
Views: 61
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.