What happens when workflow permissions are broad in a repository that accepts pull requests?

Broad workflow permissions can let a malicious pull request do more than build code. If an attacker reaches code execution inside the runner, they may approve or merge changes, alter side branches, or create release tags that push malicious code downstream. Tight branch protection and read only workflow permissions reduce that blast radius.

Why Broad Workflow Permissions Change the Risk Profile

When a repository accepts pull requests, workflow permissions are no longer just a build setting. A malicious contributor can use a writable workflow context to turn code execution in the runner into repository control, which means the compromise can move from “run arbitrary commands” to “change what gets released, merged, or trusted.” That is a much larger blast radius than normal code review risk.

The main issue is that workflow logic often runs with more authority than the code being reviewed. If the workflow can write to the repository, approve changes, or create tags, then an attacker who reaches that execution path can influence both the source tree and the release path. Read-only defaults, narrow token scopes, and branch protection are what keep a pull request from becoming a control-plane compromise.

Even when the initial payload looks like a routine CI job, the real danger is that the workflow can be used as a bridge into persistent changes. In practice, that means a trusted automation path can be abused to place malicious code into a branch, publish it under a release tag, or make the compromise harder to spot because it arrived through an apparently legitimate workflow event.

How the Abuse Path Usually Expands

Once a runner can execute attacker-controlled steps, the next question is not whether the code built successfully, but what other repository actions the workflow identity can perform. If permissions are broad, the same job may be able to commit back to the repo, update side branches, or create release artifacts that downstream systems treat as authoritative. For related controls on least privilege and release-path hardening, see Privileged Access Management Guide and Just-in-Time Access and Zero Standing Privilege Guide.

The practical pattern is escalation through trust. A pull request is supposed to be a reviewable change request, but broad workflow permissions let the automation layer act as if the change is already trusted. That is why malicious workflow activity can be especially damaging in repositories that automatically publish packages, trigger deploys, or treat tags as release signals.

That trust boundary also matters for governance. If workflow permissions are broad, it becomes difficult to tell whether a branch update, tag creation, or merge came from a human decision or from an untrusted job running in response to an external contribution. A repository can look healthy while the automation layer is quietly making the most sensitive decisions.

Controls That Reduce the Blast Radius

The safest default is to separate build activity from privileged repository actions. Workflow tokens should be read only unless a specific step has a justified need for write access, and branch protection should require human review before merges or release actions. In repositories with stronger access models, that often means treating workflow permissions as a privilege boundary, not a convenience setting. The same principle is explained well in Authorisation Models Guide and Cloud PAM and CIEM Guide.

Release tags, protected branches, and approval gates should be controlled by identities that are distinct from the job that tests the pull request. If the same workflow can both validate code and publish it, then a single compromise can traverse the full delivery chain. Separate duties and narrower scopes make that path much harder to abuse.

Good practice is to assume that anything reachable from untrusted pull request content is hostile until proven otherwise. That means validating which workflow events can write, which branches can be updated, and which artifacts are promoted automatically. For a repository that relies on automated delivery, that review is as important as the code review itself.

Risk and Threat Considerations

Broad workflow permissions create a high-value attack path because they can turn a low-privilege pull request into repository-level action. If an attacker achieves code execution in the runner, the workflow identity may be able to alter source, create tags, or push malicious releases into downstream systems.

Failure mechanism: A workflow triggered by untrusted input inherits permissions that are broader than the pull request author should ever have, so the runner becomes a bridge from code execution to repository control.

Impact: The attacker can persist malicious changes, poison release artifacts, or bypass the normal review flow, which can turn one compromised job into a supply-chain incident.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API5 — Broken Function Level Authorization	Broad workflow rights can let untrusted code invoke repository actions it should not have.
Recommendation — Restrict workflow-triggered actions to the minimum functions needed for the job.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Workflow tokens should not exceed the permissions required for validation tasks.
	CM-5 — Access Restrictions for Change	Protecting branches, tags, and release actions depends on restricting who can change them.
Recommendation — Limit workflow permissions to the minimum access each step requires. Require approval and explicit authorization before repository state changes.
CIS Controls v8	CIS-6 — Access Control Management	Repository workflows need controlled privileges and periodic review to reduce abuse paths.
Recommendation — Review and reduce workflow access paths that can alter trusted repository state.
NIST CSF 2.0	PR.AA-05 — Least Privilege, Access Permissions and Segregation of Duties	Broad workflow permissions violate least privilege and blur duties between review and release.
Recommendation — Separate untrusted build steps from privileged release actions.

Practitioner Guidance

What to verify: Check whether any pull-request-triggered workflow can write to the repository, create tags, approve changes, or publish artifacts. If it can, treat that path as privileged and reduce it before anything else.

Decision rule: If the workflow needs write access only for a narrow post-validation step, split the job so the untrusted portion runs with read-only permissions and the privileged step is separately gated.

Common mistake: Teams often protect the branch but leave workflow tokens broad, which still lets an attacker abuse the automation layer to reach the same outcome through a different path.

Practitioner takeaway: The key question is not whether the pull request is merged, it is whether untrusted workflow code can reach a permission level that changes repository state or release trust.