high · 8.5CVE-2026-49824Jun 30, 2026

CVE-2026-49824: Fission Cross-Namespace Environment Reference via Unvalidated EnvironmentRef

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A Fission tenant with permission to create Functions in their own namespace could point a Function at another tenant's Environment CRD, causing their code to run inside the victim's container image an

Packagegithub.com/fission/fission
Ecosystemgo
Affected<= 1.23.0
Fixed in1.24.0

The problem

The Fission Function admission webhook in pkg/webhook/function.go checked that spec.secrets[].namespace and spec.configmaps[].namespace matched the function's own namespace, but it never applied the same check to spec.environment.namespace.

Any authenticated user holding functions.fission.io/create in namespace A could set spec.environment.namespace to namespace B. The poolmgr and newdeploy executors would then look up and schedule pods using namespace B's Environment CRD, running the attacker's code inside the victim's container image.

This breaks Fission's namespace trust boundary and enables both credential theft (hardcoded secrets in runtime images) and confused-deputy attacks against privileged sidecars.

Proof of concept

A working proof-of-concept for CVE-2026-49824 in github.com/fission/fission, with the exact payload below.

text
apiVersion: fission.io/v1
kind: Function
metadata:
  name: steal-env
  namespace: attacker-ns          # namespace attacker controls
spec:
  environment:
    name: victim-python-env
    namespace: victim-ns           # cross-namespace ref — unvalidated pre-1.24.0
  package:
    functionName: handler
  resources: {}

The root cause is an incomplete authorization check (CWE-284 / CWE-863): the webhook's Validate() function in pkg/webhook/function.go iterated secrets and configmaps refs but had no equivalent loop for the EnvironmentReference field, so any non-empty namespace value passed through unchecked.

The patch in PR #3389 (commit 80e7ba5) adds an explicit rejection: if spec.environment.namespace is non-empty and differs from metadata.namespace, admission is denied. Empty string is still accepted because the CLI defaults it to the function's own namespace at creation time.

As a belt-and-braces measure, the same namespace equality check was added directly inside poolmgr getFunctionEnv and newdeploy fnCreate and RefreshFuncPods, covering clusters where the webhook runs with failurePolicy: Ignore or where stale Function objects survived an upgrade-before-restart window.

The fix

Upgrade to Fission v1.24.0 or later. The fix is in PR #3389 (commit 80e7ba55228e1ef426f51353e25d2682ec61de34). After upgrading, any Function whose spec.environment.namespace differs from its own metadata.namespace is rejected at admission. Functions that relied on cross-namespace environment references must be rewritten to reference an environment in the same namespace.

If your webhook runs with failurePolicy: Ignore, the controller-side guards added in the same patch still block exploitation at schedule time.

Reported by Sanket Sudake (@sanketsudake).

References: [1][2][3][4][5][6]

Related research