Ars Technica reports that PHP maintainers have told developers to expect two critical security patches soon. List your PHP versions now, set up a tested update path and plan a restart window so you can apply the fixes within hours of release.
Gather what you need before starting
You need administrative access to every server, container build or hosting control panel that runs PHP. You also need a current list of the websites and applications that depend on it. If someone else manages part of your estate, such as a hosting provider or an agency, get their contact details and find out how quickly they can respond. A staging environment that mirrors production is very useful. A recent, restorable backup of code, configuration and databases is essential.
Know what is and is not known. Ars Technica reports that the maintainers have warned of two emergency releases, and that an unconfirmed report describes an exploit called PHP2Shell that can run code remotely on PHP sites. At the time of writing, it is not known which PHP versions or configurations are affected, whether the exploit claim is accurate, or exactly when the patches will appear. The steps below are meant to work whatever those details turn out to be.
Find every PHP installation you run
Start with an inventory, because you cannot patch what you have forgotten about. Check web servers, application servers, scheduled-task hosts and build machines. Search container images and infrastructure-as-code templates for PHP base images. Include development and test machines that can be reached from the internet. They often run older versions and attract less attention.
Remember that one server can have several PHP installations. A web server may run PHP-FPM, an Apache module and a separate command-line binary, and these can be different versions. Record each one separately.
Record the exact versions and their support status
On each host, run php -v for the command-line version. For the web-facing version, use a temporary phpinfo() page that only you can reach, and delete it afterwards. Note the full version string and the source of the build.
Then compare each version against the list of supported branches published by the PHP project. Only supported branches receive security fixes from the maintainers. If you run an end-of-life branch, an upstream patch may never arrive for it. That affects your plan, as covered in the final section.
Identify how each installation receives updates
How PHP was installed decides how it gets patched. Common routes include:
- Operating system packages from your Linux distribution. These are updated through the distribution’s own security channel, often on a different schedule from the upstream release.
- Third-party package repositories that track upstream PHP releases more closely.
- Official or custom container images, which only change when you rebuild and redeploy.
- Source builds, which need to be recompiled by hand.
- Managed or shared hosting, where the provider controls the timing.
Write the route down for each installation, with the exact command or pipeline that applies an update. Distribution packages may backport fixes without changing the main version number, so plan to check the distribution’s advisory rather than relying only on php -v.
Prepare a staging copy and a rollback plan
Run a rehearsal update in staging now, using whatever minor update is currently available. This confirms that your package commands, image builds and deployment steps work, and shows you how long they take. Fix any broken pipeline before the emergency release arrives.
Write a rollback plan as well. For packages, that means knowing how to pin or reinstall the previous version. For containers, it means keeping the previous image tag ready to redeploy. Security releases on a supported branch are normally kept narrow, but a rollback path means a faulty update does not leave you choosing between an outage and a vulnerability.
Watch the official channels for the release
Follow the PHP project’s own announcements and the security advisories of your distribution or image provider. If you use managed hosting, ask the provider how it will notify you. Rely on primary sources for version numbers and fixed releases rather than social media posts. Exploit claims spread quickly and are often inaccurate during the first hours.
Agree in advance who will apply the update and who can approve an out-of-hours change. Knowing that before the release saves time when it matters.
Apply the patch and restart PHP processes
When the fixed releases are published, update staging first and run your smoke tests: load key pages, log in, submit a form and check the error logs. If staging is healthy, roll the update out to production, starting with the systems most exposed to the internet.
Installing the package is not the whole job. Running PHP-FPM pools keep the old code in memory until they restart, and Apache’s PHP module needs Apache to reload. Restart the relevant services, then redeploy containers from freshly built images.
Verify the update and monitor for exploitation
Check the version again on every installation, through both the command line and a temporary web-facing check. For distribution packages, confirm that the installed package revision matches the one named in the advisory. Then review web server and application logs for unusual requests, unexpected new files in web directories and unfamiliar outbound connections. Indicators of compromise for PHP2Shell, if it proves real, are not known yet. Look for general signs of tampering until specific guidance is published.
Avoid the mistakes people actually make
The most common mistake is updating the command-line PHP and assuming the web server is patched too. Another is installing a package without restarting PHP-FPM, which leaves vulnerable code running. Teams also forget container images. The registry may hold a patched base image while production still runs an image built weeks earlier.
Other frequent problems include patching production first without a staging check, and relying on php -v alone on distributions that backport fixes. Many teams also leave the phpinfo() page in place after checking, which publicly reveals configuration details. Finally, waiting for proof that the exploit is real is a gamble. The maintainers’ warning is enough reason to prepare, whatever the truth of the PHP2Shell claim.
Recognise when this approach is the wrong choice
This step-by-step approach assumes you control your servers. On shared or fully managed hosting, your job is to confirm the provider’s timeline and to check afterwards, not to patch yourself. If your provider cannot give a clear answer, consider taking sensitive sites offline temporarily once the details are known.
The approach also falls short if you run an end-of-life PHP branch. An upstream patch may not exist for it, so a carefully timed update is no help. In that case, the realistic options are to upgrade to a supported branch, which needs application testing, or to rely on a commercial or distribution vendor that provides extended support. Restricting access to the affected application can serve as a temporary measure. If an application cannot run on any supported version, the long-term answer is to replace or rewrite it.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the name given in an unconfirmed report to an exploit said to let attackers run code remotely on PHP websites. Ars Technica mentions it alongside the PHP maintainers’ warning of two emergency patches. Its technical details, the affected versions and whether it works as claimed have not been confirmed publicly. Treat the name as unverified until the PHP project or a recognised security body publishes an advisory.
Which PHP versions are affected by the upcoming emergency patches?
This is not yet known. The PHP maintainers have announced that critical security releases are coming but, according to the reporting available so far, have not said which versions or configurations are affected. When the patches are released, the official announcements should name the fixed versions. Until then, the safest approach is to list every PHP installation you run and get ready to update all supported branches.
Do I need to restart my web server after updating PHP?
Usually yes. PHP-FPM keeps running processes with the old code loaded until the service restarts, and Apache’s PHP module only picks up the new version after Apache reloads. Command-line PHP takes effect for new scripts at once. Containers need to be rebuilt and redeployed from an updated image. After any restart, check the version again through the web server to confirm that the patched build is the one serving requests.
How do I patch PHP on shared hosting?
On shared hosting you generally cannot patch PHP yourself, because the provider controls the installed versions. Contact the provider, ask when it will apply the emergency releases, and find out whether its control panel lets you switch to a supported PHP branch. After the provider says it has updated, check the version through a temporary phpinfo() page that only you can access, then delete that page.
Sources and further reading
- Ars Technica, its report on the PHP maintainers’ warning of critical security patches and the unconfirmed PHP2Shell claim
- The PHP Group, official release announcements and the list of supported PHP branches
- Linux distribution security advisory services, for how packaged PHP builds receive backported fixes
- The CVE Program, for vulnerability identifiers once the flaws are formally disclosed
Surfaced from the rss:arstechnica signal “PHP emergency security patches”. AI-assisted draft, editorially reviewed.
