Website Security Risk: Removing PHP

In October 2026 two critical flaws were found in PHP, the language behind a large share of the web, including the shop software that ran the alphaZ documents store and the content management system that ran this blog and the knowledge base. The flaws, which became known as PHP2Shell, let an attacker take control of a web server without a password. Nothing on our sites was breached. As a precaution, the store was taken offline the next day and its database removed from the server. What came next was decided the way any significant website security risk should be: as a risk assessment.

Website Security Risk and the Hierarchy of Control

The first question was who controlled the risk. Not us, and not anyone else running PHP. Closing the flaw depended on others publishing fixes and on every layer of the site being updated in time, and the same would be true of the next flaw and the one after it. For a site holding customer account details, a control that relies on someone else acting quickly, every time, wasn't acceptable.

Health and safety managers know the hierarchy of control: eliminate the hazard where you can, and reduce it only where you can't. Patching is a reduction. It holds until the next flaw is announced, and it needs someone watching for that announcement for as long as the site runs. Elimination was available, so we took it. The alphaZ store was rebuilt the same day as plain static web pages, with no shop software, no customer logins and no database on the website. isoassured.co.uk went through the same change, and the knowledge base and this blog have since followed.

Website Security Risk and Holding Less Data

A website can't lose data it doesn't hold. Card payments go through Stripe, so card details never reach our website. The alphaZ subscriber library holds one thing about each subscriber: their email address. There are no passwords either. Subscribers log in with that email address and a six-digit code sent to it, so there is no password store to steal and no password for anyone to forget or reuse on another site. That is data minimisation built into how the site works, rather than written into a policy afterwards.

A Faster Site After the Website Security Rebuild

Eliminating the risk also brought improvements that patching never would. Pages load faster. The alphaZ documents have their own document search, separate from the article search, and each says what it searches. Every page kept its address, so links in documents, emails and search results still work. Subscribers download from the alphaZ subscriber library, organised by document type and toolkit with its own search, and new and updated documents appear there within minutes of release. The subscription has changed too, with everything on the site now in one alphaZ subscription.

Website Security Risk Assessment for Your Organisation

Most organisations don't need to rebuild their website, but every organisation with one should be able to answer three questions. Who keeps the software on it up to date? What personal data does it hold, and does it need to? If a flaw like PHP2Shell were announced tomorrow, could the site come down without stopping the business? If the answers are nobody, more than it needs and no, that is a significant risk, and it belongs on the risk register with a named owner. For organisations certified to ISO 27001 it also falls under technical vulnerability management, a control an auditor will expect to see owned rather than assumed.

Information Security Knowledge Base

Malware Protection, Anti-Virus and Patch Management

RA-BR8 Cyber Attack Risk Assessment

PP-8-07 Technical Vulnerability Management Policy Procedure

Published: 30 October 2026