HIGH 8.8

CVE-2026-46612: Fission Serverless Framework Missing Authentication in Archive Service

Fission, an open-source serverless framework for Kubernetes, has a critical authentication gap in its storage service. Before version 1.23.0, any workload running in the same Kubernetes cluster can access, download, upload, or delete function archives without any credentials or permission checks. This means a compromised pod or malicious insider could steal code from other teams, inject malicious functions, or disrupt service availability.

Source data · NVD / CISA · public domain

CVSS
3.1 · 8.8 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-306
Affected products
0 configuration(s)
Published / Modified
2026-06-10 / 2026-06-17

NVD description (verbatim)

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, the Fission storagesvc component registers archive CRUD handlers (/v1/archive GET / POST / DELETE and /v1/archives list) directly on its HTTP router without performing any authentication or authorization. Any caller able to reach the storagesvc ClusterIP — including any other workload in the same Kubernetes cluster — could enumerate archive IDs, download archives belonging to other tenants, upload arbitrary archive content, and delete archives. This issue has been patched in version 1.23.0.

4 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The storagesvc component in Fission versions prior to 1.23.0 exposes HTTP endpoints for archive operations (/v1/archive, /v1/archives) directly on its ClusterIP without middleware or admission controls. The affected endpoints support GET (download), POST (upload), and DELETE operations. The vulnerability stems from missing authentication and authorization enforcement (CWE-306: Missing Authentication for Critical Function), allowing any network caller with ClusterIP reachability to perform unrestricted CRUD operations on archives that may belong to other tenants or namespaces.

Business impact

In multi-tenant or shared Kubernetes clusters, this vulnerability enables horizontal privilege escalation and cross-tenant data exfiltration. An attacker could extract proprietary function code, intellectual property embedded in archives, and configuration secrets. Additionally, archive deletion or malicious replacement creates operational risk: legitimate functions may fail, or trojaned code could execute in customer environments. Organizations relying on Fission for production workloads face potential compliance violations (data isolation) and supply-chain risks.

Affected systems

Fission versions before 1.23.0 are vulnerable. This includes all deployments of Fission's storagesvc component in Kubernetes clusters, regardless of cloud provider or on-premises infrastructure. The exposure is internal to the cluster; external attackers require prior cluster compromise. However, the low barrier to exploitation within a cluster (any pod can make HTTP requests to ClusterIP addresses) means the risk surface is broad in multi-tenant environments.

Exploitability

Exploitability is high within a Kubernetes cluster. An attacker needs only network access to the storagesvc ClusterIP and basic HTTP client capabilities—no special tools or zero-days required. The CVSS vector (AV:N/AC:L/PR:L) reflects that the attacker must be authenticated to the Kubernetes cluster (PR:L), but once inside, exploitation is trivial: simple curl or HTTP library calls suffice. No user interaction is needed. External exploitation requires prior cluster compromise, which elevates the attack chain complexity but does not mitigate internal risk.

Remediation

Upgrade Fission to version 1.23.0 or later immediately. Verify the upgrade path with the Fission release notes to confirm storagesvc patching. As an interim control pending patch deployment, restrict network policies to limit access to storagesvc ClusterIP only to authorized namespace(s), and audit logs for unexpected archive access patterns. Consider service mesh policies (Istio, Cilium) to enforce mutual TLS and fine-grained authorization, though these do not replace the upstream fix.

Patch guidance

Apply Fission version 1.23.0 or newer according to your deployment model (Helm chart, operator, or manual manifests). Consult the Fission release notes and vendor advisory to confirm patch completeness and any migration steps. Test in a non-production environment first to validate backward compatibility with your function definitions and CI/CD pipelines. Coordinate patching across all Fission deployments in your infrastructure to close the window of exposure.

Detection guidance

Monitor storagesvc logs and network traffic for unusual archive access patterns: repeated GET requests from unexpected pods, POST requests outside normal deployment windows, or DELETE operations. Query audit logs for anomalous calls to /v1/archive and /v1/archives endpoints. Implement Kubernetes network policies to log traffic to storagesvc ClusterIP and review for sources outside the control plane namespace. Consider runtime security tools (Falco, Tetragon) to detect process execution patterns indicative of archive reconnaissance within containers.

Why prioritize this

This vulnerability scores 8.8 (HIGH severity) due to the combination of high confidentiality and integrity impact, low attack complexity, and the ubiquity of multi-tenant Kubernetes clusters. The absence of authentication or authorization—not mere misconfiguration—makes it a design-level flaw. Although the attack vector is internal to the cluster, the ease of exploitation and the sensitivity of function code and embedded secrets justify immediate patching. Organizations should treat this as priority within their Fission estates, especially those running shared clusters or handling regulated workloads.

Risk score, explained

CVSS 3.1 score of 8.8 reflects HIGH severity: Confidentiality Impact (High) due to unauthorized archive download, Integrity Impact (High) due to upload and deletion capabilities, and Availability Impact (High) due to delete operations. Attack Vector (Network) and Attack Complexity (Low) indicate the HTTP API is directly callable. Privileges Required (Low) captures the requirement to be a pod within the cluster—a reasonable constraint in a trusted boundary, but one that fails in multi-tenant scenarios. The lack of User Interaction (None) confirms the flaw is exploitable without social engineering.

Frequently asked questions

Can an external attacker exploit this?

Not directly without first compromising a pod or gaining network access to the Kubernetes cluster. However, if your cluster has ingress controllers, API servers, or other exposed services that a compromised external application can communicate with, lateral movement to storagesvc becomes possible. The vulnerability is primarily a multi-tenant and insider-risk issue.

Does this affect Fission on managed Kubernetes platforms like EKS or GKE?

Yes. Any Fission deployment on any Kubernetes distribution—EKS, GKE, AKS, on-premises—prior to version 1.23.0 is vulnerable. The isolation (or lack thereof) depends on your cluster's network policies and RBAC configuration, but the storagesvc flaw itself is version-specific, not platform-specific.

What if we've isolated Fission to a single namespace?

Namespace isolation is a best practice and reduces blast radius, but does not prevent the vulnerability. Any workload in the same namespace or any workload that can reach the ClusterIP (default: any pod in the cluster) can exploit it. Multi-tenant isolation requires network policies and the upstream patch.

Do we need to rotate secrets after this vulnerability was present?

Yes. If archives may have contained encoded secrets, API keys, or credentials, assume they were accessible to other tenants or pods during the vulnerable window. Perform a secret audit, rotate any credentials embedded in function code or configuration, and assess whether other systems were compromised through exfiltrated secrets.

This analysis is provided for informational and educational purposes and reflects the vulnerability details published as of the source data date. Organizations should verify patch availability, compatibility, and applicability to their specific Fission deployments against official vendor advisories and release notes. SEC.co does not warrant the completeness or suitability of this guidance for any particular environment. Testing patches in non-production environments is strongly recommended before deployment. Consult your organization's security and compliance teams to determine risk posture and remediation timeline. Source: NVD (public-domain), retrieved 2026-07-19. Analysis generated by SEC.co (claude-haiku-4-5).