Critical PHP Exploit: How We Responded to Protect Our WordPress Clients
Most business owners don’t spend much time thinking about the technology running behind their websites. And they shouldn’t have to.
But when a critical security vulnerability is discovered in a technology that WordPress relies on, the work happening behind the scenes suddenly matters a great deal.
In October 2026, two critical PHP security vulnerabilities prompted an immediate review of the WordPress environments we manage at Capital House Media. Here’s how the situation came to our attention, what we were able to do, what depended on our hosting provider, and why this experience reinforced our approach to website management.
It Started With a Wordfence Newsletter
One of the things I make a habit of doing is reading Wordfence’s weekly security newsletter. It helps me keep up with vulnerabilities, exploits, and other developments in the WordPress ecosystem.
Most updates deserve a look, but not every alert has the same urgency. Sometimes a vulnerability affects a specific plugin or theme. Sometimes the potential impact is much broader.
This one caught my attention immediately.
The issue wasn’t limited to a single WordPress plugin or something we could fix by clicking an update button in the dashboard. It involved PHP itself, the programming language WordPress runs on. I could tell quickly that we needed to understand the potential impact on the websites we manage.
My first question was simple: What can we do right now to understand our exposure and be ready to respond?
Two Critical PHP Vulnerabilities
On October 21, 2026, the PHP development team released security updates for two critical remote code execution vulnerabilities:
- CVE-2026-109618: A flaw involving out-of-memory handling and partially initialized request data.
- CVE-2026-109619: A flaw involving stale internal state after memory has been freed.
Under affected conditions, these issues could allow an unauthenticated attacker to execute code on a server. The vulnerabilities concerned PHP web-serving environments generally, not WordPress alone. But because WordPress relies on PHP, WordPress site owners had good reason to pay attention.
The PHP project published fixes in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 and stressed that updating, rather than relying only on temporary mitigations, was the safe solution.
Read the PHP project’s October 21, 2026 security advisory.
From Awareness to Action: Reviewing Our WordPress Environments
Once I understood the potential gravity of the alert, we started reviewing what we could assess directly.
Our initial scan covered more than 70 accessible WordPress installations across the environments we manage. We documented the command-line PHP versions reported by those installations to build a working picture of potential exposure. Roughly:
- About two-thirds were running PHP 8.2.
- About one in eight were running PHP 8.4.
- About one in five were running a vendor-maintained build of PHP 7.4.
We’re keeping the exact figures and patch levels to ourselves, but the mix mattered. It meant the exposure wasn’t a single answer, and different environments needed different follow-up.
These readings provided an initial inventory, not a definitive server-side security assessment. In managed hosting, the command-line PHP version is useful to check, but the hosting provider is the authority on its deployed runtime and security patches.
We also separated live production websites from staging, development, and backup environments. That mattered because we wanted to prioritize where follow-up attention could have the greatest impact without overlooking other publicly accessible installations.
The older PHP 7.4 environments deserved particular scrutiny. PHP 7.4 is no longer supported by the upstream PHP project, although some hosting vendors maintain their own long-term-support builds and backport security fixes. We needed to know whether our provider’s supported build would receive the fix, rather than assuming an upstream version number told the whole story.
This was about turning a broad security alert into a specific, actionable understanding of our own environments.
What We Could Do While Waiting for Server-Level Patches
There was an important limit to what we could fix ourselves: these PHP vulnerabilities lived below the WordPress application layer. Updating a WordPress plugin would not patch the underlying PHP runtime.
That didn’t mean we had to sit idle.
We could review the published advisories, inventory versions, identify priority environments, watch for the hosting provider’s patch announcement, and prepare follow-up integrity checks. Those checks can include verifying WordPress core and plugin files, reviewing unexpected PHP files in upload directories, investigating recent file changes, and looking for unrecognized administrator accounts.
Those are useful parts of a response plan, but they are not substitutes for patching PHP. And a clean integrity review, by itself, cannot prove a website was never compromised.
Our goal was to be informed and prepared without pretending we had direct control over a server-level fix.
Why Choosing the Right Hosting Provider Matters
This experience was also a reminder of something I think business owners should understand: good website security is a shared responsibility.
As a web development and management company, Capital House Media can maintain WordPress, manage themes and plugins, evaluate security alerts, investigate suspicious changes, and coordinate a response when something needs attention.
But the underlying PHP runtime, server operating system, and many infrastructure security settings are managed by the hosting provider in our managed-hosting setup. There is only so much a website management team can change from within WordPress or its usual administrative tools.
For this incident, our hosting provider, WP Engine, was responsible for deploying the underlying PHP patches. WP Engine subsequently notified us that the two critical vulnerabilities had been patched on its platform, listing updated versions including 7.4.33.17, 8.2.35, 8.4.27, and 8.5.12.
That notification was an important milestone. It was the provider’s confirmation of its patch rollout, not a claim that we had individually completed a post-patch verification or forensic assessment of every installation.
Not every hosting provider offers the same level of management, patching support, or visibility into infrastructure changes. Price matters, but so does knowing who is responsible when a serious vulnerability appears in the software stack beneath your website.
The hosting provider maintains the infrastructure. We manage and advocate for the websites running on it. Both roles matter.
Website Security Is More Than Clicking “Update”
It’s easy to think website maintenance means logging in every so often and updating WordPress plugins. Those updates are important, but they are only one part of the bigger picture.
A WordPress website relies on multiple layers: its core software, themes, plugins, PHP, the web server, and the hosting platform. Problems can emerge at any of those layers, and the correct response depends on understanding where the issue actually exists. We’ve written before about why WordPress was once our only go-to and how our approach has changed, and this is a good example of why the layers beneath the site matter.
In this case, we didn’t discover the problem because a client’s website stopped working. We became aware of it through a security resource we already follow, recognized the seriousness, and took steps to understand how it could affect the environments we manage.
That’s the kind of behind-the-scenes work that may never be visible on a website’s front end, but it’s a meaningful part of responsible website management.
The Bigger Picture for Our Clients
I don’t expect our clients to know the difference between a PHP vulnerability, a WordPress issue, or an infrastructure patch. That’s part of why they work with us.
Our responsibility is to stay informed, recognize when something deserves attention, understand what we can act on ourselves, and work with the right technology partners when the solution is outside our direct control.
No website can be guaranteed completely immune to threats. The objective is to take security seriously, respond thoughtfully, and continuously improve how websites are maintained.
At Capital House Media, the work doesn’t stop when a website launches. Much of the value of ongoing management is in the work clients don’t see: monitoring developments, evaluating risks, making informed decisions, and keeping their websites in capable hands.
If you’re unsure who’s monitoring the technology behind your business website, get in touch. We’d be happy to talk through your WordPress hosting and ongoing website maintenance needs.
Sources and further reading
- PHP project: October 21, 2026 critical security advisory
- PHP project: October 2026 security releases and announcements
Editorial note: The installation figures are approximate and reflect an initial command-line version inventory. WP Engine’s patch notification is based on the provider message received by Capital House Media. The article does not claim that every installation has undergone a completed post-patch integrity or forensic review.