The PHP attack that proved no ecosystem is safe

For years, every major supply chain incident in npm reopened the same joke among developers: maybe it was time to go back to PHP. The problem is that modern software security no longer depends on a specific language. It depends on how we install dependencies, how much we trust external maintainers, how we run automatic scripts, and how we protect the tokens that power our development workflows. The latest attack against packages in the Laravel-Lang ecosystem has made that clear.

The campaign affected community packages used in Laravel applications, including laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and laravel-lang/actions. According to Socket, the compromise introduced remote code execution backdoors into more than 700 historical versions. StepSecurity, meanwhile, documented that the attacker rewrote Git tags in several repositories within a very short time window, meaning new installs or updates could end up downloading malicious code without developers noticing anything unusual.

A particularly dangerous attack because of how it was triggered

The case is serious because this was not an unknown package uploaded to a registry with a name similar to a popular one. The attack affected legitimate packages maintained by the Laravel-Lang community. It is important to clarify that they were not part of the official Laravel framework, but they were real dependencies used by PHP projects for internationalisation and related utilities.

The technique was especially damaging because of its integration with Composer. The malicious commits added a src/helpers.php file to the autoload.files map. In practice, this meant that loading Composer’s autoloader, something many PHP applications routinely do at startup, could execute the payload. The user did not need to manually run a suspicious binary or invoke a strange function. Installing or updating a compromised dependency and loading the application was enough.

Aikido described the attack as credential theft. The payload retrieved content from the flipboxstudio.info domain, deployed components into temporary directories and attempted to collect secrets from the environment. Among the data of interest were cloud credentials, CI/CD variables, tokens, SSH keys, Kubernetes information, Vault data, browser data and password manager information. The malware then attempted to erase traces to make forensic analysis harder.

The attack also had a feature that makes it especially worrying for security teams: it was not limited to publishing a new malicious version. In several cases, the attacker manipulated historical tags. That breaks a comfortable assumption: thinking that an old, known and apparently stable version is necessarily safe if the resolution system depends on mutable references.

Composer, npm, PyPI and crates.io: the problem is systemic

The Laravel-Lang incident is not an isolated anecdote from the PHP world. It is part of a much wider trend. The automation that made modern development possible has also become a highway for malware. We install hundreds of dependencies, allow build tools to execute code, grant access to repositories, publish artefacts automatically and use tokens with too many permissions in CI/CD environments.

The material provided for this article sums it up well: the debate can no longer be reduced to “this only happens in JavaScript”. In recent months, there have been campaigns against npm, PyPI and crates.io, as well as attacks against developer extensions, GitHub Actions workflows and seemingly harmless packages designed to steal wallets, SSH keys, AWS credentials or GitHub tokens.

Okta has described TeamPCP as a financially motivated actor that, since late 2025, has used rapid deployment tools and practices as mechanisms to distribute malware. Its goal is usually not to destroy code, but to steal secrets: package registry tokens, cloud credentials, SSH keys, personal tokens and anything valuable found in a development or continuous integration environment.

The pattern repeats because it works. A compromised package can enter through an apparently normal update. An installation hook can execute without attracting much attention. A misconfigured workflow can exfiltrate secrets. A maintainer can fall for phishing. An IDE extension can access files, terminals and credentials. And when the attacker obtains a valid token, they can publish new versions, manipulate repositories or move into other systems.

npm is reviewing one of the most debated points: the automatic execution of installation scripts such as preinstall, install and postinstall. The proposal to make these scripts require explicit approval targets the core of many recent attacks. For years, executing code during installation was accepted as a technical convenience. Today, it is increasingly seen as too dangerous a default.

What teams can do before the next incident

The answer is not to abandon PHP, JavaScript, Python or Rust. Nor is it to stop using open source. That would be unfeasible and, in many cases, counterproductive. The solution is to assume that package registries are part of the attack surface and treat them with the same rigour as an internet-facing API.

The first measure is to pin dependencies in a verifiable way. In critical environments, pointing to a mutable tag is not enough. Whenever possible, teams should use hashes, reviewed lockfiles and signatures. In GitHub Actions, pinning by SHA reduces the risk that a rewritten tag points to different code. In Composer, npm, PyPI or crates.io, teams must know exactly which versions were installed, when and in which environment.

The second is to apply least privilege to tokens. Many supply chain attacks become worse because CI environments contain secrets that are too broad: cloud keys with excessive permissions, GitHub tokens with global access, reused publishing credentials or secrets available in jobs that do not need them. Every token should have limited scope, expiry, rotation and traceability.

The third is to review installation scripts and dependency changes. A package that introduces a postinstall, a new binary, network calls, environment variable reads or access to sensitive directories deserves an alert. Not everything is malicious, but it should be treated as a risk-related change.

The fourth is to maintain an inventory. An SBOM helps teams respond quickly when an incident appears: which projects used the package, which version entered, whether it reached production, which secrets were available and what needs to be rotated. Without an inventory, response becomes a manual search under pressure.

It is also worth introducing a reasonable waiting strategy for non-critical updates. Okta notes that many campaigns against popular packages are detected quickly; a policy of not installing every newly published version immediately can reduce exposure. This is not about delaying security patches, but about distinguishing between urgent security updates and routine upgrades that can wait a few hours or days.

The supply chain is already production

The Laravel-Lang attack teaches something many companies have not yet internalised: the development environment is production for the attacker. That is where tokens, keys, repositories, pipelines, cloud credentials and deployment permissions live. Compromising a dependency can be more profitable than attacking a production application directly.

That is why supply chain security cannot be left to an occasional review. It must become part of the daily workflow: SCA, blocking suspicious packages, reviewing maintainers, verifying signatures, secret scanning, CI/CD hardening, IDE extension control and behaviour monitoring during installation. Tools such as Socket, Snyk, Aikido, StepSecurity Harden-Runner, GitGuardian and GitHub’s own native controls can help, but none of them replaces secure architecture.

The industry has trusted a dangerous idea for too long: that installing dependencies is an administrative, almost mechanical operation. It is not anymore. Every composer update, every npm install, every PyPI package and every Rust crate can introduce code with access to the development environment. Most of the time nothing happens. But when it does, the impact can spread in minutes.

The PHP attack nobody saw coming is not just a warning for Laravel developers. It is a reminder for the entire industry: modern software is built on delegated trust, and that trust needs technical controls. Open source is not broken. What is broken is continuing to treat its distribution chain as if it were not a priority target.

Frequently asked questions

Which PHP packages were affected?
The attack affected community Laravel-Lang packages, including laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and laravel-lang/actions. They were not part of the official Laravel framework.

How was the malware triggered?
The malicious code was added to Composer’s autoload mechanism through autoload.files. When vendor/autoload.php was loaded, the application could execute the payload automatically.

What did the attack steal?
According to published analyses, the malware looked for cloud credentials, CI/CD tokens, SSH keys, Kubernetes data, Vault information, browser data and other secrets from the environment.

How can a development team protect itself?
By pinning versions with hashes, reviewing installation scripts, using least-privilege tokens, maintaining SBOMs, hardening CI/CD, scanning dependencies and avoiding updates to critical packages without a minimum verification window.

Sources:
Socket, analysis of the Laravel-Lang compromise and more than 700 affected versions.
StepSecurity, technical analysis of tag rewriting, Composer autoload and secret exfiltration.
Aikido, analysis of the credential stealer and compromise domains.
Okta, recommendations against TeamPCP attacks and CI/CD risks.
npm RFC on explicit approval for installation scripts.
Provided transcript on attacks against PHP, Composer, npm, PyPI and crates.io.