26 October, 2026
In short: PHP2shell was considered as a critical event leading to extremely high risk. Handling php2shell was mainly about having prepared for this. Codific patched all the affected assets within 1.5 hours of patches becoming available. In a post-patching forensic analysis we found no evidence of an attack.
Last week PHP disclosed two AI-flagged vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Known as “php2shell”, they allow unauthenticated remote code execution. In plain language: attackers can easily abuse them to take full control of the server a PHP application runs on.
Several Codific applications run on PHP, so this was an extremely high-risk event. Below is what we did, and when.
Timeline at a glance
What we did
Early warning. Our threat intelligence process tracks upcoming patches. We learned about the CVEs late on 20 October, before full disclosure, and scheduled preparation and patching for the next morning.
Ready to patch. Our build and deploy process is fully automated. Once a patch exists, we rebuild every container running a PHP image and deploy it. For our WordPress sites we update to the official WordPress image from Docker Hub.
Customers warned. Forecasts said exploitation would start within 15 minutes of the patch. A full build and deploy takes us about 45 minutes. We therefore triggered our emergency communication protocol and told all customers to expect possible downtime.
A risk-based decision. Around 11:00–12:00 UTC on 21 October, reports came in that exploitation might already have started, with no patch available yet. Every Codific application has a risk profile:
- Confidentiality and integrity first: taken offline until patched.
- Availability first: kept online, accepting a small risk.
Waiting for images. PHP released the patch earlier than expected. The patched base container images we depend on took several more hours to arrive. By then php2shell was world news, so we did not send further updates.
Patched. The base images became available around 18:00 UTC (20:00 in Brussels, 14:00 in New York). We ran our build and deploy scripts immediately, and we have patched all systems by 19:00–19:30 UTC, followed by initial checks.
Verified. On the morning of 22 October we went through a systematic checklist on every server to confirm the patch. We also analysed three months of logs, as far back as we keep them, for signs of exploitation. We found none.
Follow-up fix. On 23 October PHP published an additional advisory: a specific configuration could still allow exploitation, though less likely. The fix was a PHP configuration change, needing no downtime. We rolled it out to all systems within one hour.
Conclusion
Each of the two fixes took us at most 1.5 hours once it could be applied. The asset inventory, automated pipeline, communication protocol and risk profiles all worked as intended. Our team is prepared for the next event of this kind.
