GitHub Actions abuse shows how CI can become attack infrastructure

At a glance

What this is: This is a weekly security briefing on a campaign where compromised development packages and GitHub-hosted runners were used as live attack infrastructure, not just as a delivery vector.

Why it matters: It matters because CI, build runners, and package workflows can become the place where attackers scan, exploit, and exfiltrate secrets unless identity and execution boundaries are governed as production risk.

Context

GitHub Actions and package workflows are often treated as build plumbing, but this campaign shows they can become operational attack surfaces. Once an attacker reaches a trusted workflow or runner, the environment can be used to launch scans, reach external targets, and collect secrets with the same permissions and network reach that legitimate automation relies on.

The identity security angle is direct: CI runners, package tokens, cloud credentials, and source-control secrets are all non-human identities or identity-bound credentials that need lifecycle control. When those credentials are usable from ephemeral automation without tight scope, the build system can act like an attacker-controlled workstation.

Key questions

Q: What breaks when a trusted package can run code on developer or CI systems?

A: The main failure is that software provenance does not stop runtime abuse. If install-time or import-time code can reach environment variables, local secret stores, or process memory, a legitimate package can become a credential stealer. That turns dependency management into an identity exposure problem, especially for cloud and pipeline credentials.

Q: Why do CI runners create such a high risk of secret exposure?

A: Runners often load secrets into memory during execution and, in self-hosted cases, may also retain credentials on disk between jobs. That combination gives attackers two collection paths at once, so secret minimisation and short-lived runtime retrieval matter more than static storage.

Q: What are the signs that CI is being used as attack infrastructure?

A: Look for outbound scanning, repeated connection attempts to internet-facing services, unusual package-triggered execution, and secrets used from contexts that do not match the build stage. Those signals show the workflow is no longer just compiling code. It is being repurposed as an operational foothold.

Q: How should security teams govern GitHub Actions in high-trust repositories?

A: Treat GitHub Actions as privileged automation, not background glue. Restrict event triggers, review command interpolation, separate build and release permissions, and limit which tokens are exposed to each workflow. If a workflow can write code, secrets, or artefacts, it needs the same review discipline as a privileged account.

Technical breakdown

How compromised packages become execution inside CI

A package supply-chain compromise is not limited to malicious code on install. In this case, development versions tied to GitHub Actions workflows gave the attacker a foothold inside automation that already had permission to run code, access repositories, and talk to external systems. That changes the threat from passive dependency risk to active execution in a trusted runtime. GitHub-hosted runners are especially useful to attackers because they are ephemeral, Internet-connected, and often provisioned with just enough trust to complete build tasks. Once malicious workflow logic or package-triggered execution is present, the runner becomes a controlled launch point rather than a defensive boundary.

Practical implication: Treat workflow execution as a privileged runtime and constrain what untrusted package code can do in CI.

Why CI secrets are high-value targets for attackers

CI systems routinely hold the credentials that link source control to cloud services, package registries, databases, and deployment targets. Those secrets are often loaded automatically into runners and then exposed to whatever code the pipeline executes. If scope is too broad, a single workflow compromise can pivot from build activity to cloud access, application control, and secret harvesting. This is a classic identity problem as much as a software one: the runner is an identity-bearing workload, and its credentials define the blast radius. When those credentials are reusable outside the exact build step they were meant for, the pipeline becomes a credential extraction path.

Practical implication: Reduce runner permissions and isolate secrets so pipeline execution cannot reuse them outside the intended task.

How attacker-run scanners turn automation into reconnaissance

The campaign used GitHub-hosted Ubuntu runners to scan internet-facing targets and probe for exploitable services. That matters because CI is not just a place to compile code; it is also a networked execution platform that can be repurposed for discovery, enumeration, and follow-on exploitation. Security teams often watch for malicious binaries on endpoints but miss the fact that legitimate automation can be coerced into doing the same work under trusted identity. Once scanning is embedded in the workflow, detection becomes harder because the traffic comes from sanctioned infrastructure and blends with normal developer activity.

Practical implication: Monitor CI network egress and workflow behavior for enumeration patterns that do not belong in build activity.

Threat narrative

Attacker objective: The attacker wanted to turn trusted build automation into a secret-harvesting and exploitation platform that could be reused against external targets.

1. Entry occurred through compromised Packagist development packages and malicious GitHub workflow files that executed inside trusted CI contexts.
2. Credential access followed when the GitHub-hosted runners were used to harvest cloud, database, source-control, and application secrets from reachable environments.
3. Impact came from using CI as reusable attack infrastructure for scanning, exploitation, and broader compromise of cPanel and WHM targets.

Breaches seen in the wild

• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI has become an identity and runtime boundary, not just a build boundary. The article shows that trusted automation can be repurposed once attackers can execute inside the workflow. That means the security model has to treat runners, workflow tokens, and package-triggered execution as governed identities with constrained authority. Practitioners should stop assuming the build plane is harmless because it is short-lived.

Secret exposure in CI is now a blast-radius problem, not a storage problem. The issue is not only where secrets are stored, but which workloads can use them and under what execution conditions. When runners can reach cloud, database, and source-control systems, the runner itself becomes a high-value identity that needs privilege scoping, audience restrictions, and task-level containment. The practical conclusion is that CI credential design is part of identity architecture.

Attackers are industrialising developer plumbing as reusable infrastructure. This is the named concept that matters here: attack infrastructure inside CI. Once workflows can scan, pivot, and harvest under legitimate automation identity, the defensive focus shifts from single malicious packages to the governance of the whole delivery path. Security teams should treat this as a signal that software supply-chain and identity controls now intersect at runtime, not just at release time.

Package trust and workflow trust are now inseparable. A compromised package can trigger logic that runs with the authority of the pipeline, while a compromised workflow can amplify the reach of otherwise ordinary package code. That interaction means supply-chain governance has to include execution boundaries, not only dependency provenance. Practitioners should align CI hardening with NHI-style lifecycle control for tokens, service identities, and ephemeral runners.

Detection has to move closer to execution provenance. If trusted CI can be used for reconnaissance and secret harvesting, then alerting on known-bad binaries alone is insufficient. Teams need to know which workflow, which runner, and which credential touched a target and why. That is a governance requirement, not just an SOC tuning issue, and it should drive how build telemetry is retained and reviewed.

What this signals

Attack infrastructure inside CI: the key shift is from dependency compromise to workflow repurposing. When trusted automation can scan targets and pull secrets, the delivery pipeline becomes part of the adversary’s runtime, which means security teams need execution telemetry, not only package provenance.

For practitioners, the immediate implication is that build identities must be managed like any other privileged non-human identity. Short-lived tokens, isolated secrets, and restricted egress are now operational controls, not nice-to-have hardening, because the attacker’s goal is to reuse the pipeline after entry.

For practitioners

• Lock down workflow execution scope Restrict what untrusted packages and pull-request workflows can execute, especially where they can call external network resources or access repository secrets.
• Separate build identity from deployment identity Use distinct service identities and tokens for build, test, and deploy stages so compromise of one runner does not expose downstream environments.
• Reduce secret reachability inside runners Inject only the secrets required for a single task, and avoid exposing cloud, database, and source-control credentials to general-purpose workflow steps.
• Monitor CI egress for reconnaissance behavior Alert on scanning, enumeration, and unusual outbound traffic from GitHub-hosted or self-hosted runners because that activity indicates the pipeline is being used as attack infrastructure.

Key takeaways

• Compromised packages can do more than deliver malware. They can turn CI into a live execution environment that attackers reuse for scanning, exploitation, and secret collection.
• This campaign exposed the same operational weakness across package trust and workflow trust: both can be abused to reach cloud, database, source-control, and application credentials.
• The limiting control is not just better dependency review. Teams need tighter workflow permissions, narrower runner identity, and secrets that cannot be reused beyond the intended task.

Key terms

• Continuous Integration Runner: A continuous integration runner is the execution environment that processes build, test, and automation jobs. In security terms, it is a workload with identity, network reach, and access to secrets, so compromise of the runner can turn routine automation into an attack path.
• Workflow secret: A workflow secret is a credential, token, key, or certificate exposed to a CI/CD job so it can perform a task. Because these secrets can unlock cloud, code, or release systems, they must be treated as privileged identities with lifecycle, scope, and revocation requirements.
• Supply Chain Abuse: Supply chain abuse is the misuse of trusted third-party software, services, or dependencies to gain unauthorized access or distribute malicious activity. It exploits inherited trust across vendors, code libraries, update channels, or managed services, allowing attackers to reach targets indirectly through a weaker link in the delivery chain.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

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 workload identity. It helps security and identity practitioners build controls that match how modern automation actually runs.