Free tool · no signup
Composer audit online: scan composer.lock
Paste your composer.lock, or drop the file in. You get every known vulnerability in the PHP packages you depend on, with the version that fixes each one.
By the Bug Circuit security team · Last updated
Free, no signup. Your file is read in your browser. Only package names and versions are sent to osv.dev, the open vulnerability database run by Google, to look up known advisories. No code, paths or registry addresses leave your device.
How it works
How the audit works
composer.lock records the exact version of every package your PHP project installed, including packages in require-dev. The tool reads that file in your browser and builds a list of package names and versions. Development branches such as dev-main are skipped, because they are not tagged releases.
It asks OSV (osv.dev), the open vulnerability database run by Google, which of those versions have published advisories in the Packagist ecosystem. Only the names and version numbers are sent. Your file, your code and your repository address stay on your device. For each advisory the tool reads the details and works out the fixed version for the release line you are on, since an advisory usually lists a separate fix for each line, for example one for Laravel 8 and another for Laravel 9.
The report groups the results by package and sorts them by severity, with the GHSA and CVE identifiers so you can read the full text. This is the same job composer audit does on your machine. The online version needs no install, which helps when you review a project or a client site that is not on your machine.
What to do with the result
Fix the critical and high items that are not development-only first. For each affected package run composer update vendor/package, aiming for the Fixed in version, and add --with-dependencies if Composer asks. Then run composer audit, test the app and commit the new composer.lock. Deploy with composer install so production gets exactly what you tested. Composer also marks a package as abandoned when its maintainers say it is no longer developed, and composer audit lists those too. They are worth replacing, because an abandoned package gets no fixes however many flaws are found in it later.
An advisory is a published flaw, not proof that your site is open to it. Whether it matters depends on which features you use. Keep the identifiers, read the advisory, and add composer audit to your CI so a new advisory fails a build instead of waiting for someone to look.
Worked examples
An old Laravel project
Lockfile with laravel/framework 8.40.0, symfony/http-kernel 5.4.0 and monolog/monolog 3.5.0
2 of 3 packages have advisories: 7 in total (1 critical, 1 high). laravel/framework 8.40.0: 6. symfony/http-kernel 5.4.0: 1. monolog/monolog 3.5.0: none.
Result on 24 Oct 2026. An old framework version collects advisories as they are published.
A clean lockfile
A lockfile where every package is current
No known advisories in 96 packages.
A clean result means nothing is published yet. Check again after each release and in CI.
A lockfile with development branches
A package locked to dev-main
1 entry skipped: not a tagged release.
Branches have no version number to match, so audit those by hand.
Frequently asked questions
Is my composer.lock uploaded anywhere?
How is this different from composer audit?
Does it check PHP itself?
Why are some packages skipped?
Do development dependencies matter?
The fixed version is a new major version. What should I do?
Is there a size limit?
Keep reading
See what attackers see, for free
Run the free passive check on your website. No login, no impact on your site, results in seconds.
Ready for the full manual audit? See pricing