PHP2Shell: update PHP on your web servers today

On 21st October, the PHP project released emergency fixes for two critical security flaws in the PHP programming language. PHP runs most of the web, including most WordPress, Drupal, Joomla and Magento sites. If your organisation has a website, a customer portal or an internal web tool, this almost certainly concerns you.

The action is clear. Update PHP today, or confirm with whoever runs your servers that it has been done.

What happened

The two flaws, CVE-2026-109618 and CVE-2026-109619, have been nicknamed PHP2Shell. Both are rated 9.2 out of 10 (CVSS v4.0, Critical). Together they can let an attacker run their own code on a web server without logging in, and read sensitive data from the server's memory, such as passwords and API keys.

The flaws sit in the core PHP engine, not in any one plugin or theme. That means a site can be exposed even when its own code is fully up to date. Researchers report that every PHP version since 5.4, released in 2012, is affected by at least one of the two.

Details leaked a day before the planned disclosure, and public proof-of-concept code is already circulating. Security vendors are reporting exploitation attempts against websites. National CSIRTs had not confirmed successful attacks at the time of writing, but that window is closing fast.

Why it matters for your business

A compromised web server is rarely the end goal. It is the front door. From there, attackers can steal customer data, plant malware on your site, or move deeper into your network.

This is not a theoretical risk for someone else. Public institutions in Iceland and the Netherlands took websites offline on 21st October as a precaution. CERT-IS, CERT-SE and CERT Polska have all issued advisories urging organisations to act now.

The good news: the fix exists, and for most organisations it is a routine update. The organisations that get hurt by flaws like this are usually the ones that assume someone else has handled it.

What to do now

We recommend these steps, in this order:

1. Find every PHP system you run. Start with anything facing the internet. Include websites, staging sites, customer portals, phpMyAdmin, control panels and vendor appliances that bundle PHP.
2. Update PHP today. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions and hosting platforms have released their own patched packages, so use your vendor's update where one exists.
3. Restart and verify. Restart all PHP services, then confirm the patched version is the one actually serving your website. The command-line version can differ from what your web server runs.
4. Isolate what you cannot patch. PHP 8.1 and older receive no official fix. Until you have a vendor backport or an upgrade, restrict access to those systems or take them offline. A web application firewall can buy time, but it is a stopgap, not a fix.
5. Check for signs of compromise. Look for unfamiliar PHP files in your web folders, new admin accounts and unusual outbound connections from your web servers.
6. Rotate secrets. If a system was exposed before you patched it, change its database passwords, API keys and tokens.
7. Report incidents. If you find evidence of an attack, report it to your national CSIRT: CERT-IS in Iceland, CERT-SE in Sweden or CERT Polska in Poland.

One warning: fake proof-of-concept scripts are circulating. Do not run code from unknown sources to test your systems.

If someone else runs your website

Many organisations rely on a hosting provider or a web agency. That is fine, but do not assume the update has happened. PHP is patched at server level, so it will not appear as an update in your WordPress dashboard. Ask your provider these questions today:

• Has the PHP version serving our site been updated to fix CVE-2026-109618 and CVE-2026-109619? Which version, and when?
• Were all PHP services restarted, and did you confirm the patched version is live?
• Are any of our sites or tools running PHP 8.1 or older? What is the plan for them?
• Is a web application firewall protecting our site while patches are pending?
• Have you checked our servers for signs of compromise from before the patch?

How Syndis can help

Most organisations can handle this with a disciplined update. If you are unsure where PHP runs in your environment, or whether you were exposed before patching, we can help.

• Offensive Security: we can map your internet-facing systems and confirm which ones still run vulnerable PHP versions.
• Detection and Response: our 24/7 SOC monitors for the kind of activity that follows an attack like this.
• Advisory: if you run end-of-life PHP, we can help you plan the upgrade before the next critical flaw arrives. PHP 8.2 support also ends on 31st December 2026.

If you suspect a compromise, contact us right away.

This post reflects what is known as of 21st October 2026. We will update it as the situation develops.