On April 26, 2025, Grafana Labs disclosed that an unauthorized actor exploited a GitHub Actions misconfiguration to extract secrets from a public repository. The vulnerable workflow used the pull_request_target trigger, inadvertently granting elevated access and injecting secrets even for pull requests from forks. The attacker utilized script injection by crafting a malicious branch name, leading to the exfiltration of secrets via a JavaScript payload. The attack required no merges or privilege escalation. Upon gaining access, the attacker committed a secondary malicious workflow designed to encrypt and export secrets. Grafana Labs promptly responded by rotating credentials, disabling public GitHub Actions workflows, and conducting a full investigation.

‍

• Unauthorized access to GitHub App secrets (GRAFANA_DELIVERY_BOT_APP_ID and GRAFANA_DELIVERY_BOT_APP_PEM)
• Potential exfiltration of other CI/CD secrets via the malicious workflow
• GitHub Actions disabled across all public Grafana Labs repositories as a containment measure
• No access to production systems or customer data was detected
• Highlighted security risks associated with pull_request_target, emphasizing the need for secret auditing, environment-based permissions, runtime monitoring (e.g., StepSecurity Harden-Runner), and least-privilege configurations

On March 17, 2025, security researcher Adnan Khan publicly disclosed a supply chain compromise in the reviewdog/action-setup@v1 GitHub Action. Within hours, Wiz published an in-depth technical analysis. The attacker injected a base64-encoded Python payload into the action-setup Action that accessed sensitive memory on GitHub Actions runners to extract secrets. These secrets were exposed in plain text via build logs.

Because reviewdog/action-setup was a dependency for several other Actions in the reviewdog ecosystem, at least five additional Actions were also considered compromised:

1. reviewdog/action-shellcheck
2. reviewdog/action-composite-template
3. reviewdog/action-staticcheck
4. reviewdog/action-ast-grep
5. reviewdog/action-typos

The incident was traced to a narrow compromise window on March 11, 2025, between 18:42 and 20:31 UTC. The maintainers responded by rotating secrets, revoking access tokens, and moving to commit-SHA-based pinning for all Actions and installation scripts.

‍

• CI/CD secret leakage via malicious memory-reading payload embedded in the GitHub Action
• Widespread ecosystem exposure as multiple Actions inherited the compromised base Action
• Public exposure of secrets in workflow logs, especially critical for public repositories
• High risk of credential reuse and follow-on supply chain attacks

‍

The tj-actions/changed-files Action, used in over 23,000 repositories, was silently compromised. Most version tags were updated to point to a malicious commit (0e58ed8671d6b60d0890c21b07f8835ace038e67) that embedded a Python script to extract secrets directly from runner memory. These secrets were displayed in plaintext in workflow logs—especially dangerous in public repositories. GitHub confirmed the incident under CVE-2025-30066.

The compromise occurred on March 14, 2025, and GitHub removed the Action temporarily on March 15, before restoring a clean version. The adversary exploited the tj-actions-bot account via an unknown method. The injected payload used the curl command to fetch a Python memory-dump script from an external Gist, executed it with sudo, and filtered the output for secret-like values.

StepSecurity’s Harden-Runner flagged the attack based on anomalous network traffic. Affected users were advised to audit usage, rotate secrets, and replace the compromised Action with the secure drop-in replacement: step-security/changed-files.

‍

• Mass exposure of CI/CD secrets across public repositories
• Compromise of most released versions of tj-actions/changed-files via tag manipulation
• Secrets printed in public workflow logs, including potentially production credentials
• GitHub temporarily disabled and cleaned the repository
• StepSecurity released a free, secure alternative (step-security/changed-files) to contain fallout

‍

The Ultralytics repository was compromised in a coordinated supply chain attack that exploited both script injection and improper use of pull_request_target. A previously patched vulnerability was accidentally reintroduced in August 2024. On December 4, 2024, the attacker submitted malicious PRs (#18018, #18020) targeting these flaws.

The malicious payload executed during CI runs, siphoning sensitive secrets and modifying the release pipeline. Compromised tokens were used to inject a cryptominer into released artifacts distributed via PyPI. The scripts were eventually deleted, and logs erased, but the impact persisted.

StepSecurity’s Harden-Runner platform was used to simulate and analyze the attack. In audit mode, it detected anomalous network calls; in block mode, it successfully prevented the attack by denying connections to external payload-hosting URLs (like gist.githubusercontent.com).

The exploit demonstrated how insufficient input sanitization and unsafe GitHub Action triggers can enable deep compromise of CI/CD systems—leading to poisoned builds and widespread end-user exposure.

‍

• Secrets Exfiltration: _GITHUB_TOKEN, API keys, and cache management secrets were stolen.
• Build Cache Poisoning: Malicious cryptomining payloads were injected into PyPI releases (v8.3.41 and v8.3.42).
• End-User Compromise: Users who installed affected PyPI packages unknowingly ran cryptominers.
• Artifact Tampering: Release pipelines were abused to modify official builds.

‍

In a demonstration of CI/CD vulnerabilities, a security researcher compromised Stripe’s open-source accept-a-payment repository by leveraging a misconfigured GitHub Actions workflow. The flaw stemmed from a combination of:

• Use of the pull_request_target trigger (which executes workflows with full repository permissions), and
• Checking out the pull request’s code via an explicit ref—a dangerous pattern when interacting with external forks.

The researcher created a PR that injected malicious code into the pipeline. Upon triggering, the GitHub token was exposed and used to merge the PR into main without reviewer approval (PR #2719). In another PR (#2723), the researcher exfiltrated the token to a controlled server using wget.

The researcher responsibly disclosed the vulnerability and highlighted the potential damage: unauthorized merges, credential leaks, and possible downstream supply chain compromise.

‍

• GitHub Token Theft: Secrets like GITHUB_TOKEN were exfiltrated, exposing repository and CI/CD infrastructure.
• Unauthorized Merge: A malicious PR was automatically merged into main, bypassing review and branch protections.
• Proof-of-Concept Exfiltration: Demonstrated exfiltration to an external server, showcasing risk of real-world exploitation.

‍

On August 31, 2024, a security researcher demonstrated a successful supply chain attack on the Azure Karpenter Provider project, maintained by Microsoft. The project’s GitHub Actions CI/CD configuration included a vulnerable e2e.yml workflow that allowed execution of attacker-controlled code in a privileged context. The flaw was introduced via the ApprovalComment → resolve-args.yml → e2e.yml workflow chain, in which a user-supplied ref was used to check out and execute code.

The researcher inserted a malicious script into their fork and ensured its commit SHA was propagated through the artifact. Once the e2e.yml workflow ran, it executed the inserted script, which downloaded and ran a payload from gist.githubusercontent.com, and exfiltrated secrets to the domain n6uw1ivl7vxwuf43sas4hjs17sdj19py.oastify.com.

Fortunately, StepSecurity Harden-Runner had been enabled since January 2024 in audit mode, allowing StepSecurity to detect the anomalous outbound network traffic in real time. The attack was reported to the Microsoft Security Response Center (MSRC) within an hour and acknowledged publicly by Microsoft.

‍

• Exfiltration of privileged CI/CD credentials, including OIDC tokens via id-token: write permission
• Arbitrary code execution in a privileged workflow context
• Potential for a Codecov-style supply chain attack, where production cloud environments could have been accessed

‍

The backdoor was deliberately inserted into versions 5.6.0 and 5.6.1 of xz Utils by maliciously tampering the Makefile during the build process. For more details, please refer to our blog postDescription: The backdoor aimed to hijack SSH connections by allowing an attacker with a specific private key to insert and execute malicious code, potentially compromising systems running Debian or Red Hat distributions.

The compromised xz Utils versions affected several Linux distributions, including Fedora, Debian, openSUSE, and Kali Linux. | The backdoor, if successful, could have led to unauthorized access, data theft, and the execution of arbitrary commands on affected systems. | The incident raised concerns about supply chain security, highlighting the need for robust CI/CD pipeline security measures. | The CVE designation for this incident is CVE-2024-3094, providing a tracking designation for security researchers and users to monitor the issue.

Flank, an open-source project maintained by Google, was targeted in a simulated supply chain attack. A researcher submitted a PR from a fork and posted a comment that triggered a workflow with elevated permissions. This workflow checked out code from the untrusted PR and executed it—allowing the attacker to run a script that exfiltrated the GITHUB_TOKEN to GitHub Gist infrastructure.

The stolen token had write access, meaning it could have been used to overwrite Flank’s project releases or tamper with artifacts. The malicious script downloaded a Python snippet that scanned the Runner.Worker memory for secret values and sent them to an external endpoint.

‍

• Secrets Exfiltration: GITHUB_TOKEN was exfiltrated, potentially allowing tampering with code or releases.
• CI/CD Vulnerability: Flawed permissions and unsafe workflow triggers exposed critical infrastructure to compromise.
• Potential Supply Chain Attack: With write access, the attacker could have introduced backdoors into software releases.

‍

In April 2024, Wiz Research collaborated with Hugging Face to uncover critical architecture risks within AI-as-a-Service environments. The incident highlighted vulnerabilities in Hugging Face's infrastructure, particularly concerning shared inference infrastructure and CI/CD pipelines. Attackers exploited these vulnerabilities by uploading specially crafted malicious models, specifically in Python's Pickle format, which allowed them to execute arbitrary code within Hugging Face's Inference API environment. This not only raised concerns about privilege escalation but also showcased the potential for cross-tenant access to sensitive data and models stored within the platform.

The incident highlighted the potential for privilege escalation and cross-tenant access within AI-as-a-Service environments, posing significant security risks. | Vulnerabilities in shared inference infrastructure and CI/CD pipelines raised concerns about the integrity and security of data and models stored within AI platforms. | Insufficient scoping and network isolation within Hugging Face's container registry exposed the platform to potential supply chain attacks, emphasizing the need for enhanced container security practices. | The incident prompted Hugging Face to implement Wiz CSPM (Cloud Security Posture Management) and vulnerability scanning, enhancing their ability to proactively identify and mitigate security risks, leading to platform improvements and enhanced security measures.

In February 2024, security researchers from Cycode discovered a critical vulnerability in Bazel, a tool for automating software building and testing. The vulnerability, exploited through a command injection in a custom GitHub Action used by Bazel, could have allowed malicious code injection into GitHub Actions workflows. This posed a significant risk to software supply chains, potentially impacting millions of projects and users, including major organizations like Kubernetes, Angular, Uber, and LinkedIn. The incident highlighted the inherent security risks associated with third-party dependencies in CI/CD workflows and emphasized the need for robust security measures to prevent such vulnerabilities from compromising software integrity and production environments.

Possible impact on millions of projects and users relying on Bazel, including Kubernetes, Angular, Uber, LinkedIn, and more. | The incident highlighted the risks associated with custom GitHub Actions and the need for thorough security assessments and considerations when integrating third-party actions into CI/CD workflows. | Cycode's scan of 3.4 million workflows from GitHub repositories revealed that over 98% of them incorporated one or more custom actions, indicating the widespread adoption of potentially vulnerable practices in CI/CD pipelines. | In response to the incident, Cycode developed an open-source scanner called RAVEN (Risk Analysis and Vulnerability Enumeration for CI/CD) to detect exploitable instances like the one found in Bazel.

Adnan Khan and another researcher exploited a critical vulnerability in PyTorch, a major ML platform used by prominent organizations like Google, Meta, Boeing, and Lockheed Martin. This exploit allowed them to execute a supply chain attack. In addition to compromising PyTorch's CI/CD pipeline, the attackers also targeted GitHub secrets, including GitHub Personal Access Tokens (PATs) with extensive permissions. These tokens provided access to sensitive systems and repositories within the PyTorch organization, further amplifying the potential impact of the attack. The attackers demonstrated the ability to manipulate repository releases, modify release artifacts, and access AWS credentials, highlighting the breadth of the security breach.

The compromised xz Utils versions affected several Linux distributions, including Fedora, Debian, openSUSE, and Kali Linux. | The attackers stole sensitive GitHub secrets, including PATs with extensive permissions, granting access to a significant number of repositories within the PyTorch organization, posing a serious risk of code injection and manipulation. | Access to AWS keys, such as the "aws-pytorch-uploader-secret-access-key" and "aws-access-key-id," provided the attackers with privileges to upload malicious assets to AWS, further compromising the supply chain integrity and potentially impacting users relying on PyTorch releases.

Diamond Sleet and Onyx Sleet exploited a critical remote-code execution vulnerability in JetBrains TeamCity server, allowing them to infiltrate build environments. Microsoft observed these threat actors utilizing distinct tools and techniques post-exploitation, including the deployment of backdoors and DLL search-order hijacking attacks. These actions posed a significant risk to organizations using affected versions of TeamCity.

JetBrains released updates to address the vulnerability, and Microsoft provided mitigation guidance to affected users.

On January 4, 2023, CircleCI disclosed a security incident where an unauthorized third party accessed and exfiltrated sensitive data from a subset of production systems. Despite encryption measures, the attacker managed to extract encryption keys after stealing credentials and access of an employee's laptop, potentially compromising encrypted data. CircleCI promptly shut down compromised accounts, rotated tokens and credentials, and engaged third-party cybersecurity experts for investigation and validation.

Customer environment variables, tokens, and keys were compromised, affecting sensitive information security. | Production access for employees was temporarily limited, impacting operational efficiency. | Engaging third-party cybersecurity specialists and implementing enhanced security measures incurred financial costs. | Public disclosure of the incident and potential data exposure may have impacted CircleCI's reputation and customer trust. | Customers were required to rotate their secrets, tokens, and credentials.

The vulnerability in GitHub Actions allowed attackers to poison software pipelines, leading to the compilation of malicious code into downstream projects. Legit Security discovered and simulated this attack by injecting malicious versions of software components into the build process. Projects using GitHub Actions were heavily affected by this attack. This allowed stolen repository secrets and code tampering.

The vulnerability impacted many open-source projects using GitHub Actions. | GitHub took steps to address the issue, including API updates, to improve artifact trust verification and reduce the risk of similar attacks in the future.

The ua-parser-js NPM package, widely used to detect browser, engine, OS, CPU, and device types from User-Agent data, was compromised with a malicious script for approximately 4 hours on October 22, 2021. This NPM package has 8 M downloads every week and 1200 dependencies. Thus it posed a huge risk as it could install a coinminer and gather user credentials. GitHub and CISA issued advisories urging immediate upgrades and system reviews for suspicious activities.

Potentially compromised systems during the 4-hour window when the malicious package was available for download | User/credential information could have been harvested due to the malicious script | Advisories issued by CISA and GitHub to highlight the incident and to urge immediate action to fix it | Guidance issued by Rapid7 to review and remediate affected versions to identify malicious activity related to the incident

The Travis CI flaw impacted over 900,000 open source projects and 600,000 users, potentially exposing secrets like signing keys, access credentials, and API tokens. This vulnerability allowed attackers to access these sensitive environment variables during pull request builds, posing a significant security risk to thousands of organizations relying on Travis CI for their CI/CD processes. The flaw was tracked as CVE-2021-41077 and lasted for approximately eight days, during which researchers discovered and reported the bug to Travis CI. The incident highlighted the importance of secure handling and protection of environment variables in CI/CD pipelines.

Thousands of open source projects had their sensitive environment variables, including signing keys and access credentials, exposed. | The vulnerability posed a significant security risk, allowing potential abuse of exposed secrets for unauthorized access. | The developer community expressed frustration over Travis CI's handling of the vulnerability disclosure process and the inadequacy of the security bulletin. | As a precautionary measure, all projects relying on Travis CI were advised to rotate their secrets to mitigate potential risks.

The vulnerability posed a risk of a malicious Pull Request gaining access to the production environment via a GitHub repository. This vulnerability stemmed from allowing unapproved CI jobs to run on Teleport infrastructure for external contributors' PRs. The attack leveraged Kubernetes worker pods, pivoting to the node and exfiltrating credentials from the CI/CD system. This breach exposed critical AWS credentials, potentially enabling unauthorized access to alter release artifacts and cloud services.

The incident prompted Teleport to enhance its security incident response procedures, including mitigation, analysis, and remediation steps, to prevent future exploits and strengthen overall security posture. | Teleport advised customers to upgrade to newer versions (Teleport 4.4.11, 5.2.4, 6.2.12, or 7.1.1) to mitigate the vulnerability's risk and encouraged reviewing systems for signs of compromise or unauthorized access.

The Codecov supply chain breach involved attackers inserting a backdoor into Codecov's infrastructure, leading to the extraction of environment variables from Codecov's customers. This breach was significant as it allowed attackers to access sensitive information, including git credentials, from CI environments, potentially compromising private repositories and exposing secrets

Approximately 23,000 Codecov customers/users affected | Large organizations like Twilio, Hashicorp, Rapid7, Confluent reported being affected | Exposure of git credentials and access to private repositories | Potential exploitation of secrets and sensitive information

The vulnerability in the review-cask-pr GitHub Action enabled the security researcher to inject arbitrary code into a cask, bypassing the review process and causing automatic approval and merge of the pull request. This further allowed potential malicious code inclusion which could have resulted in a massive supply chain attack. The vulnerable GitHub Action was immediately removed by Homebrew and all pull requests thereon were reviewed and approved manually.

Homebrew took swift action by disabling and removing the vulnerable GitHub Action, ensuring the security of its repositories.

The SolarWinds hack involved the deployment of malicious code into SolarWinds' Orion IT monitoring and management software. This breach led to a massive supply chain incident, impacting over 30,000 public and private organizations, including government agencies like Homeland Security, State, Commerce, and Treasury. The hackers gained unauthorized access to networks, systems, and data, exploiting SolarWinds' privileged position as a widely used IT monitoring system provider.

Over 30,000 organizations compromised | Government departments affected, including Homeland Security, State, Commerce, and Treasury | Emails missing from government systems, evidence of data compromise | Identified malware infections and backdoor access | Ongoing investigation and uncertainty about the full extent of the breach

The security incident involved an unauthorized user escalating privileges, resulting in the exfiltration of source code and exposure of personal data of 184 users. The attacker spent days probing and navigating Stack Overflow's systems, exploiting vulnerabilities in access controls and misconfigurations to gain higher privileges, access source code repositories, and attempt database changes. The incident prompted Stack Overflow to implement immediate remediations and long-term security enhancements.

Personal data of 184 users was inadvertently exposed. | Source code was accessed and potentially tampered with. | The attacker elevated their access privileges, highlighting vulnerabilities in access control mechanisms. | The incident led to immediate security improvements such as moving systems behind firewalls, enhancing secret management, and implementing stricter access controls.