Listen to this Post
How CVE-2026-49823 Works
Fission is an open-source, Kubernetes-native serverless framework that allows users to deploy functions and applications on Kubernetes. Prior to version 1.24.0, a Fission Function specification (Function.spec) carried three reference types: Secret, ConfigMap, and Package. These references allow a function to pull in external configurations, credentials, and deployable code packages.
The Fission admission webhook (pkg/webhook/function.go) acts as a security gatekeeper, validating all resource specifications before they are persisted in the cluster. For `Secret` and `ConfigMap` references, the webhook correctly enforced namespace boundaries, ensuring that a function could only reference resources within its own namespace. However, the validation logic failed to apply the same protective measure to PackageRef.Namespace. This inconsistency meant that while `spec.secrets[].namespace` and `spec.configmaps[].namespace` were strictly checked, `spec.package.packageref.namespace` was not validated at all.
This flaw created a confused-deputy scenario. A tenant with the `functions.fission.io/create` permission in their own namespace (e.g., ns-attacker) could set `spec.package.packageref.namespace` to any other namespace (e.g., ns-victim). When the malicious function was invoked, the `fission-fetcher` sidecar, which runs with a service account that holds `get packages` permissions across all configured function namespaces, would read the victim’s `Package` from the target namespace. It would then write the contents of that package—including the victim’s source code and any embedded credentials—directly to `/userfunc/deployarchive` inside the attacker’s pool pod. Because the namespace check was the only barrier preventing cross-namespace access, this validation omission effectively gave attackers the ability to read the deployment archive of any `Package` in any other namespace.
The vulnerability was patched in version 1.24.0. The fix introduces a check in the admission webhook’s `Validate` function (pkg/webhook/function.go) that rejects any `Function.spec.package.packageref.namespace` that is not empty and does not equal the function’s own metadata.namespace. Empty values remain accepted, as controllers will default them to the function’s own namespace. This fix was shipped alongside a cross-namespace check for `EnvironmentRef` (CVE-2026-49824 / GHSA-cvw6-gfvv-953q). The behavioral change is that functions explicitly setting `spec.package.packageref.namespace` to a different namespace are now rejected at admission.
DailyCVE Form
Platform: `Fission`
Version: `< 1.24.0`
Vulnerability: `CVE-2026-49823`
Severity: `HIGH (CVSS 7.7)`
Date: `2026-06-10`
Prediction: `2026-06-06 (v1.24.0)`
Analytics — What Undercode Say:
Check current Fission version
kubectl get deployment -n fission fission-controller -o jsonpath='{.spec.template.spec.containers[bash].image}'
List all Functions and check for suspicious cross-namespace package references
kubectl get functions -A -o json | jq '.items[] | select(.spec.package.packageref.namespace != null and .spec.package.packageref.namespace != .metadata.namespace)'
Check RBAC permissions for the fission-fetcher service account
kubectl describe clusterrole fission-function-getter
Malicious Function spec (pre-patch) - CVE-2026-49823 exploit attempt apiVersion: fission.io/v1 kind: Function metadata: name: malicious-function namespace: ns-attacker spec: environment: name: nodejs namespace: default package: packageref: name: victim-package namespace: ns-victim Unvalidated - allows reading victim's package
Verify the fix in v1.24.0 - the following Function should be rejected kubectl apply -f malicious-function.yaml Expected error: admission webhook "function.fission.io" denied the request: spec.package.packageref.namespace must equal metadata.namespace
Exploit
An attacker with `functions.fission.io/create` permission in their own namespace can exploit this vulnerability by crafting a `Function` that references a `Package` from a victim’s namespace. When the function is invoked, the `fission-fetcher` sidecar—operating with the `fission-fetcher` service account that has `get packages` permissions across all namespaces—fetches the victim’s package and writes its contents to `/userfunc/deployarchive` inside the attacker’s pool pod. This exposes the victim’s source code and any embedded credentials, such as API keys, database passwords, or other secrets stored within the deployment archive.
The exploit requires no user interaction and has a low attack complexity, with a CVSS v3.1 base score of 7.7 (High). The attack vector is network-based, requires low privileges, and changes the scope, resulting in high confidentiality impact. This vulnerability is particularly dangerous in multi-tenant Kubernetes environments where namespace isolation is critical for security separation. An attacker could potentially escalate privileges, leak sensitive data, and circumvent security controls that rely on namespace boundaries.
The CISA ADP analysis indicates that exploitation is currently none, the vulnerability is not automatable, and the technical impact is partial. However, the operational impact extends beyond simple namespace bypass, potentially enabling attackers to gain access to sensitive configurations, secrets, or application code that should remain isolated.
Protection
Immediate Action: Upgrade Fission to version 1.24.0 or later. This release implements consistent namespace validation across all reference types, including PackageRef.Namespace. The fix is available in the official Fission repository and can be applied via the standard upgrade process.
Defense-in-Depth Measures:
- Review and audit existing `Function` specifications for any cross-namespace package references.
- Implement additional monitoring to detect unauthorized namespace references in `Function` creations.
- Apply network policies and pod security policies to provide additional layers of defense.
- Regularly scan deployed functions for security issues.
- Reduce or remove `functions.fission.io/create` RBAC permissions from untrusted tenants where possible.
Verification: After upgrading, any `Function` that explicitly sets `spec.package.packageref.namespace` to a different namespace will be rejected at admission. Empty values are accepted and defaulted to the function’s own namespace.
Impact
- Confidentiality Breach: An attacker can read the deployment archive—including source code and embedded secrets—of any `Package` in any other namespace.
- Multi-Tenant Isolation Failure: The vulnerability breaks namespace isolation, a fundamental security boundary in Kubernetes.
- Privilege Escalation: Attackers can escalate privileges within the cluster by accessing sensitive configurations and credentials.
- Data Leakage: Sensitive data such as API keys, database passwords, and application code can be exfiltrated.
- Compliance Violations: The vulnerability violates the principle of least privilege and namespace-based access controls, impacting compliance requirements in security-sensitive environments.
- Supply Chain Risk: An attacker could inject malicious code or backdoors into functions by manipulating package references, potentially compromising the entire serverless deployment.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
