GitHub Actions security risks expose secrets and privileged workflows

At a glance

What this is: This analysis explains why GitHub Actions has become a high-risk CI/CD identity layer, with secrets leakage, overprivileged tokens, mutable dependencies, and workflow injection as the main failure modes.

Why it matters: It matters because CI/CD workflows now behave like privileged non-human identities, so IAM, PAM, and secrets governance must cover build systems with the same discipline as production workloads and human access.

By the numbers:

• 51% adoption.
• GitHub Actions ranks as the second most-used CI/CD tool with a 33% adoption rate.

👉 Read Orca Security's analysis of GitHub Actions security risks and workflow abuse

Context

GitHub Actions is a CI/CD automation layer built into GitHub, where workflows run code in response to repository events and often inherit access to secrets, repos, and deployment systems. In identity terms, that makes each workflow a non-human identity boundary, not just a developer convenience layer, and that boundary is where the article’s primary risk begins.

Orca Security’s core point is that many teams still secure application code more carefully than the automation fabric that builds and ships it. The result is a governance gap across secrets, permissions, dependency trust, and event-driven execution, which is typical of modern CI/CD estates and therefore broadly relevant to NHI and IAM programmes.

The article’s examples map directly to identity governance concerns: hardcoded credentials, broad GITHUB_TOKEN permissions, mutable action references, untrusted pull request input, and artifact reuse across trust zones. Those are not isolated pipeline bugs, but recurring patterns of privilege and trust misalignment.

Key questions

Q: How should security teams reduce workflow privilege in GitHub Actions?

A: Start from a deny-by-default permission model, then grant only the exact repository and deployment rights each job needs. Separate read-only build steps from privileged release steps, and audit legacy repositories for inherited write access. The goal is to make workflow privilege explicit, reviewable, and easy to revoke when the pipeline changes.

Q: Why do GitHub Actions workflows create secrets management risk?

A: Workflows often need credentials to reach APIs, cloud platforms, and internal services, which makes them high-value identity targets. If secrets are hardcoded, logged, or overexposed in environment variables, attackers can reuse them outside the pipeline. The risk is not only leakage, but the speed at which leaked secrets become production access.

Q: What breaks when untrusted pull request content is executed in a workflow?

A: The workflow stops being a controlled automation step and becomes an attacker-controlled command channel. Issue titles, branch names, and PR text can carry shell metacharacters or malicious payloads if they are interpolated into scripts. That turns normal collaboration data into executable input and makes the pipeline itself the injection surface.

Q: How should teams handle third-party GitHub Actions in production pipelines?

A: Treat each third-party action as delegated trust and verify it before use. Pin it to immutable references, review its dependencies, and restrict what secrets or deployment permissions it can reach. If an action can influence releases, credentials, or self-hosted runners, it belongs in the same risk tier as any external machine identity.

Technical breakdown

Secrets management in GitHub Actions

GitHub Actions workflows often need credentials to authenticate to cloud services, package registries, and internal APIs. The security issue is not that secrets are used, but that they are easily exposed in workflow code, logs, error output, and environment handling. Hardcoded passwords are the obvious failure, but the deeper problem is that CI/CD jobs execute in a context where secrets can be copied, echoed, or reused faster than reviewers can spot them. Once a secret is leaked, the workflow boundary has already failed as an identity control plane.

Practical implication: move secrets out of workflow code and treat every CI/CD secret as a revocable identity credential, not a configuration value.

Overprivileged GITHUB_TOKEN permissions

Every workflow receives a GITHUB_TOKEN, but the token’s effective risk depends on how much access GitHub grants by default and how narrowly teams scope it. Older repositories can still carry write-all style permissions, which means a workflow that only needs read access may still be able to alter code, publish releases, or read sensitive content. In identity terms, this is privilege creep inside automation. Least privilege must be applied at the workflow and job level, otherwise the CI/CD plane becomes a standing-access identity with more power than the task requires.

Practical implication: start from no permissions and add only the minimum token scope each workflow step truly needs.

Workflow injection, artifact poisoning, and runner trust

GitHub Actions becomes dangerous when untrusted input is allowed to shape execution. Pull request text, branch names, and issue fields can be injected into shell commands, while pull_request_target and workflow_run patterns can mix untrusted code with privileged tokens or downstream deployment steps. Third-party actions add another layer of transitive trust, because a compromise in one action can cascade into many repositories. Self-hosted runners extend that risk further by turning ephemeral jobs into persistent infrastructure footholds if isolation is weak.

Practical implication: separate untrusted execution from privileged execution, and assume runners and third-party actions are part of your trust boundary.

Threat narrative

Attacker objective: The attacker wants to turn CI/CD automation into a trusted execution path for stealing credentials, poisoning releases, and extending access into production systems.

1. Entry occurs when attackers exploit workflow triggers, untrusted pull request content, or compromised third-party actions that run inside trusted pipelines.
2. Escalation happens when leaked secrets, broad GITHUB_TOKEN permissions, or artifact reuse let the attacker move from one job to repository-level or deployment-level control.
3. Impact is achieved when the workflow is used to exfiltrate secrets, alter source code, publish malicious releases, or persist on self-hosted runners.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

GitHub Actions should be treated as a non-human identity control plane, not a build convenience. The article shows workflows inheriting secrets, repository authority, and deployment reach, which places CI/CD squarely inside identity governance. Once the workflow can authenticate, modify, and trigger downstream systems, IAM teams need to govern it as an active identity with scoped privilege and lifecycle boundaries.

Standing privilege in CI/CD is the failure mode, not just broad permissions. The article’s GITHUB_TOKEN example shows how older repositories can keep write-all defaults long after the original need has passed. That means the real problem is durable access that outlives the task, which is exactly the kind of privilege creep NHI programmes are meant to eliminate. Practitioners should treat workflow permissions as reviewable identity entitlements, not static configuration.

Workflow injection is a trust-boundary failure between human input and machine execution. Pull request text, branch names, and issue content are not just data when they are fed into shell commands. The governance assumption that user-generated text is inert collapses the moment a workflow executes it, which is why CI/CD security must distinguish safe metadata handling from executable content handling.

Mutable dependency trust: every third-party action is a delegated identity with transitive risk. The article’s dependency pinning discussion shows that tags, branches, and marketplace actions can shift without warning, and the risk extends through each dependency layer those actions call. This is the same governance pattern seen in other NHI supply chains: trust is inherited unless it is explicitly constrained, so practitioners should evaluate action trust as they would any external machine identity.

Self-hosted runners extend the identity problem into infrastructure persistence. If a runner survives beyond a single job, it can retain compromise, network reach, or cached material that outlives the intended execution window. That turns ephemeral automation into a durable foothold, which means build infrastructure must be governed as high-risk NHI rather than ordinary compute. The implication is that runner isolation and reset discipline are identity controls, not just platform hardening.

From our research:

• From our research: 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• For broader identity control context, the Top 10 NHI Issues frames the privilege, visibility, and lifecycle problems that CI/CD pipelines often inherit.

What this signals

Workflow governance is now an identity programme problem, not a developer-only problem. When CI/CD automation can authenticate, deploy, and reach secrets, it needs the same lifecycle discipline as other non-human identities. Teams that keep workflow permissions, runner rebuilds, and secret rotation outside IAM oversight will continue to discover issues only after they have already become release or infrastructure incidents.

The scale of exposed secrets shows why this matters operationally: 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026. That volume means the practical question is no longer whether secret leakage can happen, but whether your programme can revoke and contain it before it becomes durable access.

Mutable action trust is the hidden governance gap. As teams adopt more reusable actions and shared workflow components, they inherit more transitive identity risk. The right response is to map workflow trust the same way you map privileged access paths, then align that map with the OWASP Non-Human Identity Top 10 and your internal build-system controls.

For practitioners

• Reset workflow permissions to zero by default Start each repository with permissions: {} and grant only the minimum access needed per job. Review legacy repositories for write-all defaults, then document each exception as an explicit identity entitlement.
• Remove secrets from workflow code paths Store credentials in managed secret stores, inject them only at runtime, and audit logs and debug output for accidental disclosure. Rotate any secret that has been echoed, exported, or exposed through a failed job.
• Separate untrusted triggers from privileged execution Do not run attacker-controlled pull request content in jobs that can access deployment tokens or repository write permissions. Use isolated validation workflows for untrusted input and privileged workflows only after trust has been established.
• Pin third-party actions to immutable references Replace mutable tags and branches with commit hashes, then review the action’s dependency chain before allowing it into production pipelines. Reassess any action that can reach secrets, release steps, or self-hosted runners.
• Treat self-hosted runners as disposable assets Rebuild runners from clean images, remove persistent state after each job, and restrict network access to only the services a workflow truly needs. This limits the blast radius if a workflow or action is compromised.

Key takeaways

• GitHub Actions is a privileged identity layer, so workflow security must be governed like NHI, not treated as ordinary code hygiene.
• The main failure modes are secrets leakage, overbroad tokens, mutable dependencies, and execution of untrusted input inside privileged jobs.
• Teams should reduce default permissions, pin and review third-party actions, separate untrusted and privileged execution, and rebuild self-hosted runners routinely.

Key terms

• Workflow identity: A workflow identity is the effective security identity created when an automated pipeline can authenticate, access resources, and trigger downstream actions. In practice, it behaves like a non-human identity and should be governed with scoped permissions, reviewable ownership, and revocation paths.
• Privilege creep: Privilege creep is the accumulation of access beyond what a task or system currently needs. In CI/CD, it often appears when old repositories keep broad token defaults, making automation more powerful than the job requires and harder to audit.
• Mutable reference: A mutable reference is a tag, branch, or alias that can point to different code over time. In GitHub Actions, mutable references increase supply chain risk because the code you trusted yesterday may no longer be the code you execute today.
• Artifact poisoning: Artifact poisoning happens when untrusted build outputs are later consumed by a privileged workflow as if they were safe. The danger is not the artifact itself, but the mistaken assumption that something produced in one trust zone remains harmless in another.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: GitHub Actions security risks and workflow abuse. Read the original.