LiveActive security incident?Get immediate response
MITRE ATT&CK® Technique

T1677: Poisoned Pipeline Execution

Adversaries may manipulate continuous integration / continuous development (CI/CD) processes by injecting malicious code into the build process. There are several mechanisms for poisoning pipelines: * In a Direct Pipeline Execution scenario, the threat actor directly modifies the CI configuration file (e.g., `gitlab-ci.yml` in GitLab). They may include a command to exfiltrate credentials leveraged in the build process to a remote server, or to export them as a workflow artifact.[1][2] * In an Indirect Pipeline Execution scenario, the threat actor injects malicious code into files referenced by the CI configuration file. These may include makefiles, scripts, unit tests, and linters.[2] * In a Public Pipeline Execution scenario, the threat actor does not have direct access to the repository but instead creates a malicious pull request from a fork that triggers a part of the CI/CD pipeline. For example, in GitHub Actions, the `pull_request_target` trigger allows workflows running from forked repositories to access secrets. If this trigger is combined with an explicit pull request checkout and a location for a threat actor to insert malicious code (e.g., an `npm build` command), a threat actor may be able to leak pipeline credentials.[1][3] Similarly, threat actors may craft pull requests with malicious inputs (such as branch names) if the build pipeline treats those inputs as trusted.[4][5][6] Finally, if a pipeline leverages a self-hosted runner, a threat actor may be able to execute arbitrary code on a host inside the organization’s network.[7] By poisoning CI/CD pipelines, threat actors may be able to gain access to credentials, laterally move to additional hosts, or input malicious components to be shipped further down the pipeline (i.e., Supply Chain Compromise).
EnterpriseT1677TechniqueObject v1.0Modified
Discuss defensive coverageBack to ATT&CK
Glexia's Take · Automated analysis

Security context for executives and security teams

Automation confidenceMedium

T1677: Poisoned Pipeline Execution describes Adversaries may manipulate continuous integration / continuous development (CI/CD) processes by injecting malicious code into the build process. There are several mechanisms for poisoning pipelines: * In a Direct Pipeline Execution scenario, the threat actor directly modifies the CI configuration file (e.g., `gitlab-ci.yml` in GitLab). They may include a command to exfiltrate credentials leveraged in the build process to a remote server, or to export them as a workflow artifact.(Citation: Unit 42 Palo Alto GitHub A...

Executive priority

T1677: Poisoned Pipeline Execution is an official MITRE ATT&CK technique. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.

Technical view

Security teams should validate T1677: Poisoned Pipeline Execution by reviewing the official ATT&CK relationships, mapped tactics (execution), supported platforms (SaaS), and available local telemetry before making detection or mitigation decisions.

Likely telemetry

  • Official ATT&CK relationships and object metadata
  • Endpoint process, command-line, and script execution logs

Detection direction

  • Validate whether T1677: Poisoned Pipeline Execution appears in your detection coverage and tabletop scenarios.
  • Use the object to align executive risk language with SOC, incident response, and detection engineering work.
  • Do not treat ATT&CK relationship context as attribution without corroborating evidence.

Mitigation priorities

  • Map the object to existing controls and identify missing telemetry or response ownership.
  • Prioritize mitigations that reduce exposure on the listed platforms and tactics.
  • Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.
Additional notes and limits

Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.

This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

Poisoned Pipeline Execution

Adversaries may manipulate continuous integration / continuous development (CI/CD) processes by injecting malicious code into the build process. There are several mechanisms for poisoning pipelines: * In a Direct Pipeline Execution scenario, the threat actor directly modifies the CI configuration file (e.g., `gitlab-ci.yml` in GitLab). They may include a command to exfiltrate credentials leveraged in the build process to a remote server, or to export them as a workflow artifact.[1][2] * In an Indirect Pipeline Execution scenario, the threat actor injects malicious code into files referenced by the CI configuration file. These may include makefiles, scripts, unit tests, and linters.[2] * In a Public Pipeline Execution scenario, the threat actor does not have direct access to the repository but instead creates a malicious pull request from a fork that triggers a part of the CI/CD pipeline. For example, in GitHub Actions, the `pull_request_target` trigger allows workflows running from forked repositories to access secrets. If this trigger is combined with an explicit pull request checkout and a location for a threat actor to insert malicious code (e.g., an `npm build` command), a threat actor may be able to leak pipeline credentials.[1][3] Similarly, threat actors may craft pull requests with malicious inputs (such as branch names) if the build pipeline treats those inputs as trusted.[4][5][6] Finally, if a pipeline leverages a self-hosted runner, a threat actor may be able to execute arbitrary code on a host inside the organization’s network.[7] By poisoning CI/CD pipelines, threat actors may be able to gain access to credentials, laterally move to additional hosts, or input malicious components to be shipped further down the pipeline (i.e., Supply Chain Compromise).

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Associated objects

Groups, software, and campaigns

GroupEnterprise

G1056: TeamPCP

TeamPCP is a financially-motivated, cloud-native threat group that has been active since at least September 2025. Initially focused on ransomware and cryptocurrency theft, TeamPCP shifted in early 2026 to systematic, worm-driven credential theft and software supply chain attacks targeting Continuous Integration and Continuous Delivery (CI/CD) workflows. TeamPCP has monetized access through extortion and through partnerships with ransomware actors including Vect and CipherForce.[1][2][3][4][5][6]

MalwareEnterprise

S9008: Shai-Hulud

Shai-Hulud is a supply chain worm, first reported in September 2025, that spreads through code repositories, including GitHub and NPM packages. It exploits CI/CD pipeline dependencies to propagate to victims and poisons the supply chain by publishing malicious packages. Once inside a victim environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows.[1][2][3][4][5][6][7]

LinuxSaaSWindows
MalwareEnterprise

S9043: Mini Shai-Hulud

Mini Shai-Hulud is a credential stealer and self-replicating supply chain worm, derived from Shai-Hulud, that has been used by TeamPCP to target Continuous Integration and Continuous Delivery/Deployment (CI/CD) workflows since at least 2026. Mini Shai-Hulud can compromise credentials across multiple cloud, container, and AI configuration file paths and can use stolen npm and GitHub OIDC tokens to spread to other packages maintained by the compromised user. Mini Shai-Hulud also has a targeted wiper component and has used multiple C2 and data exfiltration mechanisms.[1][2][3][4][5][6]

ContainersIaaSLinux
MalwareEnterprise

S9042: CanisterWorm

CanisterWorm is a self-propagating malware that has been used by TeamPCP in credential harvesting and software supply chain campaigns since at least 2026. CanisterWorm has used npm credentials to infect software packages and propagate across developer ecosystems. CanisterWorm has a targeted wiper component and can use decentralized C2 infrastructure implemented via an Internet Computer Protocol (ICP) blockchain canister.[1][2][3][4]

ContainersLinux
Relationship explorer

All related ATT&CK context

mitigates · MitigationM1018: User Account ManagementEnterprisemitigates · MitigationM1054: Software ConfigurationEnterpriseuses · MalwareS9008: Shai-HuludEnterpriseuses · MalwareS9043: Mini Shai-HuludEnterpriseuses · MalwareS9042: CanisterWormEnterpriseuses · GroupG1056: TeamPCPEnterprisedetects · Detection StrategyDET0533: Detection Strategy for Poisoned Pipeline Execution via SaaS CI/CD WorkflowsEnterprise
Mitigations

Mitigation direction

MitigationEnterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

MitigationEnterprise

M1054: Software Configuration

Software configuration refers to making security-focused adjustments to the settings of applications, middleware, databases, or other software to mitigate potential threats. These changes help reduce the attack surface, enforce best practices, and protect sensitive data. This mitigation can be implemented through the following measures:

Conduct a Security Review of Application Settings:

- Review the software documentation to identify recommended security configurations. - Compare default settings against organizational policies and compliance requirements.

Implement Access Controls and Permissions:

- Restrict access to sensitive features or data within the software. - Enforce least privilege principles for all roles and accounts interacting with the software.

Enable Logging and Monitoring:

- Configure detailed logging for key application events such as authentication failures, configuration changes, or unusual activity. - Integrate logs with a centralized monitoring solution, such as a SIEM.

Update and Patch Software Regularly:

- Ensure the software is kept up-to-date with the latest security patches to address known vulnerabilities. - Use automated patch management tools to streamline the update process.

Disable Unnecessary Features or Services:

- Turn off unused functionality or components that could introduce vulnerabilities, such as debugging interfaces or deprecated APIs.

Test Configuration Changes:

- Perform configuration changes in a staging environment before applying them in production. - Conduct regular audits to ensure that settings remain aligned with security policies.

*Tools for Implementation*

Configuration Management Tools:

- Ansible: Automates configuration changes across multiple applications and environments. - Chef: Ensures consistent application settings through code-based configuration management. - Puppet: Automates software configurations and audits changes for compliance.

Security Benchmarking Tools:

- CIS-CAT: Provides benchmarks and audits for secure software configurations. - Aqua Security Trivy: Scans containerized applications for configuration issues.

Vulnerability Management Solutions:

- Nessus: Identifies misconfigurations and suggests corrective actions.

Logging and Monitoring Tools:

- Splunk: Aggregates and analyzes application logs to detect suspicious activity.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.

ATT&CK release
19.2
Object version
1.0
Created
Modified
Raw hash
ae1c3d3184a4a00c...
Imported snapshots across ATT&CK releases(2)
ReleaseBundle importedObject versionModifiedStatusRaw hash
19.21.0Current bundleae1c3d3184a4…
19.11.0Older bundleae1c3d3184a4…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSONOpen MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Unit 42 Palo Alto GitHub Actions Supply Chain Attack 2025

    Omer Gilm Aviad Hahami, Asi Greenholts, and Yaron Avital. (2025, March 20). GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj-actions/changed-files Incident: Threat Assessment . Retrieved May 22, 2025.

    Open source URL
  2. [2]
    OWASP CICD-SEC-4

    OWASP. (n.d.). CICD-SEC-4: Poisoned Pipeline Execution (PPE). Retrieved May 22, 2025.

    Open source URL
  3. [3]
    GitHub Security Lab GitHub Actions Security 2021

    Jaroslav Lobačevski. (2021, August 3). Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests. Retrieved May 22, 2025.

    Open source URL
  4. [4]
    Wiz Ultralytics AI Library Hijack 2024

    Wiz Threat Research. (2024, December 9). Ultralytics AI Library Hacked via GitHub for Cryptomining. Retrieved May 22, 2025.

    Open source URL
  5. [5]
    Synactiv Hijacking GitHub Runners

    Hugo Vincent. (2024, May 22). Hijacking GitHub runners to compromise the organization. Retrieved May 22, 2025.

    Open source URL
  6. [6]
    GitHub Security Labs GitHub Actions Security Part 2 2021

    Jaroslav Lobačevski. (2021, August 4). Keeping your GitHub Actions and workflows secure Part 2: Untrusted input. Retrieved May 22, 2025.

    Open source URL
  7. [7]
    John Stawinski PyTorch Supply Chain Attack 2024

    John Stawinski IV. (2024, January 11). Playing with Fire – How We Executed a Critical Supply Chain Attack on PyTorch. Retrieved May 22, 2025.

    Open source URL
  8. [8]
    mitre-attackT1677
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK siteOfficial STIX data repositoryMITRE ATT&CK terms of use