If your business website mainly explains what you do and helps customers contact you, today's PHP security disclosure is a good reason to reconsider the machinery behind it.
On October 21, 2026, PHP released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. They can allow attackers to execute code on vulnerable servers without logging in. PHP's maintainers say installations serving web requests are at risk, with the highest risk in Apache's mod_php configuration. Read the official PHP advisory.
For a business owner, the immediate job is getting the server patched. The longer-term question is whether your website needs PHP at all.
Keeping WordPress updated doesn't cover everything underneath it
WordPress depends on PHP and a database. Updating WordPress, its themes, and its plugins is part of maintaining that system, but the PHP runtime needs its own security updates. WordPress documents those hosting requirements.
Today's disclosure makes that distinction particularly important. PHP's researchers demonstrated an attack against mod_php that can happen before the website's application code starts running. A WordPress security plugin cannot be assumed to protect a request that reaches the vulnerable code before WordPress loads. See the technical advisory.
That doesn't mean every WordPress site has been compromised. Exposure and exploitability depend on the server's version and configuration. It does mean that a reassuring row of “up to date” messages in your dashboard isn't confirmation that your hosting environment is patched.
Ask your host to confirm that it has applied the fixes. PHP released patched versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12; some hosting providers and operating-system vendors supply equivalent backported fixes. PHP's update instructions explain the options.
Don't delay that work while planning a redesign. European cybersecurity authorities recommend considering isolation from public networks when immediate remediation isn't feasible. Read ENISA's guidance.
Your service pages may not need a live application
A restaurant's hours, a contractor's project gallery, or a consultant's services page can be built ahead of time and delivered as finished files.
That's what a static website does. The web server sends the page that already exists, without needing PHP to assemble it from a database for each uncached visit. MDN explains the difference between static and dynamic sites.
For a suitable business website, moving to that architecture removes several things from the public site: the WordPress installation, its PHP plugins, its login screen, and its need for a database to generate pages.
The security benefit follows from what you've removed. A public site with no PHP runtime cannot be attacked through these PHP runtime flaws. There is no WordPress administrator account to break into if WordPress is no longer there.
That's a compelling trade for a business that needs customers to read its services and request a quote.
Static pages can still have polished design, mobile navigation, galleries, and browser-based interactions. Content changes mean updating and publishing the files. Booking, payments, and forms can connect to separate services, each with its own security responsibilities.
A store with complex checkout logic or a membership application needs a more detailed plan. The case for moving is strongest when the website's needs are simpler than the system currently running it.
The migration needs to remove the old exposure
Putting a cache in front of WordPress doesn't retire WordPress. Exporting static pages while leaving the old installation publicly accessible doesn't finish the job either.
A complete move needs to account for the old hosting environment, admin URLs, staging copies, and any PHP scripts still processing requests. A forgotten contact-form handler can leave PHP in the picture even when every visible page is static.
No website has “no vulnerabilities.” Hosting accounts, domain access, third-party scripts, publishing tools, and connected services still need protection. The practical goal is a smaller attack surface and fewer components that require urgent patching. WordPress's own security guidance describes security as reducing risk, rather than eliminating it. Read its hardening guide.
SiteLift can help you move beyond WordPress
SiteLift can convert your current business website to static pages with no PHP required to run the site or process its forms. We start with the site you already have, preserve what works, and replace the machinery it no longer needs.
I've handled several of these migrations in recent weeks. The useful question is what the business needs its website to do, and how much software is actually necessary to do it.
The first step is deciding what needs to come across: your pages and images, the URLs customers already use, and the features that help people contact you. A migration plan should also cover search metadata, redirects where addresses change, and how future content updates will work.
Contact forms still need somewhere to send submissions. We can handle that with a small non-PHP backend while the pages remain static. The migration includes the remaining handlers and background jobs, so an old form script doesn't quietly keep PHP in service.
That backend still needs validation, spam protection, secure credentials, and reliable delivery. Removing PHP eliminates the PHP dependency; it doesn't make every other part of a website immune to security problems.
SiteLift's process is straightforward: share your current site, agree on the scope, review the rebuild, and approve it for launch. Hosting and ongoing management are part of the service, with the details confirmed in your agreement. See how SiteLift works.
Your website should help customers find you, understand your business, and take the next step. If WordPress has become more maintenance than your site needs, send SiteLift your current website and let's look at what it would take to move.