Loading
Flaws in PHP itself, disclosed on 21 October 2026, let an attacker run their own code on a web server with no login. Versions from PHP 5.4 through 8.5 are affected, and a third issue found days later still has no fix. Tell us what you run and we'll tell you where you stand — same day, anywhere in the world.
On 21 October 2026 the PHP project released fixes for two vulnerabilities, together nicknamed PHP2Shell. The PHP project rates both 9.2 out of 10. Both allow remote code execution without authentication, which in plain terms means an attacker who has never had an account on your system can make your server run their instructions.
The flaw is in PHP itself, not in any single application, so it does not matter whether your portal is WordPress, Drupal, Laravel, Magento or something written for you fifteen years ago. If it runs PHP and the internet can reach it, it is in scope. PHP parses an incoming request before your application code runs, so your login page never gets the chance to stop it.
Then on 23 October the PHP project disclosed a third related issue, CVE-2026-115560, which affects even fully updated installations. There is no emergency fix for it. PHP has published an interim setting instead, and recommends it for everyone until the next routine release.
How worried should you be?
Serious, but not yet a catastrophe — and that is the window you have.
Attacks began on 17 October, four days before the public announcement, and scanning since has been heavy and worldwide. But a reliable, general-purpose attack tool is not yet circulating publicly: the ones that exist only work against particular combinations of operating system, PHP version and web server.
As of 24 October 2026 no organisation has been publicly confirmed as breached through it, and one firm withdrew a claim that there had been. That will not stay true indefinitely, which is the argument for moving now rather than panicking later.
Which PHP versions are affected? Every branch from PHP 5.4 through 8.5. What differs is whether a fix exists for yours.
Your hosting panel will show your PHP version, or an administrator can run php -v on the server. If nobody can tell you which version you are on, treat that as its own warning sign.
PHP 8.5
Fix available
Update to 8.5.12, then restart your web server or PHP workers.
PHP 8.4
Fix available
Update to 8.4.27, then restart your web server or PHP workers.
PHP 8.3
Fix available
Update to 8.3.36, then restart your web server or PHP workers.
PHP 8.2
Fix available
Update to 8.2.35, then restart your workers. Note that PHP 8.2 itself stops receiving security fixes on 31 December 2026, so plan the next move now.
PHP 8.0 – 8.1
Limited options
Past end of life, so there is no normal release. The PHP security team published a minimal source patch that has to be applied and compiled by hand, and some Linux vendors ship their own build. The US cyber agency's advice for 8.1 and earlier is blunt: if you can't patch, take the system off the internet.
PHP 7.4
Limited options
Past end of life. A hand-applied source patch exists and nothing else. It buys you time; it is not a supported platform.
PHP 7.0 – 7.3
No fix exists
End of life with no fix of any kind. These systems cannot be made safe by patching. Restrict who can reach them now, and move them.
PHP 5.x
No fix exists
End of life with no fix, and years behind on every other known vulnerability. Treat any internet-facing PHP 5 portal as urgent.
Version guidance above reflects the position on 24 October 2026. Confirm the current fixed release for your platform with your Linux distribution or hosting provider before you deploy.
Installing the update is the part everyone does. These are the parts being skipped — and any one of them can leave you exposed while you believe you are finished.
Updating the package on disk does not replace the PHP already loaded into running processes. Until you restart Apache, PHP-FPM or your container, the vulnerable code is still serving traffic. This is the single most common mistake being made this week.
Linux distributions and hosting vendors received the fix early and often backport it without changing the version string, so a site that looks unpatched may be fine. The reverse also happens: the command-line PHP version can differ from the one serving your website. Check the vendor changelog, not just the number.
On 23 October the PHP project disclosed a further issue, CVE-2026-115560, which affects even fully updated versions including 8.5.12. It will not get an emergency release. PHP's own recommendation, for everyone, is to turn off session upload progress (session.upload_progress.enabled=0) in your main configuration until the next routine update. It has to be set in global php.ini, an FPM pool or server config — setting it inside the application is too late to help.
One of the flaws can read live server memory and hand it back in a response, and researchers have shown that can include passwords, tokens and API keys. No national agency has issued a formal rotation instruction, so treat this as prudence rather than official guidance — but patching cannot undo a read that already happened. If you do rotate, patch first: a credential changed before the fix lands can be read the same way.
Capping memory with ulimit -v
Actively harmful. PHP, CERT-EU and several vendors warn this makes memory allocation fail in exactly the way the attack depends on. Use cgroup limits instead if you need them.
Updating WordPress, Drupal, Magento or your plugins
Does nothing here. The flaw is in PHP itself, underneath your application, so a perfectly up-to-date site on an unpatched PHP is still exposed.
Hiding error messages
No protection at all. One working exploit actually requires errors to be hidden — the normal production setting. Quiet logs are not evidence that you are safe.
Relying on your login page
PHP parses the incoming request before your application code runs, so application passwords and permissions never get a chance to block it.
The danger is measured in days. Replacing an ageing portal properly takes weeks. Anyone who offers you only one of those is solving half the problem.
Step one · hours
Stop the bleeding on what you have, before anything is rebuilt.
Step two · weeks
Rebuild on current technology without losing your data or stopping your operations.
This is the fear that keeps organisations on software they know is unsafe: that moving means losing years of records, or going dark while it happens. It doesn’t have to, and here is exactly how we avoid it.
Every record, document and attachment moves across, including the history. We migrate in rehearsals first, reconcile the new system against the old one row by row, and show you the comparison before anyone switches. Nothing is retyped and nothing is left behind.
We migrate a PHP portal without downtime: we do not take it down for months and hope. The existing system keeps serving users while the replacement is built alongside it, so your staff and your customers carry on as normal throughout.
One area at a time — a login, a form, a reporting module — each released only when it is proven. If something behaves unexpectedly, we put that piece back the way it was the same day, rather than unwinding an entire launch.
Existing web addresses continue to work, so search rankings and the links people have bookmarked or published are preserved. Accounts stay valid, and the other systems you connect to keep talking to you through the move.
We keep the workflows your staff already know unless there is a good reason to improve them, and agree those changes with you first. Retraining everyone is a cost, and it should be a choice rather than a side effect.
The assessment comes first: what you run, what it would take to move, what it costs and in what order. You decide whether to go ahead with the real numbers in front of you, not a sales estimate.
Our tooling maps a large legacy codebase, its dependencies and its risky patterns in hours rather than the weeks a manual audit takes. That is what lets us answer quickly, anywhere in the world. Nothing reaches your production system without being reviewed and approved first — the same standard we build into VirgoOS, our own governed AI platform.
Send us the form below and you get a straight answer on where you stand, not a sales call. We work remotely across India, the Gulf, Europe, the US, South East Asia and Australia, so the time zone is not the obstacle.
If your system looks compromised, patching is not the first task, and we will say so. A confirmed breach needs specialist forensic investigation and, in most jurisdictions, disclosure to a regulator within a fixed window. We can help you preserve evidence, stabilise and rebuild — but we will point you to the right specialists rather than pretend that part is ours.
Neither of these attempts the vulnerability against your server — that would be unauthorised testing, and we won’t do it to anyone. One asks you three questions; the other reads what your server already tells every visitor.
Nothing is sent anywhere and nothing is scanned — this runs entirely in your browser.
We read only what your server tells every visitor — the same headers your browser receives. We never probe it and never attempt the vulnerability.
Neither check touches your system in any way that could disturb it, and neither needs credentials. Never give anyone passwords or keys to run a security check — including us.
Want a person to look properly? Send us the result and we’ll come back the same day with where you actually stand.
No charge, no obligation, and no sales call unless you ask for one. You get a plain answer: whether you are exposed, what to do first, and what it would take to fix properly. If the answer is “your host has already handled this”, we will tell you that too.
If something is actively wrong right now, don’t wait on a form — email business@thewmad.com or call +91 7093180303.
PHP2Shell is the nickname given to the October 2026 PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026 and rated 9.2 out of 10 by the PHP project. They let an attacker with no account and no password run their own code on a web server. Because the flaw is in PHP rather than in any one application, it affects sites built on WordPress, Drupal, Laravel, Magento and custom code alike. A third related issue, CVE-2026-115560, was disclosed on 23 October and is not yet fixed.
Your hosting control panel usually shows it, or an administrator can check with phpinfo(). Be careful with the command line: the PHP used by your website can be a different version from the one you get in a terminal. And because many Linux vendors backport the fix without changing the version number, a scary-looking version is not proof you are exposed — check your vendor's changelog.
Not quite, and this is where most people stop too early. First, restart your web server or PHP workers — until you do, the old vulnerable PHP is still loaded and serving traffic. Second, apply PHP's interim setting for the third flaw, which still has no fix. Third, if your server was reachable before you patched, treat any passwords, tokens and API keys in its memory as potentially exposed and plan to rotate them.
You are in the group most at risk, and you are far from alone: end-of-life PHP is still everywhere. Independent scans put the share of internet-facing PHP running an unsupported version somewhere between roughly 71% and 79%. The immediate step is to reduce exposure: restrict who can reach the system, put it behind a filter, and take anything non-essential off the public internet. The US cyber agency's advice for PHP 8.1 and older is simply to take it offline if you cannot patch it. The real fix is moving to a supported platform, which is the work we do.
Scanning and attack attempts have been heavy and worldwide, starting four days before the flaw was made public. But as of 24 October no organisation has been publicly confirmed as compromised through it, and one security firm retracted an earlier claim that there had been. Several agencies say they have seen attempts but no successful exploitation. We would rather tell you that plainly than frighten you with something unproven.
No. Your records, documents and history all move across, and we prove it before you switch: we rehearse the migration, then reconcile the new system against the old one and show you the comparison. The existing portal keeps serving users the whole time, because the replacement is built alongside it and switched over a piece at a time, with each piece reversible the same day. Existing web addresses keep working, so bookmarks, published links and search rankings survive the move.
Triage the same day. We read every enquiry and come back with where you stand and what we would do. Hands-on work starts once scope and access are agreed with you, which for an urgent case is usually the following working day.
No. The exposure check is open to anyone, any size, anywhere. Our paid work is strongest where the system carries real weight — government and civic portals, healthcare, financial services, manufacturing and education — because that is the engineering we specialise in.
Yes, and we think you should insist on it from anyone you hire for this. You get a written record of every system found, every change made, every credential rotated and anything still open, in a form you can hand to an auditor, a board or a regulator.
Almost certainly not. The UK's National Cyber Security Centre has warned that criminals are impersonating IT providers, hosting companies and even the agency itself with fake urgent-patch messages. We will never send you a patch file or ask for your passwords. If you are unsure whether a message is from us, call us on the number on this site before acting on it.
This page summarises public reporting as of 24 October 2026. It is general information, not advice specific to your system — check your own platform before acting.
Related: legacy platform modernisation · how we handle your data