Key points
Hour by hour, how the Life Future engineers handled PHP2Shell (CVE-2026-109618 and CVE-2026-109619): images rebuilt, old version kept, versions checked.
On 20 October 2026 two critical flaws in the core of PHP were announced under the name PHP2Shell. We run PHP in several systems, so the question was simple: how fast does everything end up on a fixed version? This post records the answer with dates and times, as it happened.
What PHP2Shell is
PHP2Shell is the name for two flaws, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4 9.2. The flaws sit in the PHP engine itself, not in application code, so a site with clean code is affected too. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (Help Net Security).
Researchers judge that the flaws can lead to remote command execution. Sansec is more cautious: a real attack needs knowledge of the target server and specific conditions, so mass exploitation is less likely. We did not weigh that. The only sensible answer to a flaw in the PHP engine is to replace PHP.
Hour by hour
All times are WIB (UTC+7).
- 20 October: PHP2Shell is announced.
- 21 October, 22:49: the fixed PHP 8.5.12 and 8.4.27 builds are available, and we pull the base images to the server.
- 22 October, 00:26: our ERP images are rebuilt on the patched PHP.
- 22 October, 00:35: the first ERP services are switched one by one to the new image. That is 1 hour 46 minutes after the builds were available.
- 22 October: Atlas is updated in the same window.
- 23 October, 17:45: the second ERP follows onto the patched image.
The second ERP followed later. We record it as it happened so the sequence stays honest.
Five patching steps
1. Rebuild the images. We do not patch in place. Every image is rebuilt on the fixed PHP, so the result is repeatable and does not depend on manual changes on a server.
2. Keep the old version. Before anything is replaced, the old image is tagged and kept.
3. Switch services one by one. Services are replaced in stages, not all at once. If one service misbehaves, the others keep running and the way back to the old version stays open.
4. Check the version in every container. We do not trust the deploy record alone. The PHP version is read from inside the running container.
5. The old version becomes test material. The old image is not thrown away. The reason is in the next section.
Why we keep the old version on purpose
The old version has two jobs. The first is obvious: a rollback backup, in case the new version breaks something. The second is less common: we use it as a sample for security testing and for practising how to close the flaw.
That vulnerable old version serves no visitors and does not run in production. It is only kept as an image, and run separately when we use it for tests.
What runs now
The result of checking inside the containers: the first and second ERP and Atlas run PHP 8.5.12. The third ERP is on the PHP 8.4 line and runs 8.4.27. All four are on a version that contains the fix.
What we do not claim
This is a patching record, not an incident audit report. We do not write that we found or did not find signs of an attack, because that is not what is recorded here. Raising the PHP version also does not replace the other layers: input checks, access limits and monitoring keep running as usual.
What we can promise is simple: once a fix exists, we raise the version within hours, check it directly, and keep a way back.