Quick summary for busy business owners.
- Two PHP vulnerabilities disclosed on 21 October 2026 are rated Critical at CVSS 9.2 and can allow unauthenticated remote code execution.
- Affected supported PHP branches must be updated to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a later patched release in the same branch.
- Updating WordPress, a plugin or a website theme does not automatically update the PHP runtime on the server.
- A white page does not prove that a site was hacked, but it is a reason to preserve evidence and investigate instead of repeatedly clicking buttons.
- Business owners should identify who maintains PHP, confirm backups, patch promptly and check logs for signs of compromise.
One morning, a business owner opened his website and saw nothing.
No homepage. No contact form. No helpful little message saying, “Relax, boss, I am repairing myself.” Just a large white page staring back at him like it had resigned without giving notice.
He called me and asked the question I have heard many times: “Is the server company taking care of this?”
Maybe. Maybe not.
A hosting company keeps the server running. That does not always mean somebody is checking every website, every plugin, every PHP version and every security announcement on your behalf. It is rather like renting a shop unit. The landlord maintains the building, but he does not automatically inspect your cash register every night.
This matters now because the PHP security team has released fixes for two critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2 out of 10 and can allow unauthenticated remote code execution.
In normal-business-owner English: under affected conditions, an attacker may be able to make the server run the attacker’s code without first logging in. No password guessing competition required. Very efficient. Unfortunately, efficient for the wrong person.
What happened with PHP in October 2026?
On 20 October 2026, the PHP security team gave advance notice that an urgent release was coming. On 21 October, it published the fixes and the technical details.
The first flaw, CVE-2026-109618, involves the way PHP handles certain out-of-memory conditions. A specially constructed request can leave request memory in an unsafe state and may eventually lead to remote code execution.
The second flaw, CVE-2026-109619, involves stale global state left between requests. Under the right conditions, one request can leave behind unsafe references that a later request touches, again creating a path to remote code execution.
You do not need to memorise “longjmp”, heap layouts or stale pointers. Unless you enjoy reading memory-management notes during dinner, in which case I respect your unusual hobby.
The useful fact is this: the PHP project says updating is the only complete mitigation.
Which PHP versions are affected?
The advisories identify these patched versions:
| PHP branch | Affected versions | Patched version |
|---|---|---|
| PHP 8.2 | Earlier than 8.2.35 | 8.2.35 or later |
| PHP 8.3 | Earlier than 8.3.36 | 8.3.36 or later |
| PHP 8.4 | Earlier than 8.4.27 | 8.4.27 or later |
| PHP 8.5 | Earlier than 8.5.12 | 8.5.12 or later |
If your website uses an older, unsupported PHP branch, the correct conversation is bigger than these two patches. Unsupported software does not receive normal security maintenance. “It has worked since 2019” is not a security strategy. My old Nokia also still switches on; I am not asking it to run online banking.
Is every PHP website already hacked?
No.
A critical vulnerability means the potential impact is severe and the issue deserves urgent action. It does not prove that every PHP website has been compromised. Exploitability can depend on the PHP build, server setup, request handling and other technical conditions.
Do not panic and delete the whole website. Also do not decide that because the homepage still loads, everything must be fine.
A website can look normal while somebody has placed a hidden file, created a secret administrator, inserted spam pages or prepared a way back in. The visible page is only the shopfront. Security problems often happen in the storeroom.
Does this affect WordPress websites?
WordPress is written in PHP. So are many ecommerce sites, membership portals, booking systems, CRMs and custom business applications.
That does not mean WordPress itself caused these particular PHP vulnerabilities. The problem is in the PHP runtime underneath the application.
This distinction is important because a business owner may log into WordPress, update every plugin and proudly report, “All green already.” Good work—but the server may still be running an affected PHP version.
WordPress updates, theme updates, plugin updates and PHP updates are separate layers. Security is irritatingly fond of layers. If only hackers agreed to attack one thing at a time, life would be very organised.
Why your hosting company may not handle everything
I have repaired hacked, malware-infected and dangerously outdated PHP and WordPress websites. A common misunderstanding is that paying for hosting means the hosting company automatically maintains the whole website.
Some managed providers do patch server software quickly. Some provide automatic updates but leave application compatibility to the customer. Some offer several PHP versions in a control panel and expect the account owner to choose. Some will help only after a support ticket arrives.
None of these models is automatically wrong. The problem is when nobody knows who is responsible.
Ask your provider or developer four direct questions:
- What exact PHP version is serving my live website?
- Has it been updated for CVE-2026-109618 and CVE-2026-109619?
- Who checks whether an upgrade breaks the website?
- When was the last successful backup restoration test?
“We have backups” and “we successfully restored a clean backup” are different sentences. The first is comforting. The second is evidence.
What does the white screen actually mean?
Many owners first notice a PHP problem as a blank white page or a page displaying an error. I have seen this pattern repeatedly.
A white screen does not automatically mean a hacker entered the website. It can come from an incompatible plugin, a PHP fatal error, a failed deployment, exhausted memory, corrupted files or a server upgrade that exposed old code.
It can also appear during a security incident.
The correct response is investigation, not random button pressing. Every hurried change can overwrite logs, alter timestamps or make recovery harder. When the smoke alarm rings, do not begin rewiring the kitchen because YouTube showed a very confident man doing it in seven minutes.
What business owners should do now
First, identify the person responsible for the website’s PHP runtime. It may be your hosting provider, managed-services company, web agency, freelance developer or internal IT staff.
Second, confirm the live version. A screenshot from an old proposal is not enough. The version must be checked on the server actually serving the public website.
Third, create and verify a current backup before changing production. The backup should include website files and databases. Store a copy separately from the same hosting account, because a backup sitting beside the damaged site can become two damaged things for the price of one.
Fourth, update to a patched PHP release in the appropriate supported branch. Do this through a planned process: check compatibility, test where practical, deploy the update and verify important functions such as forms, payments, logins, scheduled jobs and integrations.
Fifth, review logs and files for signs that the website was already touched. Patching closes the known door. It does not remove an intruder who entered yesterday and is now hiding behind the sofa.
Finally, change relevant credentials if compromise is suspected and monitor the website after recovery. That may include hosting, SFTP, control-panel, database, administrator and API credentials.
What not to do
Do not merely hide error messages. The official advisory specifically says that changing error reporting or disabling displayed errors does not protect against the stale global state vulnerability.
Do not assume a WordPress security plugin patches the PHP engine. A plugin runs inside PHP; it cannot magically replace the engine beneath itself.
Do not upgrade a live business system blindly at 4:55 pm on Friday. Security updates can be urgent, but urgency still needs a backup, compatibility checks and somebody available to verify the result.
And please do not send the office intern a message saying, “Can settle before lunch?” unless you are also giving that person access, backups, documentation and the authority to call for help. Otherwise, you are not delegating security. You are delegating anxiety.
How I approach a PHP security emergency
I have been working with PHP since 1996, from the early days when websites were much simpler and nobody had yet invented seventeen dashboards to manage one contact form.
Over the years, I have built and maintained websites, web applications, mobile-app backends, business portals and custom management systems. I have also repaired PHP and WordPress sites after owners encountered the frightening white page, malware, strange redirects or outdated code that could no longer survive a server upgrade.
The first job is not to show how clever the developer is. The first job is to stabilise the business.
That means understanding what happened, preserving what may be useful for diagnosis, protecting the data, restoring essential functions and explaining the next steps in human language. The owner already has customers, staff and bills to manage. He does not need a twelve-minute lecture on heap corruption while the enquiry form is dead.
Depending on the situation, I can help with an emergency PHP security check, hacked website and WordPress recovery, PHP upgrading and compatibility work, or ongoing website maintenance and development.
A sensible long-term website security routine
Security should not begin only when the homepage disappears.
A sensible routine records the PHP version, framework or CMS version, plugins, themes, server owner, domain access, backup location and recovery contact. Somebody should receive vendor security notices. Critical updates should have an agreed path from testing to production.
Backups should be automatic, separated from the live site and occasionally restored. User accounts should be reviewed. Unused plugins and old administrator accounts should be removed. Logs and uptime should be monitored. Important forms should be tested, because a website can remain beautifully online while quietly throwing every sales enquiry into a black hole.
This does not require an enterprise command centre with six giant screens and one serious-looking man pointing at a map. It requires ownership, a checklist and somebody competent enough to act.
Your website is part of the business
For many SMEs, the website brings enquiries, accepts bookings, processes payments or supports daily operations. It is not merely an online brochure floating peacefully in the cloud.
The two critical PHP vulnerabilities disclosed in October 2026 are a useful wake-up call. Confirm your PHP version. Apply the patched release. Verify the website. Check for signs of compromise. Test your backups. Decide who owns maintenance from now on.
If your website is showing a white page, strange errors, redirects or suspicious behaviour, do not wait for it to develop better manners. Get it checked.
Who is currently responsible for updating the PHP behind your business website—and when was the last time anybody verified it? Share your experience when I post this article, or contact me for an urgent security review.
Common questions about this topic.
What are CVE-2026-109618 and CVE-2026-109619?
They are two critical PHP vulnerabilities disclosed on 21 October 2026. Both can lead to unauthenticated remote code execution under affected configurations, meaning an attacker may be able to run commands through a vulnerable web server without first logging in.
Which PHP versions fix the critical October 2026 vulnerabilities?
The PHP security advisories list PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as patched releases. A later secure release in the same supported branch should also contain the fix. Confirm the actual server runtime rather than relying on what a website dashboard displays.
Is WordPress affected by the PHP vulnerabilities?
WordPress runs on PHP, so a WordPress website can be exposed when its server uses an affected PHP version. Updating WordPress core and plugins is still necessary, but it does not replace updating the PHP runtime.
Does my hosting company automatically update PHP?
Some managed hosting providers patch PHP quickly, while others require the account owner or developer to select a newer version. Ask for the exact PHP version currently serving the website and written confirmation that the relevant security update has been applied.
Does a white screen mean my website has been hacked?
Not necessarily. A blank white page may be caused by a PHP fatal error, an incompatible plugin, exhausted memory, a failed update or malware. Preserve logs and backups, avoid random changes and have the cause diagnosed properly.
What should I do if my PHP website may be compromised?
Restrict access if practical, preserve server and application logs, take a forensic copy, change credentials from a clean device, patch the PHP runtime, inspect modified files and persistence mechanisms, restore from a verified clean backup when appropriate, and monitor the site after recovery.
Can I fix this by hiding PHP error messages?
No. The official advisory says changing error reporting or disabling displayed errors does not protect against the stale global state vulnerability. The complete remedy is to update to a patched PHP release.
How often should a business website receive security maintenance?
Security updates should be assessed when vendors release them, with critical fixes treated urgently. A practical maintenance routine should also include tested backups, uptime monitoring, log review, access checks and periodic restoration tests.
