What changed
On October 7, 2026, the Woodpecker CI project released 3.19.0 with two security-relevant changes. Server-side agent filters are now stored in the Woodpecker server database and evaluated whenever an agent requests a workflow, rather than relying solely on labels reported by the agent itself. The release also fixes an unintended path where matrix environment variables were injected into the default clone step because an environment-populated clone container was no longer identified as a plugin. The upstream release credits a security report and links to merged fix PR #7157; it does not establish a public CVE or observed exploitation.
Why it matters
A self-hosted CI server may run jobs across machines with different access to credentials, private repositories, internal networks or deployment environments. Self-reported worker labels are useful for routing but not for restricting which jobs a potentially untrusted worker can accept. The new server-side filters make that restriction a server decision. Separately, clone steps handle repository access and should not receive unrelated matrix configuration implicitly. For small teams operating mixed trusted and ephemeral runners, these are practical boundary changes, not cosmetic release features.
Worker labels no longer have to double as authorization
Woodpecker's own documentation states that WOODPECKER_AGENT_LABELS values come from the agent and can be claimed arbitrarily. New agent filters are held on the server and applied to each workflow request. They accept key=value, key=* and mandatory !key=value syntax. If a server filter and agent label share a key, the server filter wins. Organization and personal agents additionally receive a mandatory org-id filter, preventing them from picking up another organization's workflows.
Administrators configure filters, not the runner
Filters are edited in the server UI under instance, organization or user agent settings. A change takes effect the next time that worker requests a workflow. Administrators should assign restrictions based on real trust zones, verify which labels jobs request and test that an agent with spoofed local labels still cannot accept prohibited work. The new mechanism restricts scheduling; it does not by itself sandbox code running on a permitted worker.
The default clone step had an environment-isolation regression
The merged fix PR #7157 explains that a clone container's Environment field was no longer empty, so the IsPlugin() check returned false and matrix variables were injected. The 3.19 release stops this injection into the default clone step. This is relevant where pipeline matrix values contain sensitive or unexpected configuration, although the published material does not demonstrate credential theft or exploitation in the wild.
An upgrade with a concrete checklist
Upgrade Woodpecker server and agents in a tested maintenance window, review server-side filters for restricted workers, audit pipelines that previously depended on implicit matrix variables in clone behaviour, and verify intended repository access and pipeline placement. The 3.18 release had already changed how variables flow into plugins; do not assume every plugin or clone environment retains older implicit values. Keep separate secrets handling and worker isolation controls in place.