A fresh coat of paint does not replace an old lock. Photo via Pexels.
On 17 October 2026, a decoy server Amazon runs to catch attackers (a "honeypot") logged someone trying to exploit a PHP flaw that had not yet been publicly disclosed. Amazon says it is still unclear how the attacker got the details before disclosure. Four days later, on 21 October, PHP shipped the fix.
The flaw is called PHP2Shell. If your company website runs on WordPress, it runs on PHP, and this flaw is in PHP itself rather than in a plugin or theme.
Every WordPress owner needs to patch PHP this week; that part is not optional. The bigger choice comes after.
You can keep patching PHP each time a new flaw lands, which is quick, though sites on PHP 8.1 or older first need a vendor backport or a version upgrade. Or you can take PHP off the public website altogether. That takes weeks, not days, and suits small brochure sites and multilingual sites tired of urgent updates, because there is no PHP left to attack. We recently helped a client exposed to PHP2Shell do exactly that, and we share the story below, along with how to fix PHP2Shell now and how to decide whether to migrate.
What is PHP2Shell?
PHP2Shell is the name for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (CVE numbers are the public tracking IDs for security flaws). The PHP project rates both critical, at 9.2 on CVSS v4.0, a 0 to 10 severity score. PHP says they "can allow unauthenticated remote code execution".
In business terms: an attacker who has never logged in to your site may be able to make your web server run their commands. Whoever can do that can often change your pages and reach data stored on the server, such as enquiry-form submissions.
Two details make this one unusual.
It sits inside PHP itself. PHP says the at-risk group is "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed". That list covers the common hosting setups, so shared hosting is very likely included.
A well-built theme does not protect you.
It can fire before your site's code even runs. PHP rates the risk highest for Apache with mod_php (a common setup where PHP runs inside the web server itself), "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs".
Security plugins run inside your site's code, so on this path they come too late.
The two bugs are technical, but the shape is simple:
- Bug one: PHP runs out of memory halfway through setting up a request, then treats half-built data as valid.
- Bug two: leftover data from one request survives into the next request handled by the same PHP process.
PHP says both can allow unauthenticated remote code execution, and its advisory for the second bug says a carefully crafted heap layout can produce full remote code execution.
How did PHP2Shell happen?
The bug is old. One research team found that at least one affected code path dates back to PHP 5.4.0, a branch PHP retired in 2015. Old, widely deployed code can hide serious bugs for a long time.
What changed is how they were found. Security firm Calif reported the first bug to PHP on 11 August 2026, and says no special test setup or non-public AI models were needed for the initial discovery.
Wiz Research confirmed in testing that the attack works against WordPress and Drupal without logging in. It found its first bug on 19 August using AI-assisted tooling.
The disclosure itself followed the responsible route:
- A private report to the PHP security team on 11 August, followed by further findings
- A pre-announcement on 20 October
- Patched releases on 21 October, with Linux distributions given the patches in advance
- A public proof-of-concept exploit (working attack code anyone can copy) posted on 22 October to Exploit-DB, a public archive of such code
Has anyone actually been hacked this way? The evidence is mixed.
As of 23 October: Amazon saw an attempt dated 17 October and several proof-of-concept exploits, the earliest around 02:00 UTC on 21 October, but says it is "unclear if any of these attempts would have succeeded in real-world systems".
Cloudflare reported attack traffic against its customers. Canada's Cyber Centre said on 21 October that no active exploitation had been identified, "but that can change quickly".
As of 23 October we had not found PHP2Shell on the US CISA list of known exploited vulnerabilities, and our search turned up no advisory from MyCERT, Malaysia's national computer emergency response team. Check both for updates.
Our read: AI-assisted tooling is making old bugs cheaper to find. Expect more of these.
PHP2Shell targets the server software, not your website's design. Photo by panumas nikhomkhai via Pexels.
Is your WordPress site affected by PHP2Shell?
Start with your PHP version, with one catch. Linux distributions and long-term-support vendors received the patches in advance, and their patched packages may keep an older version number. So if your host or distribution supplies PHP, ask whether their PHP2Shell update is installed.
If PHP comes straight from the PHP project:
- PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and newer: patched against PHP2Shell.
- Older releases on 8.2 to 8.5: exposed until you update.
- PHP 8.1 or older: exposed, with no official fix. PHP says "PHP 8.1 and older no longer receive updates from the PHP project."
If you are on 8.1 or older, ask your host whether they have installed a backported fix (the patch copied onto your older version). PHP also published source patches for 7.4 to 8.1, but those are for teams that build PHP themselves. Amazon's security bulletin is blunt about PHP 5.4 to 8.1: "Migration to a supported branch is required."
How common is that? As of October 2026, PHP runs on 69.3% of websites whose server language W3Techs can identify, and WordPress powers 39.6% of all websites.
By our own arithmetic from WordPress.org's published PHP statistics, roughly a third of WordPress installs report a PHP version that php.net lists as end of life, meaning it no longer gets security fixes. Treat that as an estimate.
The window is closing on the next version too. PHP 8.2 "will receive no further security fixes" after 31 December 2026. A site patched to 8.2.35 this week is safe from PHP2Shell, and unsupported again in ten weeks.
How to fix PHP2Shell: four steps, and five questions for your developer
Step 1. Check your PHP version. In WordPress, go to Tools, then Site Health, then Info, and open the Server section, which lists your server's PHP details. On a server you manage, run php -v. OpenAI has also published a free php2shell-checker that reads the version a site reports and sends no exploit probes.
Step 2. Update PHP. On a Linux server, install your distribution's updated PHP package, then restart PHP-FPM or Apache. On shared hosting, ask your host to confirm the PHP2Shell update is installed.
Step 3. Apply the temporary setting only if you cannot update yet. Details are in question 3 below.
Step 4. Check your logs. Amazon advises investigating from at least 17 October, looking for POST requests carrying PHP_SESSION_UPLOAD_PROGRESS.
If someone else runs your website, ask your developer or hosting company these five questions.
1. Which PHP version is running, exactly, and does it include the PHP2Shell fix? Not "PHP 8". The PHP project's patched releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; a vendor's patched package may carry a different number.
2. If it is 8.1 or older, what is the plan? Either a vendor backport you have confirmed in writing, or an upgrade to a supported version. Next quarter is not a plan.
3. Has the temporary setting been applied? Until patching, PHP suggests setting session.upload_progress.enabled=0 in the server configuration and restarting every PHP worker (the background processes that run your site). It says not to rely on ini_set() or FPM .user.ini for this.
PHP warns this "blocks the confirmed session paths but not other variants". It lowers the risk, but other attack variants still get through.
4. Is a firewall the only protection? A web application firewall (a filter that blocks suspicious traffic before it reaches your site) helps. Cloudflare switched protection on by default for its firewall customers, and still says "Customers should patch their PHP". AWS says its own firewall rules for PHP block CVE-2026-109619 but do not target CVE-2026-109618.
5. Has anyone checked the logs since 17 October? Amazon advises investigating from at least that date, looking for POST requests carrying PHP_SESSION_UPLOAD_PROGRESS.
PHP's own summary is the one to remember: "There are no complete mitigations, updating is the only safe choice."
What a hacked website costs the business
When a site is compromised, the server is rarely the expensive part.
Google warns your customers away. Google shows "This site may be hacked" in search results when it believes a hacker may have changed pages or added spam pages. The label stays until the owner fixes the site and asks for a review.
That review "can take from a few days to a few weeks", and cleaning up only some pages "will not earn you a partial return to search results". For a business that gets its enquiries from Google, that can be days to weeks of lost leads.
Malaysian law now expects you to report breaches. If the server holds personal data, such as enquiry forms or customer records, the PDPA has required breach notification since 1 June 2025.
The Act says the Personal Data Protection Commissioner must be told "as soon as practicable". Failing to notify carries a fine of up to RM250,000, up to two years' imprisonment, or both. Treat this as a starting point, not legal advice.
Breaches are expensive even when they start small. IBM's 2026 study puts the average cost of a data breach at USD 4.99 million globally and USD 4.12 million in ASEAN, though the ASEAN figure is based on only 26 organisations.
Those are averages across all kinds of breach. A website incident at a smaller company is likely to cost far less, but it is not free.
The longer fix: WordPress migration off PHP
Patching closes this hole. It does not change the fact that a WordPress site is a PHP program answering every visitor, and every PHP version reaches end of life four years after release. PHP2Shell will be patched. The next PHP flaw will need patching too.
This month: a client exposed to PHP2Shell
This is not theory for us. Recently, a client's WordPress website was exposed to PHP2Shell. We are not naming them, because this is a security matter.
Patching PHP would have closed this one flaw and left them waiting for the next. Instead, we helped them migrate the public website to Next.js. The live site is now ready-made files with no PHP running behind it, so PHP2Shell has nothing to attack there, and neither will the next PHP flaw.
An earlier migration: a three-language corporate site
The same reasoning, plus a goal of lower maintenance overhead and long-term running cost, is behind a WordPress migration we completed earlier for another client, a company with a three-language corporate website.
Before: a WordPress site, with pages generated by PHP on the server. A WordPress site is kept safe by updating PHP, WordPress, the theme and every plugin.
After: the public site is built with Next.js (a framework that can turn a website into ready-made files) as a static export and served from Cloudflare Pages. Content in English, Chinese and Malay is managed in Strapi, a headless CMS (an editing system kept separate from the public website). The public site is built into plain HTML, CSS and JavaScript files.
There is no PHP on the public website at all, so PHP2Shell has nothing to attack there.
A migration is planned work, done once, instead of emergency repairs every few months. Photo by Darya Sannikova via Pexels.
What changed for the business:
- Maintenance can be planned. The maintenance plans we proposed cover Strapi and Next.js dependency updates, plus a security advisory when something relevant appears. A new PHP or WordPress plugin flaw is no longer this site's emergency.
- Visitors only ever receive pre-built files. The editing system is a separate service, not the thing answering public traffic.
What a static site does not fix
A static site with a headless CMS is not "unhackable", and anyone who says so is selling something. Three caveats from our own work:
- The CMS still needs patching. Strapi publishes its own security advisories, including two rated critical in May 2026. The difference is that the admin panel can run away from the public site, so a flaw in it does not sit behind every page view.
- Static sites trade away some features. Anything that needs a live server on each request, such as member logins, has to be designed differently.
- Migrations break URLs if you are not careful. In this project, some old product URLs that Google had indexed returned 404 after launch, because the new structure dropped a category segment. We fixed them with redirects. Map every old URL before you switch.
Old PHP versions are locks nobody repairs any more. Photo via Pexels.
Patch or migrate: which fits your site
If your site is five pages or fewer, rebuilding it without PHP may cost less than years of urgent patching. If you also want ongoing SEO, our 12-month AI SEO Growth and Managed plans include a five-page Business website (normally RM3,000). We build on Next.js, not WordPress, so there is no WordPress or PHP to patch on it. See our AI SEO plans and the free website offer.
If your site is bigger, multilingual, or needs your team to edit content themselves, like the client above, talk to us about a WordPress migration. We will check your PHP exposure first, then quote the move. For typical costs and timelines, see our WordPress migration guide.
PHP2Shell FAQ
What is PHP2Shell?
PHP2Shell is the name for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. The PHP project rates both 9.2 on CVSS v4.0 and says they can allow unauthenticated remote code execution, meaning an attacker who never logs in may be able to run commands on the web server.
How do I fix PHP2Shell?
Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, released on 21 October 2026, and restart every PHP worker. If your host or Linux distribution supplies PHP, its patched package may keep an older version number, so ask whether their PHP2Shell update is installed. The PHP project says there are no complete mitigations and updating is the only safe choice. If you are on PHP 8.1 or older, there is no official update: confirm a backported fix with your hosting or Linux vendor, or move to a supported PHP version.
Is WordPress affected by PHP2Shell?
Yes, if it runs on an unpatched PHP version. The flaw is in PHP, not in WordPress, themes or plugins, so updating WordPress or a security plugin does not fix it. Wiz Research confirmed unauthenticated remote code execution against WordPress in testing.
Is there a temporary workaround for PHP2Shell?
Until you can patch, PHP suggests setting session.upload_progress.enabled=0 and restarting every worker. PHP says this blocks the confirmed session paths but not other variants, so it reduces risk and is not a fix. A web application firewall helps, but Cloudflare itself tells customers to patch PHP even with its protection on.
Is PHP2Shell being exploited?
Reports differ by source and date. Amazon found an exploitation attempt dated 17 October 2026, before public disclosure, but says it is unclear whether such attempts would have succeeded on real systems. Cloudflare reported attack traffic against its customers. Canada's Cyber Centre said on 21 October that no active exploitation had been identified at that time. A public proof-of-concept exploit was published on 22 October.
Does moving from WordPress to Next.js remove the PHP2Shell risk?
For the public website, yes: a Next.js static export is served as plain HTML, CSS and JavaScript files, so there is no PHP running for PHP2Shell to attack. It does not make a site unhackable. A headless CMS such as Strapi still needs its own security updates, and its admin panel should be kept away from the public site.
Sources
- PHP project: PHP 2026 security release notes, supported versions, end-of-life versions and GHSA-6wmf-4rv5-p3rp
- Researchers: Calif and Wiz Research
- Exploitation: Amazon Threat Intelligence, AWS bulletin 2026-143, Cloudflare, Canadian Centre for Cyber Security, AWS WAF mitigations, OpenAI php2shell-checker, Exploit-DB 52704, CISA KEV catalog
- Usage: W3Techs PHP, W3Techs WordPress, WordPress.org PHP statistics
- Impact: Google "This site may be hacked", Google Search Console security issues, IBM Cost of a Data Breach, IBM ASEAN 2026, PDPA (Amendment) Act 2024, PDPA commencement order
- Architecture: Next.js static exports, Strapi security advisories, WordPress Site Health
Free consultation
Not sure whether your website is exposed to PHP2Shell?
Tell us your website address. We will check which PHP version it reports and what that does and does not tell you, explain your options in plain English, and quote a patch or a WordPress migration in RM.
