Listen to this Post
How CVE-2026-49822 Works
Fission is an open-source, Kubernetes-native serverless framework. Prior to version 1.24.0, a critical vulnerability (CVE-2026-49822) existed in its `KubernetesWatchTrigger` (KWT) component. This flaw allowed a low-privilege developer, who only had permission to create a KWT within their own namespace, to establish a persistent surveillance channel over any other namespace in the cluster.
The vulnerability stemmed from a combination of two independent flaws in the code:
1. Improper Namespace Validation: In pkg/kubewatcher/kubewatcher.go, the `createKubernetesWatch` function used the user-controlled `w.Spec.Namespace` field directly as the target for the Kubernetes watch operation. It failed to validate this against w.Namespace, which is the KWT’s own namespace. This meant an attacker could specify any namespace they wished to monitor. The `kubewatcher` component, using its cluster-scoped service account, would then establish a watch and serialize every Pod, Service, and Job change event as full JSON, posting it via HTTP to the attacker’s specified function.
2. Bypassed Validation: The validating webhook in `pkg/webhook/kuberneteswatchtrigger.go` was only registered for verbs=create. This meant that `update` and `patch` requests for a KWT would bypass validation entirely. An attacker could first create a KWT and then update it to target a different, more sensitive namespace, effectively circumventing any initial checks.
A separate, but related, information leak was also present. If an attacker set `spec.namespace` to an empty value, the controller’s default behavior would resolve this to all namespaces, allowing them to surveil the entire cluster.
The impact was severe. An attacker could create a KWT in their own namespace and use it to continuously receive full event payloads for resources like Pods, Services, and Jobs from any other namespace. This created a persistent cross-tenant surveillance channel that required no additional privileges, effectively bypassing the fundamental security boundaries that Kubernetes namespaces are designed to enforce. The persistent nature of these watches made detection and remediation difficult.
The issue was patched in Fission version 1.24.0.
DailyCVE Form
Platform: Fission
Version: < 1.24.0
Vulnerability: CWE-284, CWE-862
Severity: HIGH (CVSS 7.7)
Date: 2026-06-10
Prediction: 2026-06-10 (Patched)
What Undercode Say
Analytics
To check for vulnerable `KubernetesWatchTrigger` resources in a cluster, you can use `kubectl` to list them and inspect their `spec.namespace` field. The following command will list all KWTs across all namespaces and show their target namespace:
kubectl get kuberneteswatchtriggers.fission.io -A -o json | jq '.items[] | {namespace: .metadata.namespace, specNamespace: .spec.namespace, name: .metadata.name}'
A KWT is potentially malicious if `specNamespace` is different from `namespace` (the trigger’s own namespace). A `specNamespace` that is empty (null) is also a strong indicator of a vulnerable configuration, as it would have watched all namespaces. After upgrading to v1.24.0, such configurations will be automatically corrected to watch only the trigger’s own namespace.
To audit for active surveillance, you can also check the logs of the `kubewatcher` service for unexpected watch creations. The following command can be used to filter for KWT-related events:
kubectl logs -n fission deployment/fission-bundle -c kubewatcher | grep -i "kuberneteswatchtrigger"
Exploit
An attacker with permission to create a `KubernetesWatchTrigger` in their own namespace (e.g., tenant-a) could exploit this vulnerability by creating a KWT that targets a different namespace, such as kube-system.
A malicious manifest might look like this:
apiVersion: fission.io/v1 kind: KubernetesWatchTrigger metadata: name: malicious-surveillance namespace: tenant-a spec: namespace: kube-system <-- Target namespace type: pod <-- Resource to watch functionref: name: attacker-function namespace: tenant-a
Because the webhook only validated `create` operations, an attacker could also first create a benign KWT and then use `kubectl patch` to change its `spec.namespace` to a sensitive target, bypassing validation entirely.
kubectl patch kuberneteswatchtrigger malicious-surveillance -n tenant-a --type merge -p '{"spec":{"namespace":"kube-system"}}'
Once created, the `kubewatcher` component, using its powerful cluster-scoped service account, would establish a watch on the target namespace. Every event (e.g., a new Pod being created in kube-system) would be serialized to JSON and POSTed to the attacker’s function, providing a continuous stream of sensitive cluster data.
Protection
The primary protection against this vulnerability is to upgrade Fission to version v1.24.0 or later. The fix, implemented in pull request 3379, introduces multiple layers of defense:
– Extended Webhook Validation: The validating webhook is now registered for verbs=create;update. This ensures that both creation and modification of KWTs are subject to validation.
– Strict Namespace Enforcement: The `Validate` function now explicitly rejects any `KubernetesWatchTrigger.spec.namespace` that does not equal the trigger’s own metadata.namespace.
– Controller Guard: A new guard in the `createKubernetesWatch` controller function acts as a final line of defense. It rejects any cross-namespace targets that might have bypassed admission control. Furthermore, it coerces an empty `spec.namespace` to the trigger’s own namespace, preventing the previous all-namespaces behavior.
As a behavioral change, any `KubernetesWatchTrigger` with an unset `spec.namespace` will now only watch its own namespace. If you previously relied on this to watch all namespaces, you must now create a separate KWT for each namespace you wish to monitor.
Impact
CVE-2026-49822 had a High severity impact (CVSS 7.7) . A successful exploit allowed a low-privileged user to establish a persistent, cross-tenant surveillance channel. This capability directly undermines the security boundaries of Kubernetes namespaces.
An attacker could monitor sensitive workloads, configuration changes, and operational events across the entire cluster. This information could be used to:
– Gather intelligence about the cluster’s structure and operational patterns.
– Detect when privileged operations are being performed.
– Identify new vulnerabilities or misconfigurations for subsequent attacks.
This vulnerability not only posed a significant security risk but also created compliance issues, as it enabled unauthorized monitoring that could violate data protection regulations and security frameworks. The fact that it required minimal privileges to exploit made it a particularly dangerous and accessible attack vector.
🎯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
