If I were paying for a straightforward business website today, I would not choose PHP.
If the proposal starts with WordPress before anyone has asked what the business needs, I want the developer to justify that choice.
Being able to install a theme quickly is convenient for the developer. I care about what the business gets, including the work it will be left paying for after launch.
The PHP2Shell disclosures make that decision feel more urgent.
On October 21, PHP released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Under the right conditions, an attacker could execute code on an affected server without logging in. Both received a CVSS v4.0 score of 9.2 out of 10. PHP’s security advisory
If your site is affected, apply the update now. Planning a replacement is a separate job, and an exposed website cannot wait for a redesign.
Once the immediate problem is handled, the next conversation should be about whether this is still the right foundation for the business.
The vulnerable code sits underneath the application. Illustration based on Cloudflare’s explanation.
PHP runs the server-side code behind WordPress and many other websites. The application you recognize sits on top of it.
Wiz demonstrated unauthenticated remote code execution against deployments of WordPress, Drupal, and Joomla using their latest container images at the time of testing. It also demonstrated disclosure of process memory that could contain passwords, tokens, or API keys. Wiz’s research
A site did not need a badly written plugin to be exposed through the demonstrated PHP paths. Updating the application’s appearance or replacing a plugin does not patch the runtime underneath it. Cloudflare’s guidance
“We updated WordPress” is an incomplete answer to this incident. I want confirmation that the PHP process serving the website received the fix. That is the part a reassuring email needs to establish.
The two bugs involve memory that PHP handles incorrectly when a request goes wrong. One can leave partially initialized data that cleanup later treats as valid. The other can leave a worker holding a reference to freed memory, which a later request may use. The exact exploitation conditions depend on the deployment. Out-of-memory advisory, stale-state advisory
The PHP advisories describe different failure paths. Exposure and exploitability depend on the actual server configuration and application behavior.
The widely repeated claim that PHP powers roughly 70% of websites needs its qualification. W3Techs measures websites whose server-side language it can identify. That figure describes adoption, not how many websites have been hacked. W3Techs’ measurements
The history is uncomfortable enough without exaggerating the numbers.
The PHP Foundation says a developer encountered signs of the out-of-memory problem in 2024. Fixes brought difficult compatibility tradeoffs, and the work stalled before a route to remote code execution had been demonstrated. It calls the delay a “structural failure.” The Foundation’s account
I respect the Foundation for saying that plainly. It also makes “this has been running for years” a pretty weak argument for leaving an old installation alone.
Calif supplied a working proof of concept in August. Wiz describes AI helping researchers develop and adapt working exploits across different versions and memory layouts. Those accounts make it harder to assume that an old, difficult bug will remain impractical to exploit. Calif’s timeline, Wiz’s account
Sources: the PHP Foundation, Calif, Amazon, and PHP’s advisories. Amazon reported the October 17 attempt retrospectively. Its origin remains unclear.
For a business owner, the deeper problem is being sold a finished website without being told what keeping it healthy involves.
A site can look finished while carrying an old theme, several plugins, a database, and a hosting configuration nobody has reviewed recently. The person who built it may have moved on. Updates may be postponed because someone is worried they will break the layout.
If nobody can tell the owner who handles a security update, the handoff was not finished. Somebody left the difficult part for the customer to discover later.
Those are the situations where I would plan a move off PHP.
The cost of keeping the old site is more than its hosting bill. It includes time spent troubleshooting updates, uncertainty about what still works, and the disruption when a contact form or booking flow quietly stops doing its job.
WordPress’s own security guidance treats updates, plugin maintenance, hosting, backups, and recovery as continuing responsibilities. Installing it is the beginning of that work. WordPress’s hardening guide
If someone sells a new theme on the same neglected installation, with no plan for updates or recovery, and calls it a professional rebuild, I think that is bullshit.
The owner still cannot get a straight answer about who handles the next emergency. That is a failure in the work being sold.
Consider a site with service pages, a few case studies, occasional articles, and a contact form.
I would need a good reason to give that owner a live application and database just to assemble mostly fixed pages. Those pages can be generated ahead of time and served as ordinary files, with the form handled separately. That removes the need to run PHP to serve them.
Astro, for example, generates static pages by default and allows server rendering where it is needed. That is a useful starting point for a content-focused business website. Astro’s rendering documentation
I would pair that kind of approach with TypeScript and a straightforward way for the owner to edit content. If the project needs accounts, dashboards, or substantial application behavior, I would consider a React and TypeScript application with a backend designed for those requirements.
The choice should follow the work the site needs to do.
I apply the same standard to the stack I prefer. I can overcomplicate a website with React too. If the new proposal adds software the business does not need, it deserves the same criticism.
A modern framework still has dependencies to maintain. Putting a new frontend in front of the old PHP backend may leave much of the original maintenance problem in place. The rebuild has to remove something that was causing trouble and give the remaining system proper ownership.
For a substantial PHP application with an active team, reliable updates, and features that would be expensive to replace, I need a real business case before recommending a rewrite. My language preference is not enough.
For a straightforward business site buried in old plugins, I start with the opposite question. Why should the owner keep carrying all of that?
WordPress keeps getting treated as the default. I think that lets too many bad decisions escape scrutiny.
A business with five useful pages and a contact form should not inherit a plugin collection just because that is what its developer knows how to install. When changing a layout means working around a page builder, and updates get postponed because nobody knows what they will break, I want to know where all this convenience went.
The owner gets told, “You can manage it yourself.” But if they are afraid to click Update, that promise has not amounted to much.
A fresh theme does very little for that situation. The screenshot changes. The runtime, database, and neglected maintenance are still underneath it. I would not expect the next year to go much better just because the homepage looks different.
Moving away still needs care. The contact form has to work, the owner still needs to edit the content, and existing URLs need an inventory and appropriate redirects. Google’s guidance covers URL mapping and monitoring. Search traffic can fluctuate during a move, so replacing WordPress is not a reason to skip that work. Google’s site-migration guidance
A React logo does not settle this either. If the replacement leaves the owner with a different pile of software they cannot operate, I have the same objection.
While that replacement is being planned, the existing PHP installation still needs attention.
For the original two PHP2Shell vulnerabilities, the first fixed upstream releases are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Distribution packages may contain backported fixes, so check the vendor’s security notice. PHP’s update instructions
PHP also issued separate guidance on October 23 for CVE-2026-115560, a narrowly conditional session-upload-progress issue awaiting a regular bugfix release. Its notice describes the affected configuration and recommends disabling session upload progress while waiting for the fix. That is additional guidance alongside the original patches. PHP’s follow-up notice
The current server needs a verified fix, and any evidence of compromise needs investigation. A future migration does not clean up an existing intrusion. NCSC guidance
PHP2Shell is a reason to patch immediately. For a simple business website, it is also a reason to ask why this much server software needs to be involved in showing a few pages.
“WordPress is what everyone uses” would not convince me. Neither would “the theme looks modern.” I want to hear why the business needs this setup and why keeping it is worth the maintenance.
If nobody can give a better answer than “that is how we have always built websites,” I think it is time to stop building them that way.