Independent security help · New Jersey
On October 21, 2026, the makers of PHP released emergency fixes for two critical security holes. PHP is the software underneath WordPress and many small-business websites. Sites that were not updated can be taken over without a password. I will check yours for free, explain what I find in plain English, and fix it if you want me to. You do not need to know anything about PHP.
Prefer to talk? Email me instead.
Free check
An automated check is not enough: most hosts keep the PHP version private, so a website can look fine while running something out of date. I look at the server directly, then reply in plain English with what you are running, whether the October 2026 flaws apply, and the exact fix. One business day. No login, no obligation.
I built one and took it down. In a sample of 4,965 PHP sites, only about one in nine published its version to the public, so the instant answer would have been “cannot tell” almost every time. A confident-looking result you cannot trust is worse than a person who actually looks.
In the news · checked October 22, 2026
PHP is the software that runs WordPress and a large share of the web. These two flaws are in PHP itself, not in a plugin or a theme. Updating WordPress does not fix them — the server’s PHP version has to be updated. Each flaw has a CVE number, which is a public ID you can look up.
The short version: PHP 8.1 and older no longer receive regular security updates, so the durable fix is to move to a supported version. If your site is on PHP 8.2–8.5 and has not been updated since October 21, 2026, it is probably still exposed. Security firms have already seen attack attempts, including before the fixes were published. Either way, the goal is the same: a supported version with the current fixes applied.
| ID | What it lets an attacker do | Severity | Fixed in |
|---|---|---|---|
| CVE-2026-109618 PHP2Shell | Run code on your web server without logging in. The attacker forces a memory error while your site handles a request, then uses the corrupted memory to take control of the PHP process. | Critical · 9.2 | 8.5.12 8.4.27 8.3.36 8.2.35 |
| CVE-2026-109619 PHP2Shell | Reuse another request’s leftover data. A failed request can leave behind memory that a later request still trusts, which can expose information or let an attacker run code. | Critical · 9.2 | 8.5.12 8.4.27 8.3.36 8.2.35 |
| CVE-2024-4577 Background | Run code on older Windows servers. A flaw in PHP’s Windows setup let attackers execute commands remotely. It was patched in June 2024, but attackers were still finding unpatched servers in 2025. | Critical · 9.8 | 8.3.8 8.2.20 8.1.29 |
You are on a supported branch. Confirm the live site is running the fixed version. A host can install the update and forget to restart PHP, so the version your site actually reports is the one that matters. PHP 8.2 reaches end of life on December 31, 2026, so plan to move up if you are on 8.2.
Your branch no longer gets regular security updates. Some hosts can patch older versions for you, but the durable answer is to move to a supported version. This is where most of the avoidable risk sits.
That is the most common answer, and it is not a failing. Most website owners were never told which version they run. A free check tells you within one business day.
Send it to your hosting company or the person who manages your site.
What PHP version is my live website running, and has it been updated to the fixed release for that branch (8.5.12, 8.4.27, 8.3.36, or 8.2.35)? Please confirm the version the live site reports, not just the version installed on the server.
These are the sources behind the summary above. Links open the publishers’ sites; I do not control their content.
Last checked against these sources on October 22, 2026. Security details change; the PHP advisory is the final word.
Start with the free check. Most people do not need anything more than that to know where they stand.
Send me your website address. I look at what the public site reports it is running, compare it with the current PHP security notices, and send you a one-page answer: your version, whether it is affected, and which version fixes it.
If your site does not reveal a version, the answer says so instead of guessing. No login, no scan, nothing changed.
If an update is needed, I do it under a one-page written approval: test on a copy where possible, schedule it around your hours, keep a way to undo the change, and give you before-and-after proof.
On shared hosting (the kind most small sites use), this is often a settings change in your hosting dashboard, not a rebuild. I price it that way.
A one-time fix drifts. I check your site on a schedule, apply or schedule the updates, and send a short report each quarter. You get a named person, a clear definition of what is covered, and something to show a board or a budget reviewer.
The work around the website: moving hosts, reviewing accounts and backups, evaluating a vendor, or writing down a system that only one person understands. Useful when you have outgrown your setup but do not have an IT person yet.
About half the websites I look at do not own a server. They sit on shared hosting, where PHP is a dropdown in the hosting dashboard your provider gives you. Changing it can take twenty minutes. I price it that way, and I will tell you if that is all you need.
The other half run their own server, often with nobody whose job includes reading security releases. The problem is the same: no one is looking at the version number.
Either way, you do not need a big project, a new dashboard, or a year-long contract to find out. You need one honest answer. The check is free because it is the fastest way to learn whether you have a problem — including when the answer is “you’re fine.”
Four steps, in this order, every time.
Email the address and who owns it. If you do not know who handles the technical side, say so — I will help you work out who to ask.
Before anything is touched, you get a one-page document naming the site and exactly what I may do. You sign it. See the template.
Where possible I test on a copy first, schedule the change around your business hours, and keep a way to undo it. You get the plan before the change, not after.
What I found, what I changed, what is left, and what to do next. Written for you and your board, not for another engineer.
If your question is not here, email it. There is no such thing as a dumb one.
Yes. PHP is the software many websites run on — think of it as the engine under the hood. You do not need to know how the engine works to know the car needs servicing. I will handle the technical part and explain what matters to you.
No. Looking at what your public site reports is the same kind of request your browser makes when it visits a page. No login, no password guessing, no exploit code, and nothing changed. If you hire me to fix something, you sign a written approval first.
It can expose a plugin or theme that was already incompatible. That is why I test on a copy where possible, schedule a maintenance window, and keep a way to undo the change. You get the plan before the change, not after.
WordPress runs on PHP, so a WordPress site can be affected. Updating WordPress itself does not update PHP.
Wix, Squarespace, and Shopify manage the server for you, so you generally cannot change PHP yourself. Ask their support whether this affects your site and what they have done about it. A free check can still tell you what your public site reports.
The check is free. Most shared-hosting fixes are $250–$450. Larger or self-hosted fixes are typically $750–$2,500. Ongoing quarterly checks are $150–$500 per month. You get a fixed price in writing before any work starts.
Then you get a one-page answer saying so, and you owe nothing. That is a good outcome, not a wasted conversation.
No. Most work is remote anywhere in the United States. On-site visits are available in New Jersey, eastern Pennsylvania, and northern Delaware.
No. If the fix is a five-minute settings change you can make yourself, I will tell you and send the steps. I would rather be the person you call next time.
In 2016 I was credited in Schoolbell and the Kingslayer, the RSA FirstWatch presentation at GoSec about a campaign that had infected roughly two thousand internet-facing servers by exploiting unpatched Java application servers.
The pattern is the same one in the news today: a public service, a version nobody checked, and a fix that had been available for months.
That is the work I do now, in PHP and the software around it. Not because the technology is exotic, but because someone has to look.
Send your website address and who owns it. You get a one-page answer: what your site reports, whether it is affected by the October 2026 PHP flaws, and what to do next. No obligation, no scan, no follow-up sequence.