Supply Chain Attack Flags 700+ GitHub Repos With Hidden Linux Payload

A new software supply chain attack has exposed developers to a hidden Linux payload planted inside package install flows, with more than 700 GitHub results tied to the same attacker infrastructure and eight Packagist packages confirmed infected.

The clearest confirmed cases came from Packagist packages carrying a malicious postinstall hook. The affected set included PHP projects, but the attacker hid the dangerous command in package.json rather than composer.json, making it easier to miss during a normal PHP dependency review.

The install hook downloaded a Linux binary from a GitHub release, saved it under /tmp/.sshd, made it executable and ran it in the background. The filename looked close to a normal system component, while the command skipped TLS certificate verification and suppressed error output. That combination points to a payload built for silent execution during dependency installation rather than ordinary package behavior.

The confirmed affected Packagist packages included devdojo/wave, devdojo/genesis, katanaui/katana, elitedevsquad/sidecar-laravel, r2luna/brain, baskarcm/tzi-chat-ui, moritz-sauer-13/silverstripe-cms-theme and crosiersource/crosierlib-base. The practical risk is highest around popular templates such as DevDojo Wave, which has roughly 6,400 GitHub stars, and DevDojo Genesis, which has about 9,100 Packagist installs.

GitHub searches also showed hundreds of public results connected to the same attacker account and payload references. Those results should not all be treated as confirmed unique compromises because forks, cached files and duplicate artifacts can inflate the count. The confirmed Packagist infections remain the strongest evidence, while the broader GitHub footprint shows the campaign may have reached well beyond the first eight packages.

CI/CD Pipelines Also Faced Exposure

The same payload also appeared inside GitHub Actions workflows under a fake step labeled “Dependency Cache Sync,” creating risk for automated build environments as well as local developer machines. CI/CD exposure is often more dangerous because build servers can hold deployment tokens, cloud credentials, signing keys, package registry tokens and production secrets.

That is why this campaign matters beyond ordinary malware cleanup. Crypto teams, exchanges, DeFi protocols, wallet projects and infrastructure providers often rely on open-source packages and automated build pipelines. A malicious install hook that executes during dependency setup can expose wallet tooling, API keys, deploy keys, npm or GitHub tokens and cloud credentials before the team realizes a package was compromised.

CryptoAdventure recently covered a similar developer-risk pattern when a Bitwarden CLI supply chain attack put crypto wallet keys at risk. The common thread is not the brand of the affected tool. It is the attack path: compromise software that developers trust, trigger execution during normal installation or build steps, then harvest secrets from systems that sit close to production infrastructure.

Package-level risks have also affected crypto ecosystems directly. A recent XRPL library flaw forced a patch after a serious open-source dependency issue, showing how developer tooling and package security can quickly become protocol-adjacent risk.

Developer Cleanup Starts With Secrets

The main indicators of compromise include the GitHub account parikhpreyash4, the repository systemd-network-helper-aa5c751f, the hidden drop path /tmp/.sshd, and command fragments such as curl -skL, chmod +x /tmp/.sshd and /tmp/.sshd &. Teams should search local machines, CI runners and build logs for those indicators, especially if they installed affected development branches such as dev-main, dev-master or 3.x-dev.

Packagist removed the bad packages, but development branches can still create risk if the upstream GitHub repositories remain infected or if build systems pull fresh code automatically. Teams using affected packages should pin safe versions, clear dependency caches, review GitHub Actions workflows, inspect package.json scripts, rotate exposed credentials and rebuild compromised runners from clean images.

Secret rotation is the most urgent step for any environment that ran the malicious hook. That includes GitHub tokens, package registry keys, SSH keys, cloud credentials, deployment secrets, exchange API keys and wallet-adjacent automation credentials. Removing the package alone does not protect a team if the payload already ran and copied secrets elsewhere.

The attack has not been publicly tied to a confirmed crypto theft so far, but the risk path is direct for any team building wallet software, trading infrastructure, DeFi apps or exchange integrations. A hidden install script in a trusted template can reach developer systems before production monitoring ever sees suspicious activity. The safest response is to treat affected installs and CI jobs as exposed until logs, runners, credentials and dependency paths are fully reviewed.

The post Supply Chain Attack Flags 700+ GitHub Repos With Hidden Linux Payload appeared first on Crypto Adventure.