Fix guide · low · exposed_composer_lock

PHP composer.lock file exposed

Why it matters

composer.lock pins exact versions of every PHP dependency, including transitive ones. The file is normally meant to be committed to source control (so all developers and deploy environments use the same versions), but should not be served publicly.

What the attacker gets:

• Exact versions of every package. Cross-referencing against the GitHub Advisory Database, Packagist Security Advisories, or commercial tooling like Snyk's database tells them which known CVEs apply to your stack.
• Hash values of each package. Useful for verifying which specific build of a package is running (and whether it's a tampered fork).
• Author email addresses for some packages (when require blocks reference forks).

This isn't a credential leak. It's reconnaissance — an attacker who finds a known CVE in a package you're running has confirmed exploit path without trial-and-error.

How to fix it

1. Block composer.lock at the web server. It should never be reachable.
2. Keep dependencies up to date. Run composer update on a schedule, prioritise security advisories.
3. For server-rendered PHP apps, ensure public/ is the web root and composer.lock lives outside it. The default Laravel/Symfony layout already does this.
4. Add a CVE-monitoring step to CI. composer audit (built into Composer 2.4+) checks your installed packages against known advisories.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.