The PHP that matters is the one inside the image, on the PATH the container process uses. The PHP on the build laptop is irrelevant.
Identify the runtime
Run the version command in a new container from the same digest you deployed: docker run –rm IMAGE php -v and, if FPM is the process, the php-fpm binary’s -v. Also record the base image tag and digest.
Change and verify
Rebuild the Dockerfile FROM a base that contains a fixed upstream release or a vendor package whose advisory you have read. Roll the containers. An in-place docker exec apt upgrade vanishes on the next start and is not a durable fix. Official library tags were not verified one by one in this review.
Treat a green health check as proof the process listens. Prove the PHP build separately with the package query or the binary version from inside the new instance. Legacy applications that cannot move off PHP 5.6 or 7.x still need a decision recorded in the pipeline, or the next bake will quietly keep the vulnerable base.
Questions
Does the cloud provider patch PHP inside my image?
Only if that provider manages the runtime. Your image, VM package, or platform stack is the thing to verify.