.png)
The PHP vulnerabilities dubbed PHP2Shell (CVE-2026-109618 and CVE-2026-109619) are two critical flaws in the PHP engine that allow for remote code execution on a server without the need for a username or password. Patched on October 21, 2026, they require upgrading to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, regardless of the CMS being used.
PHP powers a large portion of the web, from WordPress to Drupal, as well as Magento and PrestaShop. When a flaw affects the language itself, a perfectly maintained site remains exposed if the version installed on its server is not patched. This explains why numerous sites were taken down for maintenance as a precaution on October 21, including those of prefectures and public institutions.
This article provides an overview of the nature of these flaws, the affected versions, the immediate steps to take, and the consequences for your SEO.
What are the PHP2Shell vulnerabilities?
PHP2Shell refers to two vulnerabilities discovered in the PHP engine—the language that generates the pages of a dynamic site on the server side. They do not target a specific CMS or extension, but rather the foundation upon which all these tools rely.
Two remote code execution vulnerabilities without authentication
Both flaws lead to the same result: remote code execution (RCE). An attacker sends a malicious request to the server, which then executes their instructions without requiring authentication. The attacker can then steal data, modify pages, or install a backdoor.
According to the security advisory published by the PHP team, they affect memory management between two requests:
- CVE-2026-109618 (memory corruption): when memory is saturated, PHP can be interrupted while request data is only partially initialized, and then treat it as valid during cleanup;
- CVE-2026-109619 : an internal state linked to a request can persist after its memory has been freed and be reused by the next request processed by the same process.
The PHP team specifies that the most exposed configuration is Apache with mod_php: the attack can be triggered there even before the application code is executed. PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are also affected.
Flaws discovered with the help of AI
Security researchers from Calif and Wiz Research identified these flaws by leveraging next-generation AI models and then reported them to the PHP team as part of a coordinated disclosure. A leak published on October 20 forced the PHP team to urgently announce a patch, which was released the following day. This episode demonstrates that AI reduces the time between the discovery of a vulnerability and its exploitation: a site must now be able to patch itself within a few hours.
Which sites and PHP versions are affected?
Any PHP installation that responds to web requests is affected, whether the site runs on WordPress, Drupal, Joomla, Magento, PrestaShop, or a custom-built solution. Hosted platforms that do not rely on PHP (Shopify, Webflow, Wix) are not affected for the site itself, but an auxiliary tool using PHP (client portal, back-office, separate blog) may be.
Linux distributions and long-term support providers received the patches in advance. If your server uses its distribution's packages, verify that the update mentions both CVE numbers.
{{audit-primary="/cta"}}
What should you do to protect your site?
The only complete protection is updating PHP. Other measures reduce exposure while you work on the update, but they do not make a server secure.
Check your PHP version and hosting provider
Start by finding out which version of PHP is actually running on your server. In WordPress, the "Site Health" screen displays this in the Info tab; on shared hosting, it can be found in the hosting provider's administration panel.
If your site is managed or hosted by a third-party provider, ask them two specific questions:
- which version of PHP is installed on the server hosting my site?
- has the patch for vulnerabilities CVE-2026-109618 and CVE-2026-109619 been applied, and if so, when?
Most major hosting providers apply the patch themselves, but not all do: a vague answer should prompt you to follow up.
Installing the patch on the server
If you manage your own server, install one of the four patched versions, then restart all PHP processes (FPM pools, Apache). A process that has not been restarted will continue to execute the old code.
Updating WordPress, its theme, or its plugins will not fix this issue. The vulnerability is in the PHP engine beneath the CMS, and only server-level intervention will close it.
If your site is still running on PHP 8.1 or earlier, it is time to plan a migration. These versions no longer receive regular security updates, and a one-off patch does not make them secure.
Emergency measures if you cannot update
While waiting for the update, the PHP team lists several settings that close known attack vectors:
- disable session.upload_progress.enabled in the php.ini or FPM pool configuration, then restart each process;
- lower post_max_size (8M if no file uploads are needed, 32M otherwise) and keep upload_max_filesize below that;
- on PHP 8.5, disable fatal_error_backtraces;
- limit the size and complexity of requests at the web server, proxy, or web application firewall (WAF) level.
A CMS maintenance mode does not provide protection: PHP analyzes the request before the application executes. If none of these measures can be implemented quickly, taking the site offline while you fix it remains the safest option. All technical explanations can be found in theofficial PHP security advisory.
PHP vulnerabilities and SEO: what are the risks for your search rankings?
A security vulnerability becomes an SEO issue in two ways: when you take the site down to protect it, and when it gets hacked. The former can be managed without damage, while the latter can cost you months of visibility.
Putting your site into maintenance mode without losing your rankings
For a temporary outage, the right signal to send to Google is a 503 error (service unavailable), ideally accompanied by a Retry-After header. Google understands that the unavailability is temporary and will return to crawl the page later, without removing it from the index.
The classic mistake is to display a "site under maintenance" page that returns a 200 code: Google may then index this message instead of your content. A 500 error that lasts, on the other hand, signals a faulty server and slows down crawling. A few hours with a 503 have no lasting effect, but several days start to have an impact.
Detecting a hacked site before Google does
A compromised server is often used for SEO purposes: injected spam pages, hidden links, or redirects to shady sites depending on the visitor. These black hat SEO techniques expose your domain to manual action and a security warning displayed in search results.
In the weeks that follow, keep an eye on a few signals:
- the "Security Issues" report from the Google Search Console, which flags hacked content detected by Google;
- a sudden spike in the number of indexed pages, or queries unrelated to your business in the Performance report;
- unusual requests in server logs, which thelog analysis helps to isolate;
- new PHP files or administrator accounts that no one created.
If a hack is confirmed, clean the server, change all access credentials, and then request a review in Search Console. The faster you react, the more you limit traffic loss.
{{rdv-primary="/cta"}}
How datashake supports your site's technical security
A site that is down or hacked will no longer rank. The SEO and GEO team at datashake team integrates these checks into its technical monitoring, alongside crawling, indexing, and performance.
Specifically, our technical SEO audit reviews over 100 checkpoints, including the site's technical stack, response codes, and signs of abnormal indexing. During crises like PHP2Shell, we help our clients verify their exposure with their hosting provider, implement a proper 503 maintenance page, and monitor Search Console afterward.
FAQ
What is a PHP vulnerability?
A PHP vulnerability is a flaw in the PHP language itself or in code written in PHP. With PHP2Shell, the issue lies within the engine, exposing all sites that use it, regardless of their CMS.
Is my WordPress site affected by PHP2Shell vulnerabilities?
Yes, if the server hosting it uses an unpatched version of PHP. WordPress, its themes, and its plugins may be up to date, but exposure depends solely on the installed PHP version. Check it in the Site Health screen or with your hosting provider.
What should I do in the event of a critical PHP vulnerability?
You must install the patched version of PHP on the server as soon as it is released, then restart all PHP processes. If that is not immediately possible, apply the mitigation measures published by the PHP team or take the site offline with a 503 code. Then, monitor Search Console and server logs.
Does putting a site into maintenance mode hurt SEO?
No, provided it is brief and returns a 503 code. Google understands that this is a temporary outage and keeps the pages in its index. The risk arises when the maintenance page returns a 200 code or when the downtime lasts for several days.
.png)