Engineering

PHP2Shell: What to Do This Week, and What It Says About Rented Software

Two critical PHP flaws are being exploited. Here's what to check this week, and why renting your stack means renting your patch schedule.

Hari Gopal Sharma · 2026-10-23 · 6 min read

security php wordpress maintenance

If your website, client portal or internal tool runs on PHP, the most useful thing you can do today is send one email: "Which PHP version is serving our sites right now, and has it been updated since October 21?" Then wait for a written answer with a version number in it.

On Wednesday the PHP project fixed two critical vulnerabilities that together go by the name PHP2Shell. Attackers were probing for them before the fix existed. This post covers what happened, what to do this week, and the less comfortable question it raises about who is responsible for the software your business rents.

What happened

The two bugs are CVE-2026-109618 and CVE-2026-109619. PHP's security team rates both 9.2 on CVSS v4.0, and says they "can allow unauthenticated remote code execution." In plain terms: someone who has never logged in to your site may be able to run their own code on your server.

The technical causes are different. In the first, out-of-memory handling can interrupt PHP while request data is only partly set up, and the cleanup that follows treats that broken data as valid. In the second, state that belongs to one request can survive after its memory has been freed, and a later request on the same worker may use it.

PHP says the affected scope is every installation serving web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the highest risk, because the attack can start before any of your application code runs.

The fixed versions, released October 21, 2026, are:

Older branches are a different story. PHP 8.1 and earlier no longer get official releases. The security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux distributions and long-term support vendors ship their own fixes. Per Tenable, versions 7.3 and older get no fix from the PHP project at all.

Why this one moved fast

The disclosure didn't go to plan. According to the PHP Foundation, the CVE numbers started circulating online on October 20, along with a wrong severity score of 10.0. A researcher's proof-of-concept video went out by mistake that evening, and a vendor published patched images hours before the coordinated release. PHP pulled the release forward a day, from October 22 to October 21.

Attackers were already looking. Amazon Threat Intelligence saw an exploitation attempt against its honeypots on October 17, four days before disclosure, and more attempts on October 21. watchTowr reports in-the-wild exploitation of both bugs on its own sensors from October 21.

To be fair about the evidence: CISA's October 21 alert said it had not observed exploitation at the time, and when I checked CISA's Known Exploited Vulnerabilities catalog today, neither CVE was listed. That catalog often trails what security firms see on their own sensors. CISA still urged immediate patching, and advised taking PHP systems offline if they can't be updated or still run 8.1 or older.

Updating is the only real fix

There are configuration changes that block some known attack paths, such as disabling session upload progress or changing memory limits. PHP is clear that these "reduce exposure to specific attack paths but do not make an installation safe." The release notes say it more bluntly: "There are no complete mitigations, updating is the only safe choice." Amazon reached the same conclusion: no configuration-only workaround covers both bugs.

So treat any mitigation as a bridge for a day or two, not a destination.

The WordPress trap

This is where many small businesses will get caught. Keeping WordPress, your theme and your plugins updated is good practice, and it does nothing for this. The flaw lives in PHP itself, the engine underneath WordPress. As WordPress.org's own guidance puts it, "Your hosting company determines which versions of PHP are available for your site."

You can see your current version in the WordPress dashboard under Tools, then Site Health, then the Info tab, under Server. That tells you the branch. Whether that build includes the October fix is a question for your host.

What to do this week

  1. Inventory every PHP system. Not just the main site. Include staging servers, the old marketing site from two campaigns ago, landing pages on a separate host, admin panels, and any server a plugin or integration depends on. Note which ones face the internet.
  2. Check the version that actually serves web traffic. watchTowr points out that the command-line PHP on a server can differ from the one Apache or PHP-FPM runs. Ask for the web-serving version.
  3. Get written confirmation. Ask your host, agency or developer to confirm, in writing, the exact patched version on each system (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a named vendor backport) and that PHP workers were restarted afterwards.
  4. Deal with end-of-life versions. If anything runs PHP 8.1 or older, it needs a vendor backport or an upgrade plan with a date on it. Until then, restrict access or take it offline, as CISA advises. Also note that PHP 8.2 reaches end of life on December 31, 2026, so 8.2 sites need an upgrade plan too.
  5. Look for signs of compromise from October 17 onward. Amazon recommends starting from the earliest known attempt, not the disclosure date. Watch for unexpected files in web folders, new admin accounts, odd scheduled tasks, PHP processes crashing or hitting memory limits, and outbound connections from the web server that nobody can explain. Preserve logs before you change anything.
  6. Rotate credentials if anything looks wrong. Database passwords, API keys, payment and email credentials stored on the server. If a system was exposed and unpatched for days, rotating is cheaper than wondering.

Rent the stack, rent the patch schedule

None of this means PHP is a bad choice. It runs a huge share of the web, its security team shipped fixes for four supported branches under pressure, and it published backports for versions it no longer supports. That is a responsible project doing hard work well.

The lesson is about ownership. If you run on shared hosting, a page builder or a stack of plugins, you have handed someone else the job of patching the layer underneath you. That's often a sensible trade. But it means your exposure window is their response time, and most owners have never asked what that is.

Know who owns patching for each system you depend on. Know how fast they move on a critical issue, and whether they'll tell you when it's done. I wrote about the cost of nobody owning that work in Abandoned Code Is an Open Door. If you're weighing custom software against renting, patch ownership belongs on the list either way.

If you're not sure where you stand

If you can't answer "which PHP version is each of our systems on, and who updates it?" by the end of the week, that's the real finding. It's fixable. We help small businesses map what they run, close urgent gaps like this one, and set up maintenance so the next critical bug is a routine ticket. You can see how we work on our services page, or book a conversation below.

Sources

Keep reading

← Back to Insights