GitHub deployment workflows can leak secrets through fork PR abuse

At a glance

What this is: This analysis shows how GitHub deployment workflows can be abused to inject commands, trigger malicious environments, and exfiltrate secrets from seemingly trusted automation.

Why it matters: It matters because identity, secrets, and workflow permissions are being treated as trusted inputs when they should be treated as attacker-controlled data in CI and deployment pipelines.

By the numbers:

• At least 38 public GitHub apps require deployments: write permissions, suggesting a broad ecosystem exposure to deployment-based trust assumptions.
• At least 97 public GitHub apps require deployments: read/write permissions, creating a large consumer surface for deployment notifications and trust abuse.
• The researcher disclosed the findings to over 15 affected vendors, indicating the pattern was widespread enough to warrant coordinated remediation.

👉 Read Boost Security's analysis of GitHub deployment workflow secret exfiltration

Context

GitHub deployment workflows are meant to connect CI pipelines to trusted environment events, but that trust boundary becomes brittle when repository automation accepts attacker-influenced environment names, URLs, and pull request context. In this case, the primary problem is not a single bug but an identity and authorization failure inside automation that treats external input as if it were an approved deployment signal.

For IAM and NHI practitioners, the lesson is that secrets, tokens, and workflow permissions behave like non-human identities with their own lifecycle and trust boundaries. When those identities are reachable through fork pull requests or default-scoped tokens, the workflow itself becomes part of the attack surface, not just the application code.

Key questions

Q: What breaks when fork pull request workflows can influence deployment context?

A: The trust model breaks because the workflow starts treating attacker-influenced deployment metadata as if it came from a controlled release path. That can enable command injection, fake environment creation, and secret exposure. The fix is to require approval for external contributors, validate every deployment field, and keep secrets out of jobs that can be reached through untrusted pull requests.

Q: Why do deployment workflows create a secrets risk in CI pipelines?

A: Deployment workflows often run with assumptions about trusted sources, approved environments, and limited operator scrutiny. If any of those assumptions are false, the workflow can pass API keys or tokens to an attacker-controlled command or URL. This is why secrets handling in CI must be tied to trust boundaries, not just to the presence of a secure branch.

Q: How do security teams know if a workflow is still too permissive?

A: Look for secret access on untrusted events, action references that move without review, cache writes from forked runs, and any job that can publish or deploy without a protected branch or environment gate. If a workflow can both ingest untrusted input and spend real privilege, it is still over-permissive.

Q: Who is accountable when a workflow leaks secrets through deployment abuse?

A: Accountability usually spans repository owners, platform engineering, and the teams that defined the workflow and its permission model. Security governance frameworks expect explicit control ownership, because automation failures are still governance failures. For NHI programmes, the accountable party is whoever owns the machine identity, its scopes, and the approval gates around it.

Technical breakdown

How deployment_status workflows become an attack surface

GitHub deployment events can trigger workflows that assume the deployment source is trusted, especially when the job reads environment metadata such as environment name or URL. The problem is that workflows can be constructed so an attacker influences those fields through a fork pull request or a referenced environment that GitHub creates automatically if it does not already exist. Once that context reaches a run step, inline shell interpolation can turn metadata into executable commands. The result is not just script injection. It is trust inversion, where a deployment signal becomes a delivery mechanism for attacker-controlled input.

Practical implication: treat deployment metadata as untrusted input and block workflows that execute it inline.

Why environment creation and default token scope matter

GitHub’s environment model can create a false sense of safety because teams assume protected environments already exist and are being enforced. If a workflow references a missing environment, GitHub can create it with the supplied name, which can bypass the operator’s expectation that approvals or protection rules were in place. At the same time, the default GITHUB_TOKEN may have broader permissions than the workflow actually needs. In combination, environment auto-creation and over-scoped identity permissions create a control gap that allows malicious pull requests to reach sensitive actions without crossing the intended approval boundary.

Practical implication: require explicit environment allowlists and reduce default GitHub token permissions to the minimum.

How attacker-controlled URLs turn validation into exfiltration

Even when a workflow avoids obvious shell injection, the deployment URL itself may still be attacker-controlled. If a job sends secrets to that URL for validation, notification, or test setup, the workflow can behave like a server-side request forgery path, but within a CI context. That means the issue shifts from code execution to credential relay. This is why defensive patterns that only sanitize run statements do not fully solve the problem. The trust model must extend to every field that influences network requests, test endpoints, and downstream integrations.

Practical implication: validate deployment URLs separately and never send secrets to a URL that is not explicitly trusted.

Threat narrative

Attacker objective: The attacker wants to convert trusted deployment automation into a secret-extraction and execution path that can be reused across CI and integration workflows.

1. Entry occurs through a fork pull request that triggers a workflow using deployment metadata and a fabricated environment reference.
2. Credential access follows when inline interpolation or attacker-controlled URLs cause the workflow to expose API keys or high-privilege GITHUB_TOKEN values.
3. Impact is achieved through secret exfiltration, malicious deployments, or downstream abuse of trusted CI and notification integrations.

NHI Mgmt Group analysis

Deployment metadata is an identity boundary, not just a CI convenience. When workflows trust environment names, deployment URLs, and fork-supplied context, they are effectively trusting a non-human identity chain that has not been lifecycle-governed. That is an IAM problem disguised as automation glue. Practitioners should treat deployment context as an access-bearing identity surface, not as harmless metadata.

Automatic environment creation creates a standing trust assumption that attackers can reshape. The article shows that missing environments can be created on demand, which means approvals and rules are only meaningful if the expected environment already exists and is explicitly controlled. This is a classic governance gap: the control was assumed rather than enforced. Teams should review whether their environment model validates existence, ownership, and approval state before execution.

Inline interpolation is a secret-handling anti-pattern because it merges execution and data flow. Once shell syntax directly consumes deployment fields, the workflow no longer distinguishes code from input. That makes secrets, tokens, and URLs part of the same trust domain, which is exactly where exfiltration happens. Security teams should separate control data from executable statements and treat every interpolated field as potentially malicious.

Deployment trust abuse is a broader NHI lifecycle problem, not a GitHub-only issue. Any integration that uses service tokens, default workflow credentials, or external webhook callbacks can inherit the same failure mode if lifecycle controls are weak. This is why NHI governance must include runtime trust boundaries, not just inventory and rotation. The practitioner conclusion is to govern machine identities as active access paths, not static assets.

What this signals

GitHub automation is increasingly part of the identity plane, not just the delivery plane. As more workflows depend on deployment events, teams need to decide whether machine credentials, environment rules, and approval gates are governed like production access or left as convenience settings.

Deployment trust inversion: this is the pattern where a workflow assumes the deployment signal is trustworthy while the signal itself can be influenced by a fork PR, a missing environment, or an attacker-controlled URL. That pattern will recur anywhere CI pipelines blend control data with executable steps, so practitioners should review every place where automation accepts untrusted runtime context.

The practical signal for security teams is simple: if a workflow can expose secrets without a human approval path and without a fixed allowlist of environments, it is already operating outside a defensible trust model. That should trigger control review across IAM, secrets management, and pipeline governance together, not in separate silos.

For practitioners

• Require approval for external fork workflows Set repository and organization defaults so fork pull request workflows from external contributors require approval, not just first-time contributor gating, because typo-fix contributions can bypass weaker settings.
• Remove inline shell interpolation from deployment jobs Pass deployment name, environment, and URL through environment variables or validated inputs, and avoid using ${} syntax directly inside run statements where attacker-controlled context can reach the shell.
• Whitelist environments before secrets are available Allow only known environments in deployment_status workflows and ensure each one has explicit approval rules before any secret-bearing job can execute.
• Minimise default GitHub token permissions Set repository token permissions to read-only by default, then elevate only the exact scopes needed for a workflow that has been reviewed for trusted input handling.
• Separate trusted deployment URLs from attacker-controlled URLs Use only verified target_url values or other approved endpoints for downstream calls, and block any workflow that forwards secrets to environment_url without independent validation.

Key takeaways

• The core failure is a trust boundary collapse between GitHub deployment metadata and executable workflow logic.
• The exposure is not theoretical, because public GitHub apps and affected vendors show that the pattern has real operational reach.
• Teams should respond by tightening fork approvals, token scope, environment allowlisting, and secret handling in every deployment workflow.

Key terms

• Deployment Workflow Trust Boundary: The point at which a CI or release workflow stops operating on verified internal inputs and starts accepting context that can be influenced by users, forks, or external integrations. In practice, this boundary determines whether deployment metadata and environment values can be treated as safe.
• Attacker-Controlled Deployment Metadata: Deployment fields such as environment name, environment URL, or related status payload values that an attacker can influence through workflow design, fork submissions, or integration abuse. These fields become dangerous when they are used directly in commands or outbound requests.
• Workflow Secret Exfiltration: The theft of credentials, API keys, or tokens from an automated pipeline by turning a workflow into a conduit for data disclosure. It often happens when secrets are passed to untrusted commands, URLs, or logs that an attacker can observe or control.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full report

Boost Security's full analysis covers the operational detail this post intentionally leaves for the source:

• Exact workflow examples that can be reproduced or adapted for red-team validation
• The specific disclosure timeline across more than 15 affected vendors and remediation responses
• Implementation guidance for safer deployment_status handling in real GitHub Actions pipelines
• Comparisons between vulnerable and non-vulnerable integrations such as Argos CI and Checkly

👉 Boost Security's full post covers the attack chain, vulnerable integration patterns, and recommended GitHub Actions hardening steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security and identity practitioners connect workflow risk to the broader access model their programmes depend on.