Security alert · Updated
Two critical flaws let an attacker run code on your server with one web request, no login needed. PHP 8.2 and newer got fixed releases. Older versions have no official fixed release. Getting legacy PHP up to date happens to be my specialty.
Free 30-minute call · $100 an hour after that · Old WordPress sites to million-line codebases
CVE-2026-109618 · CVE-2026-109619
On October 21, 2026, the PHP project shipped fixes for two critical vulnerabilities in PHP itself. Not in a plugin, not in a framework: in the language your site runs on.
The flaws can let an attacker run their own code on your server without logging in. PHP rates both 9.2 out of 10, and on Apache with mod_php it describes a working exploit that fires before any of your code even runs.
Security firms report exploitation in the wild. Amazon's threat intelligence team says its honeypots caught an attempt on October 17, four days before the fix was published.
PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are all on PHP's list. Researchers say the flaws reach back through PHP 7 and into PHP 5.
On WordPress, it's under Tools → Site Health → Info → Server. Elsewhere, check with phpinfo() served through your web server: the command line and the web server can run different versions, and only the web server's counts here.
| Your PHP | Fix | What to do |
|---|---|---|
| 8.5 | Fixed in 8.5.12 | Update now. Supported until the end of 2029. |
| 8.4 | Fixed in 8.4.27 | Update now. Supported until the end of 2028. |
| 8.3 | Fixed in 8.3.36 | Update now. Security fixes until the end of 2027. |
| 8.2 | Fixed in 8.2.35 | Update now, then plan your next move: 8.2 gets no security fixes after December 31, 2026. |
| 7.4, 8.0, 8.1 | No official release | PHP published bare source patches, and some Linux distributions and support vendors have backported the fix. Otherwise, it's time to upgrade. |
| 7.3 and older | No fix from PHP | PHP isn't patching these. Ask your distribution or support vendor; otherwise upgrade, or take it off the internet until you can. |
Source: PHP's security advisory and supported versions table, checked .
Free advice, no strings. If a package update fixes it for you, go do that, and I hope you'll remember who told you.
Every site, every server. The one you forgot about is the one that gets you.
PHP gave Linux distributions and support vendors the patches in advance, so updated packages should be waiting. On managed hosting, ask your host whether they've updated, and to which version.
Ask your distribution or support vendor whether they've backported the fix. PHP's advisory lists configuration changes that, in its words, "reduce exposure to specific attack paths but do not make an installation safe." Cloudflare has published firewall rules for known exploit attempts, free plan included. And the UK's National Cyber Security Centre advises considering taking offline any system that can't be fixed right away.
Everything in step three buys time, not safety. PHP's release notes are blunt: "There are no complete mitigations, updating is the only safe choice." If this is the step you're stuck on, that's my specialty.
Nobody stays on PHP 5 on purpose. Something breaks when you try to move, so you don't. Here's what getting unstuck looks like, depending on what you're running.
A theme or plugin that hasn't seen an update in years breaks on a newer PHP, so the site stays pinned to an old one. Now that old PHP is the problem.
What I do
An exposure check: which PHP version each site really runs, what breaks when it moves to a supported one, and what fixing each piece costs. Then we fix it: update, swap or retire whatever is holding the site back.
The exposure check typically takes about three hours a site, at $100 an hour
Code written for PHP 5 or 7 leans on functions and behaviour that newer versions removed. Nobody wants to touch it, and the people who wrote it may be long gone.
What I do
An assessment of your code and servers, then a written upgrade plan: a staged path, what breaks at each step, and how we'll know it still works.
Scoped to your codebase, with a written quote before the upgrade starts
A backlog of client sites on PHP versions that won't get a patch, and a team that already has a full-time job.
What I do
Triage first: which sites are exposed, and which will be hardest to move. Then I work through the backlog alongside your team, worst first.
$100 an hour, for as many or as few sites as you need
Been there, upgraded that
I've taken a million lines of PHP from version 4 to 8.5.
As software manager at a small SaaS company, I became responsible for a codebase of roughly a million lines that was still on PHP 4 when I arrived. It hadn't had software updates in years. I led the team in getting it onto PHP 5.3 first. Then I set a policy: we'd never fall behind by a major or minor version again. We kept up through PHP 5, 7 and 8, and when I left we were on PHP 8.5, the latest release. When the company was acquired, I also led a security uplift to remediate the vulnerabilities in the code we'd inherited.
Years of modernizing and securing other people's PHP. I can do it for yours, too.
Most of a PHP upgrade is a familiar list of changes, over and over: functions that were removed, behaviour that got stricter, extensions that moved. The hard part is knowing which ones touch your code, and in what order to fix them. That's the part I've done before, at a million lines.
And sometimes the fix is small. A WordPress site can be one abandoned plugin away from a supported PHP version. If that's you, I'll say so, swap the plugin, and send a short invoice.
Want the longer version? How legacy PHP upgrades work with CCG Labs.
It's the name researchers and the press gave two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed on October 21, 2026. They can let an attacker run code on a web server with a single request and no login. The PHP project rates both 9.2 out of 10.
If its PHP hasn't been updated to a fixed version, yes. WordPress itself isn't the problem; the PHP underneath it is. In your dashboard, go to Tools, then Site Health, then Info, and open Server to see your PHP version. Then find it in the table on this page.
From these two flaws, yes, if your site now runs a fixed release or your host's backported package. Ask which version, and check that it's the one your site actually uses. If your host couldn't move you because your site breaks on a newer PHP, that's the part I fix.
For now. PHP 8.2 gets its last security fix on December 31, 2026, so the next critical flaw after that won't get a patch for 8.2 at all. It's a good time to plan the move to 8.4 or 8.5.
As a stopgap, yes. As a fix, no. PHP's own advisory says its configuration workarounds reduce exposure to specific attack paths but do not make an installation safe, and its release notes put it plainly: there are no complete mitigations, updating is the only safe choice.
The first call is free. After that it's $100 an hour from the moment the work starts. An exposure check for one WordPress site typically takes about three hours. Custom applications vary too much to guess at, so they get an assessment and a written quote before the upgrade starts.
I read every message myself and reply within one business day. Tell me what you're running and which PHP version it's on, and we'll go from there.
Sources, checked :
Get in touch
Tell me what you're running: WordPress or custom, which PHP version, and how many sites. I read every message myself and reply within a business day.
Rather talk now? Call (570) 939-7322.