GHSA-m63v-2g9w-2w6v is a critical-severity (CVSS 9.9) CWE-250 vulnerability in github.com/fission/fission. A fix is available for github.com/fission/fission — see the affected versions and patch details below.
Fission: Environment Runtime.Container and Builder.Container SecurityContext bypass allows privileged pod creation
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-m63v-2g9w-2w6v.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-m63v-2g9w-2w6v by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/fission/fissionReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A follow-up bypass of the round-4 PodSpec hardening (GHSA-gx55-f84r-v3r7, GHSA-wmgg-3p4h-48x7, GHSA-v455-mv2v-5g92). Those advisories validate and sanitize the PodSpec (spec.runtime.podSpec / spec.builder.podSpec /
function.spec.podSpec), but the Environment CRD also exposes spec.runtime.container and spec.builder.container — a standalone Container merged into the runtime/builder pod whose SecurityContext bypassed both layers.
Details
Admission-layer gap. Environment.Validate() calls ValidatePodSpecSafety() on Runtime.PodSpec and Builder.PodSpec only. That function takes a *PodSpec, so it never inspects the standalone Runtime.Container.SecurityContext
or Builder.Container.SecurityContext.
Merge-layer gap. sanitizeContainerSecurityContext() ran only inside MergePodSpec(). The container field is merged via MergeContainer(), which did not sanitize. With only Runtime.Container set and Runtime.PodSpec nil,
MergePodSpec is never invoked, so the sanitizer never ran.
Affected merge sites: poolmgr (gp_deployment.go), newdeploy (newdeploy.go), and buildermgr (envwatcher.go).
Proof of concept
apiVersion: fission.io/v1
kind: Environment
metadata:
name: priv-escape-test
namespace: default
spec:
version: 3
runtime:
image: "ghcr.io/fission/python-env:latest"
container:
name: priv-escape-test
securityContext:
privileged: true
poolsize: 1
The admission webhook accepts this Environment and the resulting pool pod runs with privileged: true. Equivalent bypasses: allowPrivilegeEscalation: true, capabilities.add: ["SYS_ADMIN"], capabilities.add: ["NET_ADMIN","SYS_PTRACE"]. The same attack applies to Builder.Container.
Impact
A tenant with environments.fission.io create/update RBAC can run privileged / allowPrivilegeEscalation / dangerous-capability containers in the Fission function or builder namespace, scheduled under the executor's high-privilege
service account — enabling container-sandbox escape, host filesystem and network access, and potential node- and cluster-level compromise. Identical blast radius to GHSA-gx55-f84r-v3r7.
Fix
Fixed in #3406 and released in v1.24.0.
- Admission layer (primary defence): a new
ValidateContainerSafetyinpkg/apis/core/v1/podspec_safety.goapplies the per-container SecurityContext denylist (privileged,allowPrivilegeEscalation, dangerous capabilities) to a standalone container, and is called fromEnvironment.Validate()forRuntime.ContainerandBuilder.Container. - Merge layer (defence in depth):
sanitizeContainerSecurityContext()is now invoked insideMergeContainer()itself, covering all three executor/builder call sites.
Workarounds
- Restrict Environment create/update RBAC to trusted administrators.
- Deploy a Kyverno / OPA Gatekeeper policy rejecting dangerous Container SecurityContext on Environment CRDs.
- Label the function/builder namespaces with
pod-security.kubernetes.io/enforce: restricted.
References
- GHSA-gx55-f84r-v3r7, GHSA-wmgg-3p4h-48x7, GHSA-v455-mv2v-5g92 — the round-4 PodSpec fixes this advisory bypasses (#3391,
e484df84).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/fission/fission | all versions | 1.24.0go get github.com/fission/fission@v1.24.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/fission/fission, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/fission/fission to 1.24.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m63v-2g9w-2w6v is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Frequently Asked Questions
Is GHSA-m63v-2g9w-2w6v in your dependencies?
Find it across Go, including transitive dependencies.