Composer vulnerability checker

What this checks

composer.lock lists the exact version of every package your project installs, in packages and packages-dev. We compare each version with the security advisories on Packagist. Packagist collects them from the GitHub Advisory Database and the FriendsOfPHP security advisories. A package shows up only when your installed version falls inside an advisory's affected range.

For each affected package you see the advisories, their severity where one is given, and the version that fixes them. When several advisories apply, we work out the lowest version that is outside all of them.

What composer audit is

composer audit is a command built into Composer 2.4 and later. It reads your composer.lock and checks it against the same Packagist advisory data. It runs on your machine and needs no account. This page gives you the same answer when you only have the lock file, or when you want a readable list to share with a client or a team.

How to run composer audit yourself

Open a terminal in the project folder, the one with composer.json in it, and run:

composer audit

Useful options:

# only the packages your site runs in production
composer audit --no-dev

# machine-readable output, for CI
composer audit --format=json

# check the lock file without installing anything
composer audit --locked

If Composer says the command does not exist, update Composer itself with composer self-update. composer audit exits with a non-zero code when it finds advisories, so you can add it to a CI pipeline and fail the build.

What to do with the results

1. Start with what runs in production. Packages from packages-dev (test tools, debuggers) usually never reach your live server. Check that they really don't.
2. Read the advisory. Many only matter if you use a certain feature, such as a specific file upload or cache driver. The link takes you to the source.
3. Update inside your major version first. composer update vendor/package --with-dependencies gets the newest version your composer.json allows. Most projects ship fixes for older release lines too.
4. If the fix needs a new major version, plan it as an upgrade: read the upgrade guide, run your tests, and deploy it on its own.
5. Run composer audit again and commit the new composer.lock.

Limits

A clean result means none of your installed versions match a published advisory today. It does not check your own code, your server, private packages or anything that has not been reported. Development branches such as dev-main have no version number, so we list them as not checked.

Questions

Related

• Security advisories for popular PHP packages, with a version check for each one
• Is laravel/framework vulnerable?
• Free hacked-site scan