The PHP cyber vulnerability at the centre of the October 2026 headlines is a code execution flaw that site owners fix by updating PHP, not by changing user passwords. PHP's maintainers shipped patched releases, and the published advisory rates the worst variant at CVSS 9.8, so the work is to confirm which version your host runs and whether it has been updated.
PHP cyber vulnerability: what was disclosed and what fixed it
The PHP cyber vulnerability is a flaw in the PHP programming language's own code, corrected by updating PHP on the server to a release named in the official security advisory. PHP is a scripting language that generates most WordPress pages, so the fix belongs to whoever controls the server version, not to the person browsing the site.
The official record is the PHP project's security advisory page, where each entry lists affected version branches, the fixed releases, and a CVE identifier. A CVSS score of 9.8, as reported in mainstream coverage, describes severity under a scoring system run by FIRST, a nonprofit that maintains the CVSS standard: a high score means the flaw is easy to reach and damaging if exploited. It does not tell you whether your site is exposed.
That is the distinction the radio coverage blurred. Will Guyatt, a technology journalist speaking on Times Radio on 22 October 2026, described it as "a deep vulnerability in code" that had been present for some time before being found. "You need to update your version of PHP on your server to the latest version in order to stop this from happening," he said.
Readers should treat the specific exploit mechanics cautiously. This article does not claim to know which attacker technique was used, and any site owner relying on this piece should read the PHP advisory itself for the technical detail rather than a secondhand summary.
Which PHP versions are affected and is a patch available?
A patch is available only for PHP branches the project still supports, so the answer depends on which branch a server runs. PHP's maintainers publish supported versions on the project's releases page and document the support timeline in the PHP manual, which states each branch's end-of-life date.
The practical consequence is a three-way split. Fully supported branches receive fixes. Older branches may have received a fix if they were still in security-support at the time. End-of-life branches receive nothing at all, and a site still on one is exposed until the host moves it.
Guyatt made the same point on air: "In theory, older systems and services that haven't been patched, haven't been upgraded and people haven't taken those steps would be at risk." That scoping matters because a blanket claim that "70% of websites" are vulnerable, a figure he repeated from news coverage, describes the share of sites that run PHP at all rather than the share exposed to this flaw.
| Server situation | What it means for this flaw | Next step |
|---|---|---|
| Supported PHP branch, updated | Fixed release installed | Confirm the version with the host |
| Supported branch, not yet updated | Patch exists but is not applied | Apply the update or ask the host |
| End-of-life branch | No further fixes from PHP | Migrate to a supported branch |
| Managed platform | Host controls the version | Ask the provider directly |
Does WordPress or your hosting provider handle the update?
Managed hosting providers control the PHP version, so the site owner's job is to ask the provider a direct question rather than to patch code. Guyatt described exactly this friction on air: WordPress advice pointed users back to "their individual provider", leaving owners to work out whom to contact.
That answer is not evasion. A WordPress install runs on a PHP interpreter supplied by the server environment, and hosts configure updates, staging, and rollback. If you pay for a managed plan, the version is theirs to change and yours to verify.
Here is a short list for that conversation:
- Ask which PHP version the site currently runs and when it was last changed.
- Ask whether that version received the fix from the official advisory.
- Ask for the migration date if the site is on an end-of-life branch.
- Ask whether a staging copy exists for testing before the live switch.
- Keep the reply in writing so later incidents have a record.
Self-managed server owners have a different route: package updates for the site's own PHP installation, followed by a check that the web server is loading the new version rather than an older one left on disk.
How to tell whether your own site is patched
You can tell whether your site is patched by checking the PHP version your server reports, not by checking the site's front page. A healthy-looking storefront says nothing about the interpreter behind it, and that gap is the most common reason site owners assume they are safe when they are not.
The quickest check is the host's control panel, which usually shows the active PHP version per site. If you cannot find it, the host's support team can confirm it. Compare whatever you find against the fixed releases in the PHP advisory and against the support timeline in the PHP manual.
A temporary public version check, where a diagnostic file prints the running version, works but must be removed afterwards. Leaving it in place advertises your software stack. Page-caching layers also need clearing after an update so the new interpreter actually serves requests.
Guyatt said network administrators were "working late into the night last night patching servers and systems" and that "the shock announcement worked in a way". A prompt that produces an update is the outcome to aim for; the unresolved risk sits on sites nobody has checked.
What should ordinary shoppers do about the PHP cyber vulnerability?
Ordinary shoppers have very little direct action to take on this PHP cyber vulnerability, because the flaw lives on servers. The reasonable response is to watch saved payment cards and account activity over the following weeks and report transactions or logins you do not recognise.
Guyatt declined to shop online that day himself, then set a limit on the advice: "I don't want to turn this into a absolutely unbridled panic because this warning has largely worked." Asked about deleting stored card details, he said he would not now remove them, several days into the disclosure.
He did not call any specific retailer safe. That restraint is worth keeping. Amazon was reported as a target in coverage, but being targeted is a categorisation of attempted attack, not a measurement of data taken.
Bank and card protections still apply. A card issuer's chargeback process and fraud monitoring exist precisely for incidents you did not cause, and using them promptly is more useful than a password change that cannot reach a server-side flaw.
Consumer hygiene: patch fast, mind passwords, skip borrowed advice
The durable habits from the interview are short: install security updates promptly, use distinct passwords with multi-factor authentication, and ignore confident strangers on social platforms. None of these prevents a server-side flaw, and all of them limit the damage from the breaches that follow one.
Guyatt's rule on updates is blunt. "If a company tells you to update your computer or update your security system, your phone, should you always click the update?" he was asked. "Yeah, lots of in the chat, yes, is the simple answer," he replied, adding that he installs on day one when a security update arrives.
On passwords he was less hopeful. "You could change your password as many times as you want, but if a company haven't updated their privacy" then user effort does little, he argued, pointing to breaches where trivial passwords appeared on a national database.
Both hosts, Kate McCann and Stig Abell, said the official guidance was hard to parse. McCann noted social media filled the gap with accounts predicting either nothing or catastrophe. That is a search problem as much as a security one, and going to the advisory and the host's reply beats the timeline.
FAQ
- Is the PHP cyber vulnerability fixed?
Fixes were published in supported PHP branches, and the official advisory lists the exact releases. Servers on those releases are covered; servers on end-of-life branches are not and need migration.
- Do I need to change my passwords because of it?
Not as a first response. The flaw is server-side, so changing consumer passwords does not close it. Watching account activity and enabling multi-factor authentication remain sensible habits regardless.
- Are WordPress sites automatically safe?
No. WordPress runs on PHP supplied by the hosting environment, so safety depends on whether that host installed a fixed release. Ask the provider which version is running and when it last changed.
- What does a CVSS score of 9.8 mean?
CVSS is a severity scoring system maintained by FIRST. A 9.8 rating describes how reachable and damaging the flaw could be, not how many sites are actually exposed. Enrollment depends on whether a server runs an affected version.
- Should I avoid online shopping?
The interviewee chose to for a day while patching was under way, then advised against panic and against deleting stored payment details days later. Watching transactions for unusual activity was his practical recommendation.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits