Legacy PHP
Find out what PHP you are actually running. In two days, for a fixed fee.
An exposure assessment, not a replatform pitch. We inventory every PHP runtime you have, per environment, establish where each fix actually came from, and hand you a costed upgrade path with the breakages named. If moving off PHP is the cheaper answer, this is the work that proves it.
- 2 daysSenior engineering time, fixed fee
- Days 0 to 14When this is worth doing
- 31 Dec 2026PHP 8.2 security support ends
php2shell turned every PHP install into a question nobody in the building could answer. The honest problem is not that you might be unpatched. It is that the version number cannot tell you either way, because a Linux distribution backports a security fix without changing it, so a patched and an unpatched 8.1.34 print exactly the same string. This engagement answers the question properly, from the hosts rather than from the outside, and what it finds decides whether you are patching, hardening or moving. That order matters: a replatform quoted before the first three questions are answered is a guess with an invoice attached.
Why the specifics are the service
The same CVE, a different answer on every platform.
This is the level the assessment works at. Not “upgrade PHP”, but which package, out of which archive, and whether it needed a paid subscription to exist at all. Four real answers to one vulnerability:
Ubuntu 22.04, php8.1
Fixed in the standard archive as 8.1.2-1ubuntu2.28, with no subscription involved, even though PHP 8.1 reached upstream end of life on 31 December 2025.
Ubuntu 20.04, php7.4
Fixed only as 7.4.3-4ubuntu2.29+esm5, which sits behind the paid Ubuntu Pro and ESM tiers. Without that subscription there is no fix for this host, at any price you have already paid.
Debian bookworm, php8.2
Fixed as 8.2.35-1~deb12u1 through the security archive. The 8.2.32-1~deb12u1 in the main archive is still listed as vulnerable, so whether you are patched depends on which archive your host pulls from.
Debian bullseye
Not listed in the Debian security tracker for these CVEs at all. No status is not the same as not affected, and that gap is the whole reason the question has to be asked on the host.
Package versions read from the Ubuntu CVE page for CVE-2026-109618 and the Debian security tracker on 28 October 2026. Branch support dates from php.net/supported-versions and php.net/eol the same day. If any of these has moved since, the assessment uses what the sources say that week, not what this page says.
What the two days produce
What is in the document.
A runtime inventory
Every PHP version actually running, per environment and per host, read out of the package manager rather than off a wiki page nobody has updated since the last migration.
Where each fix came from
Per host: the standard archive, a paid support tier, a vendor backport, a hand-compiled patch, or nowhere. This is the finding that changes budgets, and no external scan can produce it.
Position on the support calendar
Which branch each application sits on and the date its security fixes stop. PHP 8.2 stops on 31 December 2026, which makes it a patch target this week and a liability shortly after.
A mitigation review
The administrative settings that genuinely reduce exposure, the per-pool and per-directory overrides that quietly undo them, and the two resource limits that make the vulnerable path easier to reach rather than harder.
A costed upgrade path
The route to a branch supported well past 31 December 2026, with the breaking changes named per application rather than quoted off a PHP release note.
The replatform question, answered
Which applications are worth upgrading in place and which are old enough that upgrading and replacing now cost roughly the same, with the working shown either way.
AI in the loop
The inventory is machine work. The verdict is not.
Reading hundreds of hosts and tracking a support calendar is exactly what agents should do. Deciding whether you are patched is not, and we do not pretend otherwise.
Runtime inventory agent
Queries each host's package manager for installed PHP packages, their archive, and their changelog.
- Trigger
- Runs once per environment during the assessment, then on a schedule if you keep it.
- Output
- A table of host, package version, originating archive and branch end-of-life date.
Calendar watch
Tracks the upstream support calendar against the branches your inventory actually contains.
- Trigger
- Runs weekly.
- Output
- A note when a branch you run moves inside one quarter of its security end of life.
Advisory filter
Narrows new PHP advisories to the branches and extensions you run, and to the distributions you run them on.
- Trigger
- Runs on publication.
- Output
- The advisories that apply to you, each with the vendor package to wait for.
Upgrade dry run
Builds and boots each application against the target branch in a throwaway environment.
- Trigger
- Runs on request while the upgrade path is being costed.
- Output
- The failing files, and the extensions with no supported equivalent on the target.
Nothing in this list concludes that you are safe. That conclusion comes from a vendor package version and its changelog, read by a person who will put their name on it.
The check that settles it
Run it yourself. The vendor package version is the string that means something.
These are the commands the assessment runs, on every host instead of one. If anything we hand you contradicts what these print on your own servers, we are wrong and you should say so.
The installed package, its archive, and the changelog entry that names the CVE. On Ubuntu 20.04 and earlier, the last command is the one that tells you whether the fix is even reachable.
# Which PHP packages are installed, and at what version
dpkg-query -W -f='${Package} ${Version}\n' 'php*' | sort
# Which archive the installed version came from, and what is available
apt-cache policy php8.2
# The changelog entry that should name CVE-2026-109618 / CVE-2026-109619
apt-get changelog php8.2 | head -40
# On Ubuntu 20.04 and earlier: is the ESM fix reachable at all?
# php7.4 on focal is fixed only as 7.4.3-4ubuntu2.29+esm5, behind Ubuntu Pro.
pro security-statusHow we work
Three stages. You only buy the first one.
- 01
Exposure assessment
Days 0 to 14. Two days of senior engineering time for a fixed fee: the inventory, where each fix came from, the calendar position, and a costed upgrade path. This is the only thing we ask you to buy today, and it is useful even if you never buy anything else.
- 02
Patch and harden
Weeks 1 to 6. The work the assessment found, in the order it ranked it: packages, worker restarts, the configuration that was silently undoing a mitigation, and the hosts where a fix does not exist yet. Scoped from the assessment, so nobody pays for a second discovery phase.
- 03
Upgrade, or replace
Months 2 to 6. The route off a branch with a death date, or the move to something that is not PHP at all. Quoted against the assessment's own numbers, and only for the applications where it came out cheaper than upgrading in place.
What this does not do
Four things we will not claim.
The post this page follows from is read because it refuses to say a version number can prove patch status. This page is not going to undercut that to make an engagement sound bigger.
It does not prove you were never compromised
An assessment reads current state. Establishing whether something already happened is incident response and forensics: different work, different people, different engagement. If that is what you actually need, we will say so instead of selling you this.
It is not a penetration test
We exploit nothing, and what we hand over is not a report an auditor or an enterprise customer will accept as independent testing. For that you want a firm that has not touched your systems, and we can point you at one.
It cannot be done from the outside
Our free checker reads the version a server advertises, which gives you the branch and nothing about patch status. The assessment needs read access to the hosts and their package managers, because that is the only place the question can be answered.
It does not conclude with a replatform
Most assessments end in a patch, a configuration fix and an upgrade path. When upgrading in place is cheaper, that is what the document says, and the migration we might otherwise have sold you does not happen.
Where this starts
The four questions we get in the week after a CVE.
Nobody books a call asking for PHP modernization. They arrive with one of these, usually on a Tuesday, usually because somebody on the board read a headline.
Are we vulnerable?
The question everyone asks first, and the one that cannot be answered from a version number, because distributions backport security fixes without changing it.
Points at the host: the installed vendor package, the archive it came from, and its changelog, per environment rather than per assumption.
We patched to 8.2. Are we done?
Partly. PHP 8.2 is one of the branches that got a fixed release, so patching to it closes php2shell. Its security support ends on 31 December 2026.
Points at the support calendar: a patch with a date on it is a reprieve, and planning the next hop now costs less than planning it in December.
Our hosting provider says it is handled.
Sometimes that is true. On Ubuntu 20.04 the php7.4 fix exists only behind paid Ubuntu Pro, so whether it is handled depends on a subscription somebody either bought or did not.
Points at provenance: which archive the installed package actually came from, which is a one-command answer nobody had run.
Should we just rebuild the whole thing?
Occasionally yes. More often it is the answer that arrives first because it is the easiest thing for an agency to quote and the hardest thing for you to check.
Points at both numbers: the cost of upgrading in place and the cost of replacing, measured on your code rather than asserted in a proposal.
What clients say
I was particularly impressed by their creative approach and attention to detail.
Videography & photography company · website, SEO + design
They delivered the project on time.
Watch retailer · Shopify store build
Cubitrek always had a positive mindset and was kind.
Personal training company · video + social media
Questions buyers ask us.
- It is a fixed fee, quoted in writing before the work starts, and it does not move if the work turns out to be harder than we expected. The fee is set by the number of environments and hosts in scope rather than by hours spent, and two days of senior engineering time is the usual shape. Ask on a 15-minute call and you will have the number and the scope in the same email.
- No, and nobody can. A Linux distribution backports a security fix without changing the PHP version number, so a patched and an unpatched build of the same version report an identical string to the outside world. An external check tells you which branch a server advertises and whether that branch is still supported upstream, which is a useful first orientation and not an answer. The answer is the installed vendor package version and its changelog, and both live on the host.
- Usually three things. Which branch you landed on, because 8.2 is a fixed release whose own security support ends on 31 December 2026. Whether every worker process actually restarted, which matters because the second flaw needs a producer and a consumer in the same worker. And whether a pool, directory or application setting is quietly restoring a finite memory limit and undoing the primary configuration mitigation.
- Not as an upstream release. PHP 8.1 left security support on 31 December 2025 with 8.1.34 as its final release, and 7.4 left on 28 November 2022 with 7.4.33. Distribution coverage is where it varies, and the variance is the point: Ubuntu fixed php8.1 on 22.04 in the standard archive as 8.1.2-1ubuntu2.28, while php7.4 on 20.04 is fixed only as 7.4.3-4ubuntu2.29+esm5 behind the paid Ubuntu Pro and ESM tiers, and Debian bullseye is not listed in the security tracker for these CVEs at all.
- The most conservative branch whose security support still has more than a year to run, which today is PHP 8.3, supported until 31 December 2027. Not the newest: upgrade cost rises with distance, and the goal is runway rather than novelty. Moving to 8.2 instead would be technically current and would put you back in this conversation before the new year.
- Only when the numbers say so, and the numbers are in the document you already paid for, so you can check them without us. A replatform is a three to six month procurement decision and selling one off the back of a CVE is selling the wrong thing at the wrong moment. Most of these engagements end in a patch and an upgrade path.
- Both, as separate stages. The assessment stands alone and is deliberately useful to a team that then does the work themselves. If you would rather we did it, the patch and harden stage is scoped directly from the assessment's findings, so there is no second discovery phase to pay for.
- Read access to the hosts or to someone who has it, one conversation about which applications matter, and a read of the document at the end. Two working days of our time, usually inside a calendar week of access being granted.
Read the working first
Everything on this page, with its sources.
- php2shell: what to patch today, and what to replace this year
What the two CVEs actually do, why a version number cannot prove patch status, and the PHP 8.2 end-of-life trap. Every claim linked to the source it came from.
- Free PHP exposure check
Which branch a site advertises and where that branch sits on the support calendar. Free, no signup for the diagnosis, and no verdict it cannot support.
Ready when you are
Ready to start PHP modernization?
A 15-minute call. We map the goal, look at what exists, and come back with a scoped plan.