GHSA-7PJR-QPVH-M339

Vulnerability from github – Published: 2026-05-21 20:17 – Updated: 2026-06-10 18:42
VLAI
Summary
Fission builder accepts arbitrary buildcmd strings from Environment.spec.builder.command, allowing the builder pod to invoke arbitrary executables
Details

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:

  • PR #3364 (commit 0f45c911) introduces Builder.resolveBuildCommand in pkg/builder/builder.go, which:
  • Accepts an empty string (treated as the default /build).
  • Accepts the literal /build.
  • Accepts any absolute path that survives filepath.Clean and contains no .. segments.
  • 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.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.22.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fission/fission"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46618"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250",
      "CWE-269",
      "CWE-78"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T20:17:24Z",
    "nvd_published_at": "2026-06-10T18:17:05Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nBefore 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 \u0027...\u0027`) and execute arbitrary code in the builder pod context.\n\n### Affected component\n\n- `pkg/builder/builder.go:254` \u2014 call site (`exec.Command(buildCmd, buildArgs...)`).\n- `pkg/builder/builder.go:106` \u2014 input source: `buildCmd, buildArgs = strings.Fields(req.BuildCommand)[0], strings.Fields(req.BuildCommand)[1:]`.\n\n### Impact\n\nA subject with `create` / `update` privilege on `Environment` objects could:\n\n1. Cause the builder pod for any package using that environment to execute arbitrary code.\n2. Read whatever files the builder pod has access to inside its `/packages` shared volume (deployment archive payloads for that package).\n3. Write arbitrary content into the `/packages` shared volume, which the fetcher subsequently uploads as the package deployment archive.\n\nThe builder pod runs in the user\u0027s namespace with the `fission-builder` SA (not the more-privileged executor SA), so the impact is bounded to that namespace\u0027s package contents and the builder pod\u0027s own filesystem. `PR:H` reflects that creating / modifying `Environment` CRDs is typically restricted to cluster admins or platform operators.\n\n### Root cause\n\n`pkg/builder/builder.go`\u0027s 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.\n\n### Fix\n\nReleased in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0):\n\n- **PR #3364** (commit `0f45c911`) introduces `Builder.resolveBuildCommand` in `pkg/builder/builder.go`, which:\n  1. Accepts an empty string (treated as the default `/build`).\n  2. Accepts the literal `/build`.\n  3. Accepts any absolute path that survives `filepath.Clean` and contains no `..` segments.\n  4. Rejects anything containing whitespace metacharacters or relative paths.\n- `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.\n\n### Mitigation (until upgrade)\n\n1. Restrict who can create / update `Environment` CRDs to trusted operators only.\n2. Audit `Environment.spec.builder.command` values for any non-`/build` paths.\n3. Run the buildermgr with a tightened ServiceAccount that has no secret access in the builder namespace.",
  "id": "GHSA-7pjr-qpvh-m339",
  "modified": "2026-06-10T18:42:10Z",
  "published": "2026-05-21T20:17:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/security/advisories/GHSA-7pjr-qpvh-m339"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46618"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/pull/3364"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fission/fission"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/releases/tag/v1.23.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Fission builder accepts arbitrary buildcmd strings from Environment.spec.builder.command, allowing the builder pod to invoke arbitrary executables"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…