The Critical Security Issue Affecting PHP Is an Ownership Problem

On October 21, 2026, the PHP project fixed two flaws that let an attacker run code on a web server without logging in. CERT-EU, the cybersecurity service for the EU institutions, told organizations to patch at once and, where that is not feasible, to consider isolating internet-facing systems from public networks. Patching the critical security issue affecting PHP will take days. The harder part for most security leaders is the first question they get: where do we run PHP at all?

• Are we exposed if we do not build in PHP? See where PHP runs without anyone choosing it.
• Did Azure patch this for us? Understand where the platform's job ends.
• What do we tell the board this week? Learn the five questions to answer first.

What the Critical Security Issue Affecting PHP Does

Two flaws in PHP itself let an attacker run code on a web server with a single request and no login. The PHP project's security advisory says all PHP installations serving web requests are at risk, and the PHP team rates both CVE-2026-109618 and CVE-2026-109619 at 9.2 out of 10.

The PHP team has seen the attack demonstrated on Apache with mod_php, where it fires before any application code runs. A carefully written website on a vulnerable PHP version is exposed all the same. The PHP team names that setup as the riskiest, so ask your web teams first whether any system runs it.

Experts do not agree on how easy the attack is. Red Hat rates the first flaw Important rather than Critical, because a reliable attack needs precise memory manipulation and timing. On Red Hat Enterprise Linux's default PHP setup, it calls remote code execution "difficult in practice".

CERT-EU reads the situation more urgently: technical details are public, early proof-of-concept code is circulating, and that raises the likelihood that attackers are already using it. When two credible sources disagree, plan for the worse reading. A patch costs a maintenance window, and guessing wrong costs a server.

PHP 8.2 reaches end of life on December 31, 2026, so a system patched to 8.2.35 this week still needs an upgrade plan. Versions 8.1 and older get no official release from the PHP project. Its security team did publish minimal source backports for 7.4, 8.0 and 8.1, which only help teams that compile PHP themselves. For any system on 8.1 or older, the owner has to pick a vendor's backported fix or an upgrade, and keep the system offline until one of them is in place.

Most of Your PHP Was Chosen by Someone Else

Even if nobody in your organization writes PHP, your exposure usually sits in software that brought PHP along. The Dutch National Cyber Security Centre keeps a public list of products with a PHP dependency and marks each one with a status such as under investigation, vulnerable, fixed or not vulnerable. WordPress is on it as vulnerable whenever it runs on an affected PHP version, and the remedy listed is the PHP upgrade. Updating WordPress itself does not fix it.

Marketing and campaign sites. A WordPress site that an agency built three years ago, on a hosting account marketing still pays for, is the classic case. Security never approved it, so security never sees it. This is the same pattern as shadow IT, with a public web address attached.

Vendor products. Help desks, online shops, billing tools and admin consoles often run PHP under the hood. The vendor has to ship the fix, and you need to know that it did. Ask for confirmation in writing, with the version number.

End-of-life runtimes. An internal tool still on PHP 7.4 has no official patch at all. Somebody has to upgrade it or switch it off, and that somebody needs a name.

The NCSC list leaves out applications built in-house and warns that it is incomplete, so read it as a list of questions for your vendors. Endpoint tools such as Microsoft Defender can list installed software, but only on servers someone has onboarded to them.

On Azure, the Platform Patches Only Its Own Images

Azure has patched only part of your PHP. Microsoft fixed the PHP that Azure App Service on Linux provides itself, according to the App Service team's October 21 update. An app is covered if it runs on those built-in PHP images and on a supported PHP version. Apps on the slower Extended release channel get the fix last.

Everything else is your team's job. Microsoft does not patch PHP inside custom containers, PHP versions that have reached end of life, or WordPress on the older Alpine-based images. PHP that your team installed on its own servers is also yours, and Azure Arc can bring servers outside Azure under the same management. Ask your team for a single list of every PHP app you run on Azure, showing for each one whether Microsoft or your own people apply the patch.

Figure 1. Microsoft patches the built-in PHP images. Custom containers, old runtimes and Alpine WordPress images stay with your team.

A web application firewall only buys you days. Firewall rules can block known attack patterns while you patch, but the PHP team states that interim measures do not make an installation safe. Give any rule you add an end date.

Patch or Isolate, Then Name an Owner

Every internet-facing PHP system needs one of two decisions this week: patch it, or take it off the public internet until it is patched. That matches CERT-EU's advice, which adds that isolation should last until the fix is applied and verified. Configuration changes and firewall rules only bridge the time until one of those decisions is carried out. The board will ask a simpler question than your engineers do: are we exposed? Five questions get you to the answer.

1. Which of our systems run PHP, including those hosted by vendors and agencies?
2. Which of them can be reached from the internet?
3. Who owns each one, by name?
4. Is each one patched, isolated or scheduled, and by what date?
5. Which vendors have confirmed a fix in writing?

The third question is usually the slow one. In many organizations, the owner of a forgotten website turns out to be whoever approved the hosting invoice, and that person is rarely in the security meeting.

AI has the same gap. Tools and agents that teams sign up for on their own are assets too, often with access to company data and no owner on file. That is how shadow AI gets in. If this week showed holes in your inventory, I would run the same five questions against your AI tools before a vendor advisory forces you to.

Work with Precio Fishbone

Patching closes the critical security issue affecting PHP. Keep the list you built after that, with a named owner on every line, because the next advisory will ask the same five questions. To see how leaders are handling unknown AI tools and agents, read our AI security guide for business leaders and our take on AI risk management for CIOs, talk to our AI services team, or email me at par.johansson@preciofishbone.se.

Frequently Asked Questions