PHP Site AuditLaravel
What should Laravel teams check after a PHP security update?
Composer resolves Laravel and application libraries; the host, container image, or platform owner patches PHP itself. Confirm compatibility for the project’s Laravel release, test the runtime change in staging, and deploy using the established image or server process. Laravel specifically calls out reloading long-running queue workers, Reverb, and Octane after code deployment. Verify web requests and those background services separately.
Separate dependencies from runtime
A Laravel security maintenance has at least three layers to keep straight: Composer dependencies described by composer.json and composer.lock; the PHP interpreter and extensions in the runtime image or server; and long-running processes that may keep old code or runtime state loaded. Composer can update framework packages, but it does not patch the underlying PHP executable. Rebuilding a PHP image does not automatically update application dependencies or confirm that queue workers were replaced.
Check Laravel and PHP compatibility
Start with the Laravel documentation for the exact major version and check its server PHP and extension requirements. Review application and third-party package constraints before moving the runtime. The October PHP-core advisory describes upstream security releases, while a container base image or Linux vendor may carry its own package revision and patch evidence. Use the relevant vendor’s fixed-version guidance rather than assuming the displayed upstream version tells the whole story.
Exercise production-shaped staging
Build a staging image or runtime configuration with the intended PHP package and extensions, then install the application from its lock file using the same build pipeline as production. Exercise sign-in, the most important read and write routes, scheduled jobs, outbound integrations, and any code path that depends on an extension or changed PHP behavior. Review logs and health checks for startup warnings, worker crashes, failed database connections, or serialization errors.
Check queue, scheduler, and persistent services after rollout
A route that returns HTTP 200 only proves that a request path responded. It does not show that an asynchronous queue completed, that scheduled work ran, or that a process supervisor started a worker from the new image. Laravel’s deployment documentation says long-running queue workers, Reverb, and Octane should be reloaded or restarted after a new version is deployed, and a process monitor should bring reloadable processes back up when they exit. Follow your own platform’s supported lifecycle commands and confirm the new process identity or image.
Make acceptance evidence reviewable
For the ticket, capture the application commit and lock-file result separately from the runtime image digest or vendor package revision. Record which environments and worker pools were changed, the advisory reference, restart/replacement time, and health observations. Ask the platform owner to confirm web, queue, scheduler, and any Octane or Reverb processes use the intended runtime. If one pool cannot be confirmed, state that exact gap instead of describing the full service as patched.
The final acceptance check should name both success and limits: for example, the primary web route and login passed, queue test job completed, scheduler heartbeat arrived, but the secondary region has not yet returned an image inventory. External scanning can contribute public response evidence; it cannot read an image digest, inspect internal process pools, or prove the vendor package contains a particular patch.
For multi-region services, capture rollout status and health for each region and ensure the load balancer has stopped sending work to any old replica. If a process is restarted automatically by a supervisor, verify the replacement process belongs to the intended release. The owner can then distinguish a successful artifact rollout from a merely successful deployment command.
Common questions
Does composer update fix PHP itself?
No. Composer updates application libraries; the runtime provider or image maintainer owns the PHP interpreter.
Why restart Laravel workers after a runtime deployment?
Long-running processes can keep using the old code or runtime until the platform reloads or replaces them.
Is a successful health route enough?
It confirms one request path. Check queues, scheduler, Octane or Reverb and other production processes separately.