GHSA-QF34-295C-26V8

Vulnerability from github – Published: 2026-07-14 20:29 – Updated: 2026-07-14 20:29
VLAI
Summary
Woodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend
Details

Impact

A privilege escalation vulnerability affects Woodpecker instances using the Kubernetes backend.

The pipeline option backend_options.kubernetes.serviceAccountName was passed directly to the pod spec without any admin gating.

Who is impacted: any operator running the Kubernetes backend. Any user with Push permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account's RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover.

Patches

https://github.com/woodpecker-ci/woodpecker/pull/6792

Workarounds

Operators who cannot upgrade immediately can mitigate by any of:

  • Restrict Push access on repositories connected to the Kubernetes-backed instance to trusted users only.
  • Harden the pipeline namespace: ensure no privileged ServiceAccount exists or is bound in the namespace where pipeline pods run; keep the default ServiceAccount minimally privileged.
  • Disable ServiceAccount token automounting for ServiceAccounts that should not be used by pipelines.
  • Enforce an admission policy (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy) that rejects pipeline pods setting an unexpected serviceAccountName.
  • Use a dedicated, isolated namespace per org/instance with no sensitive RBAC bindings.

Resources

  • Vulnerable option introduced in commit 609ba481b5e912f59aaae8ca7bc22b44523c5e37
  • Affected versions: v1.0.0 through v3.15.0
  • Source: pipeline/backend/kubernetes/backend_options.go (field ServiceAccountName), pipeline/backend/kubernetes/pod.go (assigned to pod spec with no gating)
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.woodpecker-ci.org/woodpecker/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/woodpecker-ci/woodpecker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "last_affected": "1.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.woodpecker-ci.org/woodpecker/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61549"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T20:29:32Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA privilege escalation vulnerability affects Woodpecker instances using the **Kubernetes backend**.\n\nThe pipeline option `backend_options.kubernetes.serviceAccountName` was passed directly to the pod spec without any admin gating.\n\n**Who is impacted:** any operator running the Kubernetes backend. Any user with **Push** permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account\u0027s RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover.\n\n### Patches\n\nhttps://github.com/woodpecker-ci/woodpecker/pull/6792\n\n### Workarounds\n\nOperators who cannot upgrade immediately can mitigate by any of:\n\n- **Restrict Push access** on repositories connected to the Kubernetes-backed instance to\n  trusted users only.\n- **Harden the pipeline namespace**: ensure no privileged ServiceAccount exists or is bound in\n  the namespace where pipeline pods run; keep the `default` ServiceAccount minimally privileged.\n- **Disable ServiceAccount token automounting** for ServiceAccounts that should not be used by\n  pipelines.\n- **Enforce an admission policy** (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy)\n  that rejects pipeline pods setting an unexpected `serviceAccountName`.\n- **Use a dedicated, isolated namespace** per org/instance with no sensitive RBAC bindings.\n\n### Resources\n\n- Vulnerable option introduced in commit `609ba481b5e912f59aaae8ca7bc22b44523c5e37`\n- Affected versions: `v1.0.0` through `v3.15.0`\n- Source: `pipeline/backend/kubernetes/backend_options.go` (field `ServiceAccountName`),\n  `pipeline/backend/kubernetes/pod.go` (assigned to pod spec with no gating)",
  "id": "GHSA-qf34-295c-26v8",
  "modified": "2026-07-14T20:29:32Z",
  "published": "2026-07-14T20:29:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/woodpecker-ci/woodpecker/security/advisories/GHSA-qf34-295c-26v8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/woodpecker-ci/woodpecker/pull/6792"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/woodpecker-ci/woodpecker"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Woodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend"
}



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…

Detection rules are retrieved from Rulezet.

Loading…

Loading…