Landing page
E-commerce website
UX/UI design
Business software & ERP
SaaS software
B2B client portal
Web App & PWA
Mobile app
Artificial Intelligence
Organic SEO
AI SEO & GEO
On October 23, 2026, the PHP Foundation released four emergency security patches. If you run an SME and your site operates on WordPress, Prestashop, or a custom CMS, this news isn’t a technical detail to leave for your developer “for later.” It’s a check to perform this week, period. The stakes: knowing whether your hosting provider has already applied the patch, or if your showcase site or online store is still running with an open door.
A critical PHP security update was published on October 23, 2026 (versions 8.5.12, 8.4.27, 8.3.36, 8.2.35), fixing two flaws referenced as CVE-2026-109618 and CVE-2026-109619. For a website running WordPress or another CMS, the immediate action is to verify with your hosting provider that this patch has been deployed on the server.
- Two critical flaws (CVE-2026-109618 and CVE-2026-109619) were patched in PHP by the PHP Foundation on October 23, 2026.
- WordPress and other CMS sites remain exposed as long as the hosting provider hasn’t deployed the server-side patch.
- Approximately 2 million devices were potentially vulnerable before the patches were released, mostly in the United States, according to ZDNET.
- Security support for PHP 8.2 ends on December 31, 2026: beyond that, no more patches, even for critical issues.
- Checking your PHP version and the installed patched version is a preventive maintenance step that takes five minutes.
Why is this PHP security update critical for your website?
Because PHP runs your site’s engine: WordPress, Prestashop, Drupal, and the majority of CMS platforms rely on it. A flaw at this level directly impacts the foundations, not just a simple plugin, and can allow an attacker to take control of the server, steal customer data, or sabotage the online store.
Most SME managers think their site’s security boils down to updating WordPress and its extensions. That’s false, or rather incomplete. PHP is the language that executes the code behind your CMS, much like a car engine where WordPress is the bodywork. You can change the tires and repaint the bodywork every month, but if the engine has a known defective part, the vehicle remains dangerous.
The two vulnerabilities patched this time, CVE-2026-109618 and CVE-2026-109619, are classified as critical by the PHP Foundation itself, which doesn’t happen with every update. The majority of PHP patches address minor bugs or performance improvements. Here, we’re talking about remotely exploitable flaws, affecting a perimeter of about 2 million devices before the patches were released, the majority being based in the United States.
The specific risk for WordPress and other CMS sites
A poorly maintained WordPress site often accumulates several layers of risk: an outdated theme, abandoned plugins, and now potentially a vulnerable PHP version. Attackers automate large-scale site scanning to identify those that haven’t applied a recent patch, it’s trawling, not a targeted attack. Your SME doesn’t need to be a target to be hit; your server just needs to match the right criteria.
How to check if your hosting provider has applied the PHP patch, and why automation isn’t guaranteed
Log into your hosting administration panel (cPanel, Plesk, or your provider’s client area) and check the PHP version displayed for your site. Compare it to the patched versions released on October 23, 2026: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. If the displayed number is lower, the patch hasn’t been applied yet. In most cases, the hosting provider manages PHP at the server level, not you. But “most cases” doesn’t mean “all cases”, and this is precisely where SMEs get caught: they assume the update is automatic, while some shared hosting services leave the PHP version choice to the user, frozen since the account was created.
The 7-step verification procedure
- Open the hosting administration panel (cPanel, Plesk, proprietary interface)
- Locate the “PHP version” or “PHP selector” section
- Note the exact version number displayed
- Compare with the patched versions released on October 23, 2026
- Contact the hosting provider’s support if the version is older or if PHP 8.2 hasn’t yet received version 8.2.35
- Request written confirmation of the patch application date
- Check again within 48 hours if the provider announces a progressive deployment
The specific case of servers running Ubuntu 24.04 LTS
If your site runs on Ubuntu 24.04 LTS, know that the patch for PHP 8.3 was integrated into a specific package (8.3.6-0ubuntu0.24.04.13), released as early as October 21, 2026, two days before the PHP Foundation’s official announcement. A serious hosting provider using this distribution should therefore have already applied the update via its system repositories, without waiting.
The three precise questions to ask your hosting provider
Don’t settle for a vague “yes, it’s done.” Ask for the exact PHP version now active on your account. Ask for the precise deployment date. And ask whether the patches were applied to the production environment or only in testing, some providers announce a patch “being deployed” that can drag on for several days on the cheapest shared hosting plans.
PHP security update for your website: who is responsible, you or the hosting provider?
On a classic shared hosting plan, the hosting provider manages the server’s PHP engine version, you often only have a version selector in a dropdown menu. On a dedicated server or unmanaged VPS, the responsibility falls on you, or on the agency maintaining your infrastructure. This is the first thing to clarify: many SME managers discover, at the time of an incident, that they were solely responsible for a server they thought was “managed.”
How to install the latest PHP version on your website?
On shared hosting, installation is done via a PHP version selector in the administration panel, in just a few clicks. On a dedicated server or VPS, it involves updating system packages (apt, yum) or manual compilation, reserved for a technical administrator or a web agency.
The risks of an unprepared version upgrade on a CMS
Changing the PHP version is never a completely neutral operation for a CMS. An old WordPress theme, a plugin abandoned for three years, or a poorly coded payment module can break the display or even completely crash the site after the version upgrade. This is the classic trap: the administrator applies the security patch without testing first, and ends up with a site showing a 500 error on a Friday evening.
The checklist for a damage-free update
- Back up the complete site (files and database) before any manipulation
- Test the new PHP version on a pre-production environment if possible
- Check the compatibility of the theme and plugins with the target version
- Activate the new version via the hosting panel or system commands
- Check the display and critical functionalities (payment, forms, cart) immediately after the change
- Monitor error logs for the following 48 hours
A site that remains stuck on an old PHP version “because it works” accumulates silent technical debt, the day a security patch becomes non-negotiable, the entire stack needs to be audited urgently, in a rush, at the worst possible time.
When to entrust the operation to an external provider and plan the PHP 8.2 exit
For an SME without an internal technical team, entrust this operation to the agency that built or maintains the site. Properly executed web development, with an up-to-date foundation and planned preventive maintenance, precisely avoids this kind of race against the clock with every security alert. This rigor is all the more critical as security support for PHP 8.2 ends on December 31, 2026, according to PHP2Shell. After this date, even a critical flaw discovered on this branch will no longer receive an official patch. If your site is still running PHP 8.2, the update to 8.2.35 is a temporary patch, not a lasting solution, you will need to plan the upgrade to a longer-supported version (8.3, 8.4, or 8.5) before the end of the year.
What are the consequences of not updating PHP quickly?
An unpatched site is exposed to hacking (customer data theft, malicious content injection, server takeover), service interruption, and degraded SEO if Google detects a compromise. For an SME, the bill also includes loss of customer trust and the cost of remediation.
According to ZDNET, approximately 2 million devices were potentially vulnerable before the patches were released, the majority being based in the United States. This figure gives the measure of global exposure at the time the two flaws were discovered, a volume that necessarily includes shared servers hosting SME sites, often without their owners knowing.
PHP security update for your website by impact type
The following table details the three direct consequences of a patch delay on a professional site, and the vector through which each is triggered.
| Impact | Manifestation | Typical timeframe |
|---|---|---|
| Security | Intrusion, data theft | Days to weeks |
| Availability | Site offline, server errors | Immediate to a few days |
| SEO | Google penalty, traffic loss | Weeks to months |
Concretely, a hack doesn’t necessarily kill the site overnight: often it infects it silently, then Google flags it to visitors months later, and that’s when traffic really collapses.
The specific risk for SEO and online reputation
A compromised site can be detected by Google, which then displays a “this site may be hacked” warning directly in search results, an immediately dissuasive signal for a potential customer. The deindexing or downgrading that follows can erase months of natural referencing (SEO) work, much faster than it took to build it. Unlike a classic technical failure, repairing a search engine’s trust takes time, sometimes several weeks after the site has been effectively cleaned. On shared hosting, a PHP flaw exploited on another account on the same server can contaminate your site without you having made any configuration error.
Depending on your situation: what should you concretely do?
A very small business with a WordPress showcase site on €5/month shared hosting
The most common situation, and the most exposed: these entry-level plans often mutualize PHP updates across thousands of accounts, with variable deployment delays. What matters here: the support team’s responsiveness and the ease of the version selector. Check the PHP version in the administration panel this week. If it predates the October 23, 2026 patches, contact support without waiting for a subscription renewal.
An SME with 20 employees and an e-commerce store under Prestashop or WooCommerce
Here the stakes go beyond server security: an online store processes payment data, and a hack directly impacts customer trust. The compatibility of payment modules with the new PHP version conditions any switch, under penalty of a broken cart in the middle of a sales period. Plan a pre-production test before applying the patch in production, with the agency maintaining the site.
A mid-sized company with a dedicated server or unmanaged VPS
In this case, no one applies the patch for you: it’s the internal team or the managed services provider who bears the responsibility. Demand a written report confirming the application of versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35 depending on the branch used, with a precise date. If your server runs PHP 8.2, anticipate its end of security support on December 31, 2026, by planning the migration to a maintained branch now.
Working on a project like this? See our dedicated page: free security audit.
FAQ on the PHP update
How to download PHP?
PHP is downloaded from the project’s official website, as source code or binaries depending on the operating system. In practice, most professional sites never install PHP manually: it’s the hosting provider or the Linux server (via its system packages) that provides and updates this version.
How to update PHP on Windows?
On a Windows server (IIS), the update involves downloading the new version from the official PHP project website, then replacing the binary files and reconfiguring the corresponding module. For a production site, this operation must be tested offline before application, and remains rarely relevant for classic shared hosting.
How to install PHP?
On a Linux server, installation is done via the system’s package manager (apt, yum, dnf depending on the distribution). On shared hosting, there is nothing to install: only a version selector in the administration panel needs to be adjusted. On Windows, installation requires manual web server configuration.
A critical flaw in PHP doesn’t forgive procrastination, especially with a deadline like the end of support for PHP 8.2 on December 31, 2026, approaching. If you’re not sure your hosting provider has applied the patch, or if you discover your site relies on an aging technical stack, now is the right time for a complete technical audit, Skyward Agency supports French and Mauritian SMEs on this type of verification, from scoping to compliance, with a single point of contact from the beginning to the end of the project.
