GHSA-qf5v-m7p4-95rp is a high-severity (CVSS 8.5) Improper Privilege Management vulnerability in github.com/fission/fission. A fix is available for github.com/fission/fission — see the affected versions and patch details below.
Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption
Exploitation Status
No confirmed exploitation observed yet
- 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-qf5v-m7p4-95rp.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-qf5v-m7p4-95rp plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 379,145 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
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
Fission v1.24.0 added PodSpec safety validation for tenant-facing Environment and Function CRDs (ValidatePodSpecSafety / ValidateContainerSafety admission webhook + sanitizeContainerSecurityContext executor merge layer), but the
capability check was implemented as a fixed denylist of six Linux capabilities (SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE, DAC_READ_SEARCH, DAC_OVERRIDE). The denylist omitted CAP_SYS_TIME, among others. As a result, a tenant
who could create a Function or Environment CRD could request securityContext.capabilities.add: ["SYS_TIME"], pass Fission's admission validation and merge-layer sanitization, and run attacker-controlled code with CAP_SYS_TIME in the
resulting function or runtime container.
Demonstrated consequence: cross-tenant node integrity damage via CAP_SYS_TIME. The Linux real-time clock is not namespaced — time namespaces virtualize only MONOTONIC and BOOTTIME, never REALTIME — so a tenant container holding
CAP_SYS_TIME could call clock_settime(CLOCK_REALTIME) and rewrite the shared node wall clock. That corrupts TLS / certificate validity windows, Kubernetes lease renewal, token expiry, scheduling, and time-series for every workload on
the node.
The denylist also omitted SYS_RAWIO, BPF, SYS_RESOURCE, and MAC_ADMIN. Those are documented as evidence that the denylist is structurally incomplete (their practical impact is kernel-, LSM-, or device-cgroup-dependent and is not
exercised in this report).
The deeper structural problem: a denylist on capabilities.add cannot constrain capabilities the OCI runtime grants by default — DAC_OVERRIDE is in the OCI default cap set and reaches the container regardless of any add check,
partially mooting the denylist for its own entries. A capability allowlist (with drop:["ALL"] to remove the default set) is the only model that addresses both problems.
Affected
- Project:
github.com/fission/fission - Versions:
<= 1.24.0 - Audited commits: v1.24.0 tag (
ce617120) and current HEAD at audit time - Component:
pkg/apis/core/v1/podspec_safety.go(dangerousCapabilities) andpkg/executor/util/merge.go(dangerousMergeContainerCapabilities) - Pre-condition: cluster does not enforce a restrictive Pod Security Admission (PSA) profile on the function-pod namespace. With PSA
restrictedin force the API server's PodSecurity admission rejects the pod at creation and this finding does not apply. Fission added its own PodSpec validation precisely because it cannot assume PSA enforcement.
Fix section (paste into the Fix / Patches field)
Fixed in v1.25.0 by:
- PR #3465 (commit
2569b42b) — replace the denylist with a PSA-restricted allowlist (NET_BIND_SERVICEonly) at both enforcement layers:pkg/apis/core/v1/podspec_safety.go—ValidateContainerSafetynow rejects anycapabilities.addentry not inallowedCapabilities. The container check is invoked fromValidatePodSpecSafetyfor every PodSpec container / init-container and fromEnvironment.validateForAdmissionfor the bareRuntime.Container/Builder.Container.pkg/executor/util/merge.go—sanitizeContainerSecurityContextfilterscapabilities.addthrough the same allowlist at every merge site (poolmgr / newdeploy / container executor / builder).
- The same PR adds 21 bounded CEL
XValidationrules covering the cheap pod-level invariants (hostNetwork/hostPID/hostIPC/serviceAccountName/serviceAccountoverride) onFunctionSpec,Runtime, andBuilder, plus the bare-ContainerSecurityContextchecks (privileged != true,allowPrivilegeEscalation != true,capabilities.add ⊆ {NET_BIND_SERVICE}) onRuntimeandBuilder. The API server now short-circuits those attack vectors per CRD apply before the webhook is invoked. Per-container PodSpec iteration stays in the webhook because it exceeds the API server's CEL cost budget. - The same PR also adds two forward-compat regression guards in
pkg/apis/core/v1/podspec_safety_test.go:TestAllTenantContainerSurfacesAreValidatedwalks every CRD root type via reflection and fails if any reachable*apiv1.PodSpecor*apiv1.Containerfield is missing from the hand-maintained known-covered set.TestTenantContainerSurfaces_RejectSysAdminend-to-end exercises each covered surface and assertsValidateForAdmissionrejects aSYS_ADMINinjection at that exact path.
Not addressed in v1.25.0
The advisory's structural recommendation to force capabilities.drop: ["ALL"] at the merge layer is not part of this fix. Fission's own sidecar containers (fission-fetcher, builder) were authored against the OCI default capability
set and need a per-container cap audit before drop:["ALL"] can be applied uniformly. The allowlist on capabilities.add closes the demonstrated CAP_SYS_TIME impact; the OCI-default-cap concern (which the advisory itself marks as
conditional / not demonstrated) is tracked separately.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/fission/fission | all versions | 1.25.0go get github.com/fission/fission@v1.25.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.25.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qf5v-m7p4-95rp is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-qf5v-m7p4-95rp can be triaged on real exposure rather than presence alone.
Tailored to GHSA-qf5v-m7p4-95rp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-qf5v-m7p4-95rp in your dependencies?
O3 Security finds GHSA-qf5v-m7p4-95rp across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.