PHP2Shell Remediation: PHP 7.4 to 8.3 Migration in One Day

A multi-tenant B2B SaaS platform depended on two production API stacks in the same AWS EKS Kubernetes cluster. The legacy stack ran PHP 7.4.33 with Symfony 5.2; the newer stack ran PHP 8.1 with Symfony 6.4 LTS. Each served a main hostname and two dedicated tenant hostnames.

The PHP2Shell disclosure made the runtime upgrade urgent. The client needed a practical route away from unsupported PHP without turning an emergency security update into a full application rewrite. The project addressed runtime exposure; it did not claim to resolve every application security issue.

Move all six production hostnames onto PHP 8.3.36, retain the existing microservice routes, limit disruption and preserve a fast rollback path. Avoid permanent additional Kubernetes workloads or CPU reservations.

The application also needed dependency compatibility checks, a normal development-to-production release path and explicit follow-up work for issues outside the urgent runtime cutover.

The two application branches had diverged by 49 commits unique to the newer branch and 18 unique to the legacy branch. Updating the older Symfony application in place would require broader compatibility changes; a trial cherry-pick conflicted in every file it touched.

A separate deployment based on the newer code was built and deployed, but would duplicate workloads and reserve about 2.5 additional vCPU. Cluster nodes already had 82–94% of CPU capacity reserved, even though actual use was much lower.

The deciding discovery was that the stacks used the same database and signing keys. After checking this shared foundation, the team could reuse the existing newer application pods rather than keep a third deployment.

Actinode split the work into two stages: upgrade the newer stack to the patched PHP runtime, then move legacy hostnames onto that stack through Kubernetes Ingress changes.

PHP 8.3.36 was the chosen security release for this environment, rather than a claim that every application should use the same version. The PHP2Shell vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Runtime patching and application migration were treated as related but distinct work.

The legacy pods stayed running during the cutover so the team could restore the previous routing if needed. Only the root application backend changed; the existing microservice routes remained in place.

The fastest workable legacy migration came from understanding the existing systems before adding infrastructure. A shared database and compatible authentication foundation allowed Actinode to upgrade one stack and redirect legacy traffic through small, reversible routing changes. That decision was specific to this application and required validation; it is not a universal shortcut for migrating independent systems.

The delivery account records outstanding work: reconcile three legacy-only fixes, change the rollout strategy for single-replica tenant deployments, commit the legacy Ingress definitions to source control, remove temporary alternative workloads, and retire old pods after a stable period.

A further framework upgrade and remediation of 67 Composer security advisories across 21 packages remained on the backlog. Completing the PHP runtime upgrade did not mean the application was free of other security issues.