composer update re-solves composer.json, takes the newest versions allowed and rewrites the lock; run it deliberately, per package, and review the diff. composer install installs exactly what the lock names; CI, fresh clones and deploys run it (install --no-dev -o in production). The shop application pinned Monolog 21,402 to 3.10, widened the constraint, then took a vulnerable guzzlehttp/psr7 2.4.4, standing in for an old lock file:
composer require 'monolog/monolog:3.10.*'
composer outdated --direct
composer require 'monolog/monolog:^3.10'
composer require guzzlehttp/psr7:2.4.4 --no-blocking
composer audit --format=plain; echo "exit=$?"... monolog/monolog 3.10.0 ! 3.12.0 Sends your logs to files, sockets, inboxes, ... ... - Upgrading monolog/monolog (3.10.0 => 3.12.0) ... Found 5 security vulnerability advisories affecting 1 package: Package: guzzlehttp/psr7 Severity: medium Advisory ID: PKSA-vznr-tgp9-fd7d CVE: CVE-2026-59882 Title: guzzlehttp/psr7: Host Confusion via Weak URI Host Validation ... exit=1
--no-blocking was needed because since Composer 2.9 5,243 , update refuses versions with known advisories: without it the require failed ("not loaded, because they are affected by security advisories"), naming the policy.advisories settings of 2.10, which also blocks known malware at install. Old lock files still install, so run composer audit in CI, where exit status 1 fails the build. composer require 'guzzlehttp/psr7:^2.12.3' moved to 2.13.1 and a clean audit.