Executive Summary

CVE-2026-50570 is a security vulnerability in the Fission serverless framework, which runs on Kubernetes. Before version 1.25.0, Fission used a fixed denylist of six Linux capabilities to validate tenant-supplied PodSpec containers, but this list missed critical capabilities like CAP_SYS_TIME.

Because CAP_SYS_TIME was omitted, a tenant with permission to create Function or Environment CRDs could add this capability to their container, bypassing Fission's admission validation and sanitization. This allowed attacker-controlled code to run with CAP_SYS_TIME inside the container.

CAP_SYS_TIME enables manipulation of the shared node wall clock, which can affect other workloads on the same node, including TLS certificates, Kubernetes leases, token expiry, scheduling, and time-series data.

The root cause was that the denylist was structurally incomplete and also ineffective against capabilities granted by default by the OCI runtime. The fix in version 1.25.0 replaced the denylist with a strict allowlist permitting only NET_BIND_SERVICE and enforced dropping all other capabilities.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an attacker tenant to escalate privileges by gaining the CAP_SYS_TIME capability inside their container.

With CAP_SYS_TIME, the attacker can manipulate the shared node's wall clock, which can disrupt co-tenant workloads running on the same Kubernetes node.

• Corruption or invalidation of TLS certificates
• Disruption of Kubernetes leases
• Manipulation of token expiry times
• Interference with scheduling and time-series data

Such disruptions can lead to integrity compromises and potentially mass node-wide outages, severely impacting the reliability and security of your Kubernetes workloads.

Useful 0 Not Useful 0

Detection Guidance

Detection of this vulnerability involves checking if tenant-created Function or Environment CRDs in Fission are requesting or running with dangerous Linux capabilities such as CAP_SYS_TIME that were previously omitted from the denylist.

You can inspect the securityContext.capabilities.add field in the PodSpec of running containers or CRDs to see if capabilities like SYS_TIME are present.

• Use kubectl to describe or get the Function or Environment CRDs and check their PodSpec capabilities, for example: kubectl get functions -o yaml | grep -A 5 capabilities
• Check running pods for added capabilities with: kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.spec.containers[*].securityContext.capabilities.add}{"\n"}{end}'
• Look for containers running with CAP_SYS_TIME or other dangerous capabilities by inspecting container security contexts.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation is to upgrade Fission to version 1.25.0 or later, where the vulnerability is patched.

The fix replaces the incomplete capability denylist with a strict allowlist permitting only NET_BIND_SERVICE, and enforces dropping all other capabilities by default.

Until the upgrade, restrict tenant permissions to create or modify Function or Environment CRDs to trusted users only.

Review and audit existing Function and Environment CRDs for any added dangerous capabilities and remove or redeploy them with safe configurations.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows tenants to gain elevated Linux capabilities such as CAP_SYS_TIME, enabling them to manipulate the shared node wall clock. This manipulation can corrupt TLS certificates, Kubernetes leases, token expiry, scheduling, and time-series data across the node, potentially compromising the integrity of multi-tenant environments.

Such integrity compromises could impact compliance with standards and regulations like GDPR and HIPAA, which require maintaining data integrity and secure access controls. The ability to alter system time and affect security tokens and certificates could lead to unauthorized access or data tampering, thereby violating these regulatory requirements.

The fix implemented in Fission v1.25.0 replaces the incomplete denylist with a strict allowlist aligned with Kubernetes Pod Security Admission's restricted profile, reducing the risk of privilege escalation and helping to maintain compliance with security best practices.

Useful 0 Not Useful 0