October 28, 2026 / Nirav Shah
Millions of production websites still run on PHP 5.6. It reached end-of-life in December 2018, which means it no longer receives official security patches yet replacing it is rarely something a business can do overnight. Legacy applications, custom extensions, and years of accumulated code turn a version jump into a project of its own. So what happens when a serious vulnerability is disclosed, and the official fix ships only for PHP 8.x? This is how we closed one such hole on a live PHP 5.6 site, while keeping the version exactly where it was.
Earlier this month a pair of related flaws were disclosed in PHP, together nicknamed “PHP2Shell” (tracked as CVE-2026-109618 and CVE-2026-109619). Both stem from the same root cause: when PHP runs out of memory in the middle of handling a request, it can stop halfway while its internal data is only partly built. What happens next is where the danger lies.
There are two faces to it. In the first, the cleanup code treats that half-built data as if it were complete and valid, and accesses it. In the second, memory that belonged to one request is freed, but internal pointers keep referring to it and because a single worker process serves many requests in a row, the next visitor’s request can end up reusing that stale data. In both cases a carefully crafted request can turn the resulting memory corruption into remote code execution: the attacker runs their own code on your server. That is the most serious category of web vulnerability there is.
The PHP project did the right thing and shipped a fix but only for versions that are still supported (8.5, 8.4, 8.3, 8.2), with the official advice being, as it usually is: upgrade.
Upgrading is the correct long-term move, and we never argue otherwise. But “upgrade now” and “stay safe now” are two different clocks. A mature application built against PHP 5.6 can depend on framework versions, extensions, and language behaviour that changed in later releases. Moving it to PHP 8 safely means testing every page, every integration, every edge case work that takes planning, not a single evening. Meanwhile the vulnerability is public, and the server is exposed.
End-of-life does not have to mean defenceless. It means the responsibility for the fix moves to you.
Rather than wait, we brought the fix to where the application already lived. The PHP team’s own patch changes a small, specific set of code paths — essentially, on an out-of-memory or overflow condition the engine now shuts the worker down cleanly instead of stumbling onward through half-initialised state, and the leftover pointers that enabled the cross-request reuse are cleared. We carried that same logic, faithfully, into the PHP 5.6 source and recompiled.
The guiding principle at every step was change nothing the application can see. The rebuilt PHP keeps the exact same compiled-in extensions and the same binary interface as the original, so every feature of the site behaves identically. The version number stays 5.6. Only the dangerous behaviour is gone.
Before — unsafe:
// out of memory mid-request: raise_error(...); jump_out(); // unwind a half-built request → cleanup runs over corrupt state
After — the backported fix:
// out of memory mid-request: log_fatal_error(...); _exit(1); // stop the worker cleanly — nothing half-built is reused
Alongside the code fix we added a layer of web-server hardening capping request sizes so the parser can’t be force-fed unbounded data, and recycling worker processes regularly so a single compromised process can’t linger. The code fix closes the hole; the hardening shrinks the attack surface around it.
A security patch you can’t demonstrate is just a hope. We built a behaviour test harness that reproduces the exact conditions the vulnerability needs, and ran it against the original and the patched build side by side.
What the tests confirmed the dangerous paths close; the ordinary ones don’t: On the patched build, an out-of-memory event exits the worker immediately instead of continuing over corrupt state; the cross-request leftover data is never written; and a flood of junk request headers is handled cleanly instead of crashing the process. At the same time, normal form submissions and file uploads worked exactly as before — no regression.
Production deployments are where good intentions meet real traffic, so the sequence mattered. We took a full server image backup first, giving us an instant rollback point. Because the rebuilt binary was a byte-for-byte compatible drop-in, going live was a straightforward swap followed by a brief service restart — seconds of downtime, scheduled and communicated in advance. We then re-ran the same before-and-after tests against the live server to confirm the fix was active, and watched the logs. The site came back exactly as it was, minus the vulnerability.
If your business depends on an older PHP stack and you’re unsure whether you’re exposed, this is exactly the kind of problem the Eternal web pvt ltd team solves assessment, targeted fixes, and a safe path to a modern version. Get in touch and we’ll take a look.
Nirav Shah is the Director of Eternal Web Pvt Ltd, an AWS Advanced Consulting Partner and certified Odoo Partner based in the UK. With over a decade of experience in cloud computing, digital transformation, and ERP implementation, Nirav helps enterprises adopt the right technology to solve complex business challenges. He specialises in AWS infrastructure, Odoo ERP, and web development solutions for businesses across the UK and beyond.
Have queries about your project idea or concept? Please drop in your project details to discuss with our AWS Global Cloud Infrastructure service specialists and consultants.
