PHP security alert: what schools and businesses should check now

What has happened?

On 21 October 2026, the PHP team released fixes for two critical security flaws, commonly called PHP2Shell. Their reference numbers are CVE-2026-109618 and CVE-2026-109619.

PHP is software that runs behind many websites. You might use it through a WordPress site or another service without ever seeing its name.

These flaws can let an attacker make the computer running a vulnerable website carry out their instructions without signing in. Website files and information accessible to that computer could be at risk. The concern is the software on the server, so changing your own laptop settings will not fix it.

The PHP team's security advice and CERT-EU's alert explain why affected systems need urgent attention.

Start with your website or IT provider

Ask whoever looks after your school, trust or business website whether it uses PHP. Include other web applications, old sites and test sites; some may sit with different suppliers.

For services bought from another organisation, ask that supplier to confirm whether its service is affected and what it has done. A familiar brand or a working login page is not evidence that the update is installed.

You can use this message:

Please check whether our website or any web services you manage for us use PHP. Have you applied and verified the fixes for CVE-2026-109618 and CVE-2026-109619? Please confirm the running version or patched vendor package, the services covered, and any remaining action. Please also check PHP's follow-up advice of 23 October about session upload progress.

Use your usual support portal or a contact number you already trust.

What update should they confirm?

The 21 October security releases fix the original two flaws in these PHP versions:

PHP version family	Security release to check
8.5	8.5.12 or a later release containing these fixes
8.4	8.4.27 or a later release containing these fixes
8.3	8.3.36 or a later release containing these fixes
8.2	8.2.35 or a later release containing these fixes

Some suppliers put security fixes into an older-looking version number. Ask them to identify the relevant vendor update and confirm that it covers both flaws. Older PHP installations need a specific confirmed fix or a move to a supported version.

Ask about PHP itself as well as website software and plugins. Updating WordPress alone does not confirm that the server's PHP has been updated.

The provider should check the version actually serving your website, complete any required service restarts and test important functions such as forms and sign-in. An installed update that is not yet running leaves the job unfinished.

If they cannot fix an affected service promptly, ask about temporarily restricting access until it is updated and checked. Agree how essential services will remain available. CERT-EU recommends considering isolation where immediate patching is not possible.

Include the 23 October follow-up advice

On 23 October, PHP published further advice about an uncommon combination of application and server settings, tracked separately as CVE-2026-115560. It recommends temporarily disabling the session upload progress feature, unless the provider can confirm that the relevant configuration is not used.

Ask your provider to check PHP's 23 October advice, apply the relevant guidance and follow the next bugfix release. The 21 October fixes and this follow-up check are separate parts of the conversation.

What should you look out for?

Tell your provider promptly about:

• Pages, links or website redirects that nobody authorised.
• New administrator accounts or changes that staff cannot explain.
• Repeated website failures or unexpected security alerts.
• Messages claiming to offer an urgent “PHP fix” and asking for your password, a download or remote access.

These are general warning signs. They do not prove that this particular vulnerability has been used. Equally, a normal-looking website does not prove that it is patched or free of compromise.

Check unexpected requests through your normal supplier contact. Avoid using a link or telephone number supplied in a suspicious message. The NCSC's advice on suspicious messages explains this approach.

If you suspect someone has already got in

Contact your IT provider and whoever coordinates incidents in your organisation. Record what you noticed and when, and ask the provider to preserve the relevant logs and investigate.

Applying the PHP fix prevents the original flaws being used again; it does not automatically remove files or accounts an attacker may already have left behind. Recovery may require restoring a known-clean system and changing exposed credentials. Your provider should direct that work.

If personal information may have been affected, involve your data protection lead promptly. The NCSC's response and recovery guidance provides routes to further help.

Keep a short record

Write down who owns each website or service, who maintains it, the update confirmation and any outstanding actions. Give one person responsibility for following up. Keep that record current when a supplier, website or application changes.

The useful result is a clear answer: which services were checked, what was fixed and what still needs attention.