Morocco Next Technologies (MNT) · 21/10/2026 · PHP2Shell · CVE-2026-109618 · CVE-2026-109619
On October 21, 2026, two critical PHP runtime vulnerabilities, CVE-2026-109618 and CVE-2026-109619, prompted the release of security patches. Under certain conditions, they may expose web applications to unauthenticated remote code execution.
At Morocco Next Technologies (MNT), our recommended response is practical: identify exposed systems, deploy verified fixes and confirm that production services actually run patched software. This guide covers Linux VPS hosting and containerized infrastructure.
Understanding the risk
Both issues affect PHP’s internal memory handling. Even a well-maintained Laravel, Symfony or WordPress application can remain at risk when the underlying PHP runtime is vulnerable.
The first upstream fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Linux distributions may backport patches, so consult your vendor’s security bulletin rather than relying on the version string alone.
1. Patching PHP on a Linux VPS
On Ubuntu or Debian, inspect the CLI version, active PHP-FPM services and web-server configuration. More than one PHP version may be installed on the same machine.
After taking backups and confirming patched packages are available in configured repositories, upgrade the relevant packages and restart PHP-FPM. Also check extensions, HTTP responses and logs.
- php -v
- systemctl list-units --type=service --all | grep php
- sudo apt update
- apt-cache policy php8.3-fpm php8.3-cli
- sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
- sudo systemctl restart php8.3-fpm
- sudo systemctl status php8.3-fpm
2. Rebuilding Docker and Docker Compose images
The PHP runtime inside a container is separate from the host. Updating the VPS does not patch an existing Docker image. Inspect the container, rebuild it with a patched base image and redeploy it.
The FROM directive below is only an illustrative base-image selection, not a complete production Dockerfile. Validate image availability, extensions and application compatibility first.
- docker ps
- docker exec NOM_CONTENEUR php -v
- FROM php:8.3.36-fpm-alpine
- docker build --pull --no-cache -t mon-application:php2shell-fixed .
- docker run --rm mon-application:php2shell-fixed php -v
- docker compose build --pull
- docker compose up -d
3. Rolling out fixes across Docker Swarm
Publish the patched image to a registry reachable by Swarm nodes, then update each affected service. A controlled rolling update may help reduce downtime where the deployment architecture supports it.
Inspect all replicas, service logs and health checks. Rolling back to a vulnerable image is not a security fix and should be treated as an exceptional availability measure.
- docker service ls
- docker service ps NOM_SERVICE --no-trunc
- docker service update --image registry.example.com/app:php2shell-fixed --update-parallelism 1 --update-delay 10s --update-order start-first --update-failure-action rollback NOM_SERVICE
- docker service ps NOM_SERVICE --no-trunc
4. Updating Kubernetes workloads
Identify PHP workloads, publish the corrected image and update the affected Deployments. The commands below assume a production namespace and a container named php; adapt them to your cluster.
If Helm, Argo CD or Flux manages these workloads, update the declarative configuration to prevent reconciliation from restoring the vulnerable image. Check every running Pod and its effective runtime.
- kubectl get pods -A
- kubectl -n production set image deployment/mon-application php=registry.example.com/php-app:php2shell-fixed
- kubectl -n production rollout status deployment/mon-application
- kubectl -n production get pods -o wide
Validate and monitor after patching
A successful command does not prove remediation. Verify the running versions, application availability, HTTP errors, system logs and anomalous activity.
If compromise is suspected, isolate affected systems, preserve evidence, investigate access patterns and rotate exposed secrets. Temporary filtering controls are not equivalent to a security patch.
MNT’s perspective
PHP2Shell highlights the importance of accurate inventories of runtimes, container images and dependencies, supported by CI/CD pipelines that include security checks.
Our recommendation is to act promptly but methodically: identify exposure, deploy the appropriate patches and record verification for each production instance.
Morocco Next Technologies — Digital solutions built around your challenges, designed to inspire lasting trust.