### Summary Before the round-1 security sweep, `pkg/builder/builder.go` passed `Environment.spec.builder.command` directly into `exec.Command(...)` after a `strings.Fields` split, with no validation of the executable path or its arguments. A user who could create or update `Environment` CRDs in a namespace observed by the buildermgr could thereby point the builder pod at any executable inside the builder image (e.g. `/bin/sh -c '...'`) and execute arbitrary code in the builder pod context. ### Affected component - `pkg/builder/builder.go:254` — call site (`exec.Command(buildCmd, buildArgs...)`). - `pkg/builder/builder.go:106` — input source: `buildCmd, buildArgs = strings.Fields(req.BuildCommand)[0], strings.Fields(req.BuildCommand)[1:]`. ### Impact A subject with `create` / `update` privilege on `Environment` objects could: 1. Cause the builder pod for any package using that environment to execute arbitrary code. 2. Read whatever files the builder pod has access to inside its `/packages` shared volume (deployment archive payloads for that package). 3. Write arbitrary content into the `/packages` shared volume, which the fetcher subsequently uploads as the package deployment archive. The builder pod runs in the user's namespace with the `fission-builder` SA (not the more-privileged executor SA), so the impact is bounded to that namespace's package contents and the builder pod's own filesystem. `PR:H` reflects that creating / modifying `Environment` CRDs is typically restricted to cluster admins or platform operators. ### Root cause `pkg/builder/builder.go`'s build-command parser did not validate the resulting executable path. Although `exec.Command` does not invoke a shell, it does locate the executable via `$PATH`, and `strings.Fields` splitting allowed multiple flags / sub-arguments to be passed. ### Fix Released in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0): - **PR #3364** (commit `0f45c911`) introduces `Builder.resolveBuildCommand` in `pkg/builder/builder.go`, which: 1. Accepts an empty string (treated as the default `/build`). 2. Accepts the literal `/build`. 3. Accepts any absolute path that survives `filepath.Clean` and contains no `..` segments. 4. Rejects anything containing whitespace metacharacters or relative paths. - `exec.Command` still receives only the validated absolute path; sub-arguments continue to come from `strings.Fields` of the original string but are now passed positionally with no shell expansion. ### Mitigation (until upgrade) 1. Restrict who can create / update `Environment` CRDs to trusted operators only. 2. Audit `Environment.spec.builder.command` values for any non-`/build` paths. 3. Run the buildermgr with a tightened ServiceAccount that has no secret access in the builder namespace.
### Summary Before the round-1 security sweep, `pkg/builder/builder.go` passed `Environment.spec.builder.command` directly into `exec.Command(...)` after a `strings.Fields` split, with no validation of the executable path or its arguments. A user who could create or update `Environment` CRDs in a namespace observed by the buildermgr could thereby point the builder pod at any executable inside the builder image (e.g. `/bin/sh -c '...'`) and execute arbitrary code in the builder pod context. ### Affected component - `pkg/builder/builder.go:254` — call site (`exec.Command(buildCmd, buildArgs...)`). - `pkg/builder/builder.go:106` — input source: `buildCmd, buildArgs = strings.Fields(req.BuildCommand)[0], strings.Fields(req.BuildCommand)[1:]`. ### Impact A subject with `create` / `update` privilege on `Environment` objects could: 1. Cause the builder pod for any package using that environment to execute arbitrary code. 2. Read whatever files the builder pod has access to inside its `/packages` shared volume (deployment archive payloads for that package). 3. Write arbitrary content into the `/packages` shared volume, which the fetcher subsequently uploads as the package deployment archive. The builder pod runs in the user's namespace with the `fission-builder` SA (not the more-privileged executor SA), so the impact is bounded to that namespace's package contents and the builder pod's own filesystem. `PR:H` reflects that creating / modifying `Environment` CRDs is typically restricted to cluster admins or platform operators. ### Root cause `pkg/builder/builder.go`'s build-command parser did not validate the resulting executable path. Although `exec.Command` does not invoke a shell, it does locate the executable via `$PATH`, and `strings.Fields` splitting allowed multiple flags / sub-arguments to be passed. ### Fix Released in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0): - **PR #3364** (commit `0f45c911`) introduces `Builder.resolveBuildCommand` in `pkg/builder/builder.go`, which: 1. Accepts an empty string (treated as the default `/build`). 2. Accepts the literal `/build`. 3. Accepts any absolute path that survives `filepath.Clean` and contains no `..` segments. 4. Rejects anything containing whitespace metacharacters or relative paths. - `exec.Command` still receives only the validated absolute path; sub-arguments continue to come from `strings.Fields` of the original string but are now passed positionally with no shell expansion. ### Mitigation (until upgrade) 1. Restrict who can create / update `Environment` CRDs to trusted operators only. 2. Audit `Environment.spec.builder.command` values for any non-`/build` paths. 3. Run the buildermgr with a tightened ServiceAccount that has no secret access in the builder namespace.
Update github.com/fission/fission to 1.23.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFission builder accepts arbitrary buildcmd strings from Environment.spec.builder.command, allowing the builder pod to invoke arbitrary executables affects github.com/fission/fission (go). Severity is medium. ### Summary Before the round-1 security sweep, `pkg/builder/builder.go` passed `Environment.spec.builder.command` directly into `exec.Command(...)` after a `strings.Fields` split, with no validation of the executable path or its arguments. A user who could create or update `Environment` CRDs in a namespace observed by the buildermgr could thereby point the builder pod at any executable inside the builder image (e.g. `/bin/sh -c '...'`) and execute arbitrary code in the builder pod context. ### Affected component - `pkg/builder/builder.go:254` — call site (`exec.Command(buildCmd, buildArgs...)`). - `pkg/builder/builder.go:106` — input source: `buildCmd, buildArgs = strings.Fields(req.BuildCommand)[0], strings.Fields(req.BuildCommand)[1:]`. ### Impact A subject with `create` / `update` privilege on `Environment` objects could: 1. Cause the builder pod for any package using that environment to execute arbitrary code. 2. Read whatever files the builder pod has access to inside its `/packages` shared volume (deployment archive payloads for that package). 3. Write arbitrary content into the `/packages` shared volume, which the fetcher subsequently uploads as the package deployment archive. The builder pod runs in the user's namespace with the `fission-builder` SA (not the more-privileged executor SA), so the impact is bounded to that namespace's package contents and the builder pod's own filesystem. `PR:H` reflects that creating / modifying `Environment` CRDs is typically restricted to cluster admins or platform operators. ### Root cause `pkg/builder/builder.go`'s build-command parser did not validate the resulting executable path. Although `exec.Command` does not invoke a shell, it does locate the executable via `$PATH`, and `strings.Fields` splitting allowed multiple flags / sub-arguments to be passed. ### Fix Released in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0): - **PR #3364** (commit `0f45c911`) introduces `Builder.resolveBuildCommand` in `pkg/builder/builder.go`, which: 1. Accepts an empty string (treated as the default `/build`). 2. Accepts the literal `/build`. 3. Accepts any absolute path that survives `filepath.Clean` and contains no `..` segments. 4. Rejects anything containing whitespace metacharacters or relative paths. - `exec.Command` still receives only the validated absolute path; sub-arguments continue to come from `strings.Fields` of the original string but are now passed positionally with no shell expansion. ### Mitigation (until upgrade) 1. Restrict who can create / update `Environment` CRDs to trusted operators only. 2. Audit `Environment.spec.builder.command` values for any non-`/build` paths. 3. Run the buildermgr with a tightened ServiceAccount that has no secret access in the builder namespace.
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fission/fissiongo | <=1.22.0 | 1.23.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/fission/fission to 1.23.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFission builder accepts arbitrary buildcmd strings from Environment.spec.builder.command, allowing the builder pod to invoke arbitrary executables affects github.com/fission/fission (go). Severity is medium. ### Summary Before the round-1 security sweep, `pkg/builder/builder.go` passed `Environment.spec.builder.command` directly into `exec.Command(...)` after a `strings.Fields` split, with no validation of the executable path or its arguments. A user who could create or update `Environment` CRDs in a namespace observed by the buildermgr could thereby point the builder pod at any executable inside the builder image (e.g. `/bin/sh -c '...'`) and execute arbitrary code in the builder pod context. ### Affected component - `pkg/builder/builder.go:254` — call site (`exec.Command(buildCmd, buildArgs...)`). - `pkg/builder/builder.go:106` — input source: `buildCmd, buildArgs = strings.Fields(req.BuildCommand)[0], strings.Fields(req.BuildCommand)[1:]`. ### Impact A subject with `create` / `update` privilege on `Environment` objects could: 1. Cause the builder pod for any package using that environment to execute arbitrary code. 2. Read whatever files the builder pod has access to inside its `/packages` shared volume (deployment archive payloads for that package). 3. Write arbitrary content into the `/packages` shared volume, which the fetcher subsequently uploads as the package deployment archive. The builder pod runs in the user's namespace with the `fission-builder` SA (not the more-privileged executor SA), so the impact is bounded to that namespace's package contents and the builder pod's own filesystem. `PR:H` reflects that creating / modifying `Environment` CRDs is typically restricted to cluster admins or platform operators. ### Root cause `pkg/builder/builder.go`'s build-command parser did not validate the resulting executable path. Although `exec.Command` does not invoke a shell, it does locate the executable via `$PATH`, and `strings.Fields` splitting allowed multiple flags / sub-arguments to be passed. ### Fix Released in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0): - **PR #3364** (commit `0f45c911`) introduces `Builder.resolveBuildCommand` in `pkg/builder/builder.go`, which: 1. Accepts an empty string (treated as the default `/build`). 2. Accepts the literal `/build`. 3. Accepts any absolute path that survives `filepath.Clean` and contains no `..` segments. 4. Rejects anything containing whitespace metacharacters or relative paths. - `exec.Command` still receives only the validated absolute path; sub-arguments continue to come from `strings.Fields` of the original string but are now passed positionally with no shell expansion. ### Mitigation (until upgrade) 1. Restrict who can create / update `Environment` CRDs to trusted operators only. 2. Audit `Environment.spec.builder.command` values for any non-`/build` paths. 3. Run the buildermgr with a tightened ServiceAccount that has no secret access in the builder namespace.
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fission/fissiongo | <=1.22.0 | 1.23.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard