If a critical PHP flaw is reported, find out which PHP versions you run, read the official advisory and install the fixed release. Restrict access to any site you cannot patch straight away, then check it for signs of compromise.
UK search trends show strong interest in a critical security issue affecting PHP. The searches link it to PHP websites going offline and to Edinburgh council. The vulnerability itself is not known at the time of writing: which versions are affected, how it is exploited and whether a fix exists. The search terms also do not show why the council’s sites went down. This guide covers how a site owner can respond to any serious PHP alert.
Gather what you need before starting
You need administrative access to every server or hosting account that runs PHP. That means shell access where you have it, or the hosting control panel where you do not. Make a list of every website and application you are responsible for, including staging copies, old microsites and forgotten admin tools. These are the sites most often missed.
You also need a recent backup that you know you can restore, and a way to tell users if you take a service offline. If you use managed hosting, have your provider’s support contact and status page ready. In that case the provider usually controls the PHP version, not you.
Identify every PHP version in use
Run php -v on the command line to see the version installed on a server. Remember that a web server can use a different PHP binary from the one the shell uses. To see what a site actually runs, check the PHP-FPM pool configuration or the hosting control panel. You can also briefly put up a page that calls phpinfo() on a non-public address, then delete it straight away.
Write down the full version number for each site, not just the major release. Security advisories usually name exact patch levels. Also note the operating system packages. Linux distributions often backport security fixes into their own builds, so their version string can look older than the fixed upstream release even when the fix is in.
Read the official advisory carefully
Go to the primary sources: the PHP project’s release announcements, the security bulletins from your Linux distribution, and the National Cyber Security Centre for UK organisations. A widely reported issue can turn out to be in PHP itself, in a common extension, in a popular framework, or in an application built with PHP, such as a content management system. Each needs a different fix.
Check whether the flaw depends on a particular setup, such as a specific server mode, operating system or enabled extension. Many PHP vulnerabilities only matter under certain conditions. Knowing these lets you decide whether a site needs emergency action or can wait for routine maintenance.
Restrict exposure while you prepare a fix
If a site is affected and you cannot patch it straight away, reduce its exposure. You can put it behind a maintenance page, limit access by IP address or move it behind authentication. If the advisory publishes mitigation rules, a web application firewall can block the known attack patterns.
Taking a public service offline is disruptive, but it is sometimes the safer choice. The search activity suggests some site owners are doing exactly that, although the reasons in each case are not known. Tell users plainly what is unavailable and where they can get help in the meantime.
Apply the patched release
Install the fixed PHP version through the same channel you normally use: your distribution’s package manager, your container base image or your hosting provider. Avoid one-off manual builds, which tend to get forgotten when the next update comes. If you use containers, rebuild the images and redeploy them. Patching a running container is not enough, because the change is lost when the container restarts.
Test on a staging copy first if you can, because minor PHP updates sometimes change behaviour. When the risk is serious, a short test followed by a quick deployment is usually better than a long delay. After deploying, restart PHP-FPM or the web server. Then confirm the new version is the one actually serving requests.
Check for signs of compromise
Patching closes the hole but does not remove an attacker who got in first. Look through web server and PHP logs for unusual requests around the time the vulnerability became public. Look for newly created or modified PHP files, especially in upload directories. Check for unexpected scheduled tasks and new administrator accounts.
Compare deployed code against your version control repository where you can. Rotate database passwords, API keys and other secrets stored in configuration files if there is any doubt. If you find evidence of a breach, treat it as an incident. Organisations handling personal data in the UK may have reporting duties to the Information Commissioner’s Office.
Restore service and keep monitoring
Bring sites back gradually, starting with those whose patch and integrity checks are complete. Watch error logs and traffic for several days afterwards. Follow-up advisories and corrected patches sometimes follow a first release. Subscribe to the PHP announcements list and your distribution’s security feed so you hear about the next alert directly, not through general news.
Avoid the mistakes people actually make
The most common mistake is patching the main production server and forgetting staging environments, old subdomains and test installations, which attackers find through automated scanning. Another is checking the command-line PHP version and assuming the web server runs the same one.
People also mix up a flaw in PHP with a flaw in an application written in PHP. Upgrading PHP does nothing about a vulnerable plugin. Others run PHP releases that no longer get security updates. Those versions may never receive a fix, so the only lasting answer is to upgrade to a supported branch. Finally, some teams take a site offline and never investigate, then bring it back with any planted backdoor still in place.
Know when this approach is the wrong choice
This step-by-step response is designed for site owners and administrators. If you use a fully managed platform, your role is mainly to confirm with the provider that the fix is in. Changing settings yourself could get in the way of their work.
If you already see clear signs of compromise, such as defaced pages, data leaving the server or ransom notes, stop routine patching. Bring in incident response help and preserve the evidence before changing anything. If the vulnerability turns out to be in an application rather than in PHP itself, follow that vendor’s guidance.
Frequently asked questions
How do I check which PHP version my website uses?
On a server, run php -v, but also check the version used by the web server itself, because the two can differ. On shared or managed hosting, the control panel usually shows the PHP version for each site. A temporary page that calls phpinfo() also shows the active version. Remove that page immediately afterwards, because it reveals configuration details useful to attackers.
Should I take my PHP website offline during a security alert?
It depends on whether your version and setup are affected, and on how quickly you can patch. If the official advisory confirms your site is vulnerable, the flaw is being actively exploited and no fix can be applied quickly, then restricting access or showing a maintenance page is a reasonable precaution. Tell users clearly what is unavailable and when to check back.
Does updating PHP fix vulnerabilities in WordPress or other PHP applications?
No. PHP is the language and runtime, while WordPress, Drupal and similar systems are applications built on it. A flaw in the runtime is fixed by updating PHP. A flaw in an application, theme or plugin is fixed by updating that component. Read each advisory to see which layer is affected before deciding what to update, and keep both layers current.
What should I do if my PHP site was hacked before I patched it?
Treat it as a security incident. Preserve logs and copies of suspicious files, then check for modified code, new administrator accounts and unfamiliar scheduled tasks. Restore from a known clean backup taken before the compromise, and change all passwords and keys. UK organisations holding personal data should check whether they must report the breach to the Information Commissioner’s Office.
Sources and further reading
- PHP project: official release announcements and security notes for supported branches
- National Cyber Security Centre: guidance on vulnerability management and incident response for UK organisations
- Linux distribution security teams: advisories describing backported fixes in packaged PHP builds
- Information Commissioner’s Office: guidance on personal data breach reporting duties
Surfaced from the google:GB signal “PHP security vulnerability alert”. AI-assisted draft, editorially reviewed.
