Skip to content

Security alert The NCSC has warned of a critical flaw in every version of PHP. If your website or application runs on PHP, it needs patching now.

Hosting, support & security

PHP patching, before it becomes an incident.

The NCSC has warned that a critical flaw affects every version of PHP. We find every install you are running, patch in the order that takes the most risk off the table first, and give you a record of what was done.

Live advisory

CVE-2026-109618 and CVE-2026-109619

The NCSC published a critical alert on 21 October 2026. Two memory-handling flaws in PHP can, in the right conditions, let an attacker run commands on a web server without authenticating first. A fix has been released. The NCSC is explicit that you should not limit the search to outdated versions: any version of PHP is affected, so having been up to date before the fix came out is not the same as being safe now.

Read the NCSC alert

Most businesses have no idea how much PHP they are running. It is under the website, under the booking system, under the intranet nobody has logged into since 2019, and inside appliances and vendor products that were never thought of as servers at all. When an advisory lands, the hard part is rarely applying the patch. It is knowing where to apply it.

That is the work. We build the list, patch in priority order, apply a temporary mitigation where an update has to wait on something else, and keep the estate in Anvil so the next advisory starts from a list rather than a guess.

What drives the cost

Priced two ways: a one-off job to get an estate patched and documented, or a monthly fee to keep it that way. What moves the number:

  • How many servers and sites, and how many of them anybody can still log into.
  • Whether your applications will run on a current PHP version, or need code work first.
  • How much downtime is acceptable, and whether we work in hours or out of them.
  • Whether we host it too - if we do, most of this is already part of your hosting.

Discovery is quoted on its own and can be the whole engagement. Plenty of businesses just want to know what they are running; what to do about it is a separate decision, and not one you need us for.

What you get

What the work covers

Finding every install

Servers, VPSs, shared hosting, containers and the odd machine under a desk. We look for PHP wherever it runs rather than only where you expect it, because the install you have forgotten about is usually the exposed one.

Internet-facing first

Anything reachable from outside gets patched before anything internal. That is the NCSC's own order of priority and it is the right one - it shuts the doors somebody could actually walk through today.

Patching with a way back

A snapshot before we touch anything, a check that the application still works after, and a rollback if it does not. An update that breaks your booking system on a Friday afternoon is not a result.

Mitigation when a patch has to wait

Where an update is blocked on a code change or a vendor release, we apply the interim mitigations the PHP Foundation has published, and tell you plainly what risk is left while you wait.

Bundled and third-party PHP

PHP inside appliances, control panels and vendor products is still PHP, and it is usually nobody's job. We list it, chase the vendor update, and tell you where you are waiting on somebody else.

End-of-life tracking

PHP versions stop receiving security fixes on a published schedule. We track which of yours are close to it, so the upgrade is planned work in a quiet month rather than an emergency in a busy one.

A look for the obvious

On anything that has been exposed and unpatched, we check for the common signs of compromise - files that should not be there, changed scheduled jobs, accounts nobody recognises. There is a note below on what that is and is not.

Built in-house

Anvil keeps the whole estate on one screen.

Anvil is our own security dashboard. We built it because a spreadsheet of server versions is out of date within a week, and a stale list is worse than no list - it tells you that you have checked when you have not.

Anvil is a record of what we have found and what we have done. It is a management tool rather than a guarantee: it is only ever as complete as the access and information we are given, and no dashboard makes a server immune.

An inventory that stays current
Every server and site we look after, the PHP version on it, and how that version is actually being run.
What is behind, and by how much
Installed version against current, ordered by how urgent the gap is rather than listed alphabetically.
End-of-life dates in view
When each version stops getting security fixes, so upgrades can be planned months ahead instead of discovered.
What has already been done
Which patches have been applied to which server, so whoever picks it up next is not starting from scratch.
A report you can forward
Where the estate stands as it is now, in a form you can hand to a board or a customer without editing it first.

How it works

How an engagement runs

No engineer turning up unannounced, and no invoice with surprises on it.

  1. 1

    Discovery

    We work out what you are actually running, from read-only access and a conversation. A day or two, and it is the part that finds the surprises.

  2. 2

    A prioritised plan

    What gets patched and in what order, what needs a maintenance window, and what needs code work first. Priced before anything is touched.

  3. 3

    Patch windows

    Booked at a time that suits you, including evenings and weekends, with a tested way back for each system.

  4. 4

    Ongoing watch

    The estate stays in Anvil. When the next advisory lands we already know what is affected, and you hear it from us rather than from the news.

Questions

The things people ask first.

Probably, yes. The NCSC's advice on this advisory is explicit: do not limit the search to outdated versions, because any version of PHP is affected. Having been current before the fix was published is not the same as having the fix.

We can look for the common signs - files that should not be there, changed scheduled jobs, accounts nobody recognises - and we will tell you straight if something looks wrong. We are not a forensic incident response firm. If it looks like you need one, we will say so rather than charge you to arrive at it slowly.

Common, and it is the real reason estates stay unpatched for years. That is a code problem rather than a server problem, and it is what our project rescue work is. We will tell you whether it is a week of work or a rebuild before you commit to either.

No. A good deal of it is on servers somebody else set up, including ones where the original developer is long gone and nobody has the passwords. We do not need to take over your hosting to patch it.

Usually. Most PHP updates need a short restart rather than an outage. Where a system genuinely cannot drop a single request, we will say so in the plan and set out what it would take.

Either. One-off gets you patched and documented now. Ongoing is what stops you being in the same position next time, which is the part that actually matters, because advisories are not rare.

What we promise, and what we do not

We will patch what we are given access to, in the order we agreed, and tell you honestly what risk is left. What nobody can promise is that a patched system cannot be broken into - flaws get found in software that was fully up to date the day before. What we are responsible for, and the limits on it, are set out in the security and patching section of our terms. It is worth reading before you engage us rather than after.

Read our terms

A quick word about cookies

We use a couple of cookies to make the site work, and we count visits with our own analytics - no third parties, no advertising, and no IP addresses stored. You can turn the counting off and we will not record your visit at all. Cookie policy.