Skip to content
Fencer Intel
high 8.1

GHSA-7m8x-qg2j-4m3v json

Fission: MessageQueueTrigger scaler manager materializes Secret values into Deployment envvars and accepts arbitrary user PodSpec

published 4mo ago modified 4mo ago also GO-2026-5849

cvss
8.1
version 3.1, GitHub
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

### Summary

The Fission MessageQueueTrigger (MQT) scaler controller exposed two privilege-escalation primitives to any subject able to create MQTs in a namespace.

### Details

**1. Secret materialization.** `getEnvVarlist` in `pkg/mqtrigger/scalermanager.go` read the Secret named in `Spec.Secret` using the controller's cluster-wide `secrets/get` RBAC and emitted each key as a literal `EnvVar.Value`, copying the plaintext secret content into the connector Deployment's pod template. A subject holding `messagequeuetriggers/create` but **not** `secrets/get` could exfiltrate any Secret in the namespace by pointing an MQT at it.

**2. PodSpec injection.** `Spec.PodSpec` was merged into the controller-built connector PodSpec via `util.MergePodSpec` with no allowlist on which fields could come from the user. An MQT could substitute `Containers[].Image` (run any image), override `Command`/`Args`, inject `Env`, add `VolumeMounts` + `Volumes`, override `ServiceAccountName`, and set `HostNetwork`/`HostPID`/`HostIPC` — turning `messagequeuetriggers/create` into effective `deployments/create` with an arbitrary image and service account.

### Impact

A tenant with only `messagequeuetriggers.fission.io/create` in a namespace could read any Secret in that namespace and run an arbitrary container image under an arbitrary service account, escalating well beyond their intended RBAC.

### Fix

Fixed in [#3367](https://github.com/fission/fission/pull/3367) and released in [v1.24.0](https://github.com/fission/fission/releases/tag/v1.24.0).

- `getEnvVarlist` now emits `EnvVar.ValueFrom.SecretKeyRef` so the connector pod resolves values at start time under its own service account. The secret values are never written into the Deployment object and never logged. - A new allowlist, `MergeAllowedPodSpecFields` (`pkg/executor/util/merge_allowlist.go`), accepts only `NodeSelector`, `Tolerations`, `Affinity`, `RuntimeClassName`, and per-container `Resources`. All other user-supplied fields are dropped at the controller layer, and the validating webhook rejects every populated non-allowlisted field with a clear error. The webhook and the merge helper share a single canonical `DisallowedPodSpecFields` enumeration so they cannot drift.

### Behavioural change

MQT authors that previously overrode the connector image, command, args, env, volumes, service account, or host namespaces via `Spec.PodSpec` will see those fields rejected at admission (or silently dropped if the webhook is disabled). Allowlisted fields flow through unchanged.

Patch / fix

  • go github.com/fission/fission 1.24.0

Is GHSA-7m8x-qg2j-4m3v in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CVSS scores

assigned by version score vector
GitHub 3.1 8.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Affected packages

ecosystem package affected fixed in
go github.com/fission/fission
<1.24.0
1.24.0

Classification

Weakness
  • CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
  • CWE-269 Improper Privilege Management
  • CWE-284 Improper Access Control

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.