Financial Services
Five Sites Rebuilt on Patched AWS Servers in Under an Hour After PHP2Shell
UK Specialist Lender
Under 1 hour
To migrate five sites to fresh, patched AWS servers
When the critical PHP2Shell vulnerabilities were disclosed, we used our agentic tooling to move a UK lender's five sites onto fresh, patched AWS servers in under an hour.
The Challenge
In October 2026, details of two critical flaws in PHP itself leaked ahead of their planned disclosure. Known together as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), both were rated 9.2 under CVSS v4.0 and could allow unauthenticated remote code execution with the privileges of the web server.
Because the flaws sat in the PHP engine rather than in any application, every PHP site was exposed, however well its own code was written. Exploitation attempts were reported before the patches shipped, and the PHP maintainers were clear that updating was the only safe option.
Our client, a UK specialist lender, ran five PHP sites. As a regulated financial business, they could not leave those sites exposed while they waited for a fix, and could not afford a slow, manual recovery once it arrived.
Our Solution
Closing the Gap Before the Patch
There was a delay between the first exploits and the patched PHP release. Rather than leave the sites running on vulnerable PHP in the meantime, we replaced them with static placeholders. With no PHP running, there was nothing for PHP2Shell to attack, and visitors still saw a holding page rather than an error.
A Clean Rebuild, Not a Patch
When the patch shipped, we didn't just update PHP on the existing servers. Because exploits were circulating before the fix, we couldn't be certain the old machines were clean. So we rebuilt: all five sites moved onto fresh servers on AWS running patched PHP, leaving nothing behind that an attacker could have touched.
Human in the Lead
We ran the migration with our own agentic tooling. AI agents carried out the provisioning, configuration and migration work for each site, so the five migrations ran together rather than one after another.
Our engineers were in the lead, not stuck in the loop. They set the plan, made the decisions and owned every change that went live, without becoming a bottleneck for each routine step. The agents did the work; people stayed in charge of it.
Results
- No PHP exposed while the client waited for a patch, thanks to static placeholders
- Five sites rebuilt on fresh, patched AWS servers
- Under an hour to migrate all five once the patch was available
- Clean infrastructure with no carry-over from the previously exposed servers
Why It Matters
Critical vulnerabilities do not wait for a convenient maintenance window. With agentic tooling led by engineers who understand what it is doing, a response that would once have taken days can be done safely within the hour.