Cloudflare Pages Action CVE-2026-11325: RCE in GitHub Actions pipelines

CVE-2026-11325 in cloudflare/pages-action, a formerly popular GitHub Action for Cloudflare Pages deployments, was published on 12 August 2026. Under certain workflow configurations, attacker-controlled input can result in remote code execution inside the runner. That may expose CLOUDFLARE_API_TOKEN, GITHUB_TOKEN and other secrets made available to the job.

Every published version is affected, including the moving v1 tag. The repository has been archived and deprecated since 2024, and no patch will be released. Cloudflare directs users to cloudflare/wrangler-action; projects already migrated are not affected by this CVE. The old action is scheduled for removal on 18 September 2026, so staying creates both a security risk and an approaching pipeline failure.

Why a workflow is part of the supply chain

GitHub Actions is more than build automation. A runner retrieves code, installs dependencies, creates an artifact, signs or publishes it and authenticates to source control and hosting. Code executing there may alter deployment output, read tokens available to the job or use GITHUB_TOKEN for actions allowed by its permissions block.

The flaw therefore differs from one in a static website. Even if malicious code runs only for a job’s duration, it may publish a changed artifact or steal a long-lived Cloudflare token. When that token can administer several zones and projects, the blast radius extends beyond one branch.

CVE-2026-11325 scores 8.8 under CVSS 3.1. The vector includes user interaction because a malicious change has to enter a flow that runs the workflow. Actual reachability depends on triggers, pull-request policy and whether secrets are available while untrusted content is processed.

Which workflows need the closest review

Highest risk comes from jobs that run on content an outsider can change while receiving a deployment token. Review pull_request_target, comment-driven deployments, maintainer buttons that execute another person’s branch, automatic previews and repositories accepting contributions from forks.

Use of pull_request alone does not automatically expose a secret because GitHub restricts fork secrets. Risk can reappear through custom conditions, a self-hosted runner, checkout of untrusted commits in a privileged context or a downstream workflow consuming an artifact. Analysis needs the full event graph, not one uses line.

Search for cloudflare/pages-action across branches, reusable workflows, organisation templates and archived repositories that can still deploy. A moving tag does not help: all releases of the old action are in scope. There is no safe version to upgrade to within that project.

Migrating correctly

The replacement should use cloudflare/wrangler-action@v4 with an explicit Pages command such as pages deploy, naming the output directory and project. The action repository documents syntax, secrets and options. Migration is not only changing uses, because the inputs differ.

1. Inventory every cloudflare/pages-action reference, including shared workflows.
2. For each, record triggers, checked-out ref, GitHub environment, runner and exposed secrets.
3. Replace it with supported cloudflare/wrangler-action@v4 and the appropriate pages deploy command.
4. Declare minimum permissions, commonly starting with contents: read; add deployments: write only when needed.
5. Put production secrets in a protected GitHub Environment with required approval and branch restrictions.
6. Scope the Cloudflare token to one account and the Pages capabilities required by that pipeline.
7. Test previews against a non-production project, then deploy production from an approved commit and verify the public digest.

For a critical pipeline, consider pinning the action to a complete commit SHA and use an update bot with change review. The v4 tag is convenient and appears in vendor examples, but a moving tag trusts the maintainer’s release process. The organisation should choose a pinning policy deliberately and maintain a route for updating SHAs.

Minimum tokens and rotation

A Pages token should not have global administrative rights over DNS, Workers, accounts and billing. Create a separate credential for the pipeline and restrict resources. Declare GitHub permissions explicitly because default GITHUB_TOKEN rights depend on organisation settings and may be wider than the YAML author expects.

If a vulnerable workflow processed untrusted code, or that possibility cannot be excluded, rotate the Cloudflare token after migrating and review audit records. Check Pages deployments, project changes, use from new addresses, repository actions and workflow edits. Deleting a GitHub secret does not revoke it at the provider; revoke it in Cloudflare.

GITHUB_TOKEN is normally short-lived, but actions taken during a job remain. Review commits, releases, artifacts, deployment statuses and settings changes. Other long-lived secrets present in the job—npm, signing or notification credentials—need separate evaluation.

Detection and post-migration validation

Build a chain from GitHub event to workflow, commit, artifact and Cloudflare deployment. Every production release should map to an approved commit and file digest. A run from a fork, YAML changed immediately before deployment, unexpected log commands or a surprising artifact size are useful signals.

Runner logs may accidentally contain secrets, so access to them is sensitive. Enable masking, avoid secret-bearing debug output and retain logs according to investigation needs. A self-hosted runner exposed to untrusted code should be ephemeral; a persistent host can carry data and persistence between jobs.

After migration, run a negative control in a test repository: a fork contribution must not receive a production secret or deploy to production. Approval should bind to a specific commit so code cannot change afterward. Branch protection and CODEOWNERS for .github/workflows/ reduce silent supply-path edits.

Fact versus recommendation

The advisory establishes that every pages-action release is vulnerable, RCE is possible in particular workflows, no fix is planned and migration is required. Token exposure follows when credentials are present in the job environment. It does not mean every historical user was breached.

Repository owners should retain evidence of review: removed references, the new pinned component, token scope, declared permissions and a successful production-route check. That record makes it possible to prove that every project entered the migration. An organisation-wide repository rule can also reject future pull requests that attempt to add cloudflare/pages-action again, preventing an old copied workflow from silently restoring the risk.

Breachroad recommends using the migration as a trust-boundary review rather than a one-line edit. Actions, triggers, runners, permissions and tokens form one system. Teams practise this model in our cybersecurity training for organisations, while an independent cloud security assessment can review CI/CD exposure and secret scope.