GHSA-vjhc-cf4p-72q4 — fission

Summary

Fission's buildermgr controller processed Package CRDs without verifying that Package.spec.environment.namespace matched Package.metadata.namespace.

Details

An attacker with packages.fission.io/create in their own namespace could set spec.environment.namespace to any other tenant's namespace. The controller then used its high-privilege service account to fetch the Environment cross-namespace and dispatch the build command into the victim namespace's builder pod.

The build command's stdout is written verbatim into Package.status.buildlog. By running malicious code through an npm preinstall lifecycle hook (or any equivalent build step), the attacker could read the victim namespace's fission-builder Bearer token from inside that builder pod and surface it through the build log — then use the leaked token to read every Secret and ConfigMap in the victim namespace.

Impact

Cross-tenant compromise: a package author in one namespace could execute code inside another tenant's builder pod and exfiltrate that namespace's fission-builder service-account token, giving namespace-wide secret and configmap read in the victim namespace.

Fix

Fixed in #3379 and released in v1.24.0. Two checks in series:

• Admission webhook (pkg/webhook/package.go::Validate) rejects Package.spec.environment.namespace != Package.metadata.namespace. An empty namespace is still accepted; the controllers default it to the package's own namespace.
• Controller belt-and-braces: the same check is repeated in pkg/buildermgr/pkgwatcher.go::build and pkg/buildermgr/common.go::buildPackage before the cross-namespace Environments(...).Get call, so a stale Package CR or a webhook-bypass cluster (failurePolicy=Ignore) cannot exploit the primitive either.

Behavioural change

Packages that explicitly set spec.environment.namespace to a different namespace are now rejected at admission. Empty-string remains accepted (resolves to the package's own namespace, the same as the prior implicit behaviour).