PHP2Shell: what the critical PHP vulnerability means for your website – and what to do now

• What: two critical flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619), both rated CVSS v4.0 9.2 by the PHP project. They can allow unauthenticated remote code execution.
• Who: according to the PHP project, all PHP installations serving web requests – PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project considers the risk highest for mod_php.
• Fix: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Temporary measures only reduce specific attack paths – according to the PHP project, only the update is a complete solution.
• Old versions: PHP 8.1 and older no longer receive updates from the PHP project. The PHP security team provided minimal source backports for 7.4, 8.0 and 8.1; some distributions and long-term-support vendors ship their own packages.
• What this means for you: if your website runs on WordPress, Joomla, a shop system or any other PHP software, ask your host today which PHP version is running and whether the fix is installed. How to check it yourself is explained below.

PHP is the programming language many websites use to build their pages on the server: content management systems such as WordPress, Joomla and TYPO3, shops such as WooCommerce, Shopware or Magento, forums, booking and membership software. When a visitor opens such a page, a PHP process on the server handles the request.

That is exactly where the two flaws sit. The PHP project's security advisory of 21 October 2026 describes them as follows:

• CVE-2026-109618 – “RCE via OOM corruption”: out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
• CVE-2026-109619 – “RCE via stale global state”: request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

“RCE” stands for remote code execution: whoever exploits the flaw can run their own commands on the server, with the web server's permissions. Hence the name PHP2Shell – an ordinary web request turns into access to the server's command line. The PHP project states that for mod_php an exploit was demonstrated in which an unauthenticated request can trigger the attack before any application code runs. So it does not help that WordPress, a plugin or a shop is fully up to date: the weakness sits one level below, in PHP itself.

In its pre-announcement of 20 October 2026 the PHP project rated both flaws CVSS v4.0 9.2. The scale goes up to 10; scores of 9 and above count as “critical”.

According to the PHP project, all PHP installations serving web requests are at risk. Named explicitly:

• Apache with mod_php – where the PHP project sees the highest risk,
• PHP-FPM (the common setup behind nginx or Apache),
• php-cgi, FrankenPHP and LiteSpeed.

Which versions are safe?

Important: Linux distributions often build security fixes into their own packages without raising the version number to 8.x.y. According to the PHP project, distributions and LTS vendors received the patches in advance. An “old” number on a Debian, Ubuntu, Red Hat or AlmaLinux server can therefore still be protected – only your host or IT team can confirm it.

What this means for typical businesses

• WordPress, Joomla, TYPO3, Drupal: run on PHP. An up-to-date CMS does not protect you here – what counts is the PHP version on the server.
• WooCommerce, Shopware, Magento/Adobe Commerce, PrestaShop: also PHP. Shops hold customer data and payment flows – act especially fast.
• Shared hosting: the host usually applies PHP updates centrally. Many plans let you pick a PHP version yourself, though – if an old version such as 7.4 or 8.1 is selected, you stay on it until you switch.
• Own server or VPS: you (or your agency) are responsible: update the packages and restart every PHP worker.
• Builders without PHP: services that deliver static pages or run on other technology are not affected by this particular flaw. If in doubt, ask the provider.

Timeline

• August/September 2026: several teams find the bugs independently. According to the PHP Foundation, the first signs came from a PHP core developer, followed by reports from Calif and OpenAI (11 August) and Wiz (24 August). Wiz gives 19 August as its discovery date.
• 20 October: the PHP project announces a critical security release – scheduled for 21 October at 14:00 UTC, both flaws rated CVSS v4.0 9.2. The same day, according to the PHP Foundation, the CVE numbers circulate with a wrong time and a wrong score of 10.0; in the evening a proof-of-concept video is published by mistake.
• 21 October, early morning: according to the PHP Foundation, a container image vendor publishes fixed packages at 07:41 UTC – more than six hours before the coordinated release.
• 21 October, 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and the technical details are published.

Authorities and reactions

National cyber security agencies across Europe issued warnings: Germany's BSI with a security notice at criticality level 3/orange (“measures must be taken without delay”), CERT.at in Austria, CERT-FR in France, the UK's NCSC, INCIBE-CERT in Spain and CSIRT Italia. BSI and NCSC advise taking systems offline temporarily if neither the update nor a mitigation is possible.

Many did exactly that. According to derStandard, the University of Vienna, TU Wien, the newspaper NÖN and Caritas went offline as a precaution in Austria; according to Deutschlandfunk, the German state capital Mainz took web services and its portal offline. In France the Interior Ministry, at the request of ANSSI, put prefecture websites into preventive maintenance (actu17); in the Netherlands MijnOverheid and DigiD were affected, according to igizmo.it citing NOS.

Is it being exploited? Sources disagree

• Yes, attack attempts: Amazon Web Services reports attempts in its honeypots from 17 October and further ones from early 21 October. Security firm watchTowr reported active exploitation attempts against both flaws on 21 October; Datadog describes broad, untargeted scanning. INCIBE-CERT writes that attacks were reported before the updates were published.
• Not confirmed yet: the PHP Foundation says the PHP security team had not identified functional exploits at the time of release. The BSI could not verify early reports from social media. As of 22 October, neither CVE is listed in the US CISA Known Exploited Vulnerabilities catalog.

Our reading: attack attempts are documented; large-scale successful compromises have not been publicly confirmed so far. For you nothing changes: the details are public and mass scanning usually follows quickly. Treat every unpatched PHP server as if it were already under attack.

How many websites are affected?

There is no exact figure. Wiz speaks of “70% of the Internet” in its analysis. According to The Hacker News, on 20 October about 884,000 internet-facing servers showed PHP 8.1 or older in their banner – versions without an official update. Such counts are based on server banners and do not show whether a server is actually vulnerable.

You do not need to be technical to find out whether your website uses PHP and which version runs. These routes usually take a few minutes:

1. In the WordPress dashboard: Tools → Site Health → Info, section Server. The PHP version is listed there.
2. In Joomla: System → System Information. The PHP version is listed there.
3. In your host's control panel: shared hosting plans usually have an item such as “PHP settings” or “PHP version”, where you see and change it.
4. By emailing your host: ask literally: “Which PHP version runs my website, and are the fixes for CVE-2026-109618 and CVE-2026-109619 installed?” Get the answer in writing.
5. For technical staff: php -v on the server shows the command-line version, which can differ from the one serving web requests. Reliable is the version the web server actually uses (for example via a phpinfo page created briefly and deleted right after). Some servers reveal the version in the X-Powered-By HTTP header; if it is missing, that does not mean PHP is absent.

Rule of thumb: 8.5.12, 8.4.27, 8.3.36, 8.2.35 or higher means the official update is in. A lower number is not automatically unsafe (see distribution packages above) – then your host must confirm the fix is included.

1. Contact your host or agency and get written confirmation: PHP version, fix for both CVEs installed, all PHP workers restarted.
2. Check the PHP version in your control panel and, where you choose it yourself, switch to a maintained branch (8.3, 8.4 or 8.5). Test briefly whether theme and plugins still work.
3. Make a backup and download it – files and database, with a date. A backup on the same server is not enough.
4. Update CMS, themes and plugins. This does not close PHP2Shell, but it closes other doors attackers are probing right now.
5. Review admin accounts: any users you don't recognise? Remove and report them.
6. Change passwords once the update is in: admin logins, FTP/SFTP, database, hosting account. Turn on two-factor login wherever possible.
7. Have the logs reviewed (see below), especially if the server was reachable between disclosure and update.
8. Test contact forms and your shop after everything is updated, so no enquiry gets lost.

If you took your website offline as a precaution, say so on your channels (Google Business Profile, social media) with a short note on how customers can reach you in the meantime.

The PHP project lists temporary measures for servers that cannot be updated immediately – and stresses that they only reduce exposure to specific attack paths and do not make an installation safe. They are a job for whoever runs the server, not for website owners. In short:

• Against CVE-2026-109618: set memory_limit=-1 so applications cannot override it (e.g. php_admin_value); keep post_max_size low (8M without file uploads, 32M with them) and upload_max_filesize below it; enforce limits for request size, input field count, multipart parts, header count and nesting depth at the web server or proxy; use container or cgroup limits as a safety net. Explicitly do not use RLIMIT_AS or RLIMIT_DATA.
• Against CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the pool configuration and restart every worker (not via ini_set() or .user.ini); on PHP 8.5 also set fatal_error_backtraces=0. Fix fatal errors and timeouts attackers can trigger – merely hiding error messages does not help.

The full technical details are in the security advisory on php.net.

An installed update closes the hole – it does not remove anything planted before. If your server was reachable between disclosure and update, have it checked for traces. Common general warning signs after a server compromise:

• new or modified PHP files in upload or cache folders that nobody created,
• unknown administrator accounts in the CMS or new users on the server,
• many aborted requests or memory errors in the PHP or web server log, especially very large or oddly structured POST requests,
• outgoing connections or new scheduled tasks (cron jobs) nobody set up,
• redirects to unknown sites, spam pages under your domain in Google, browser warnings.

Specific PHP2Shell traces published by security firms (for whoever reviews your logs): Amazon Web Services points to the string PHP_SESSION_UPLOAD_PROGRESS in POST form uploads and recommends reviewing logs from 17 October. Datadog lists messages such as “Allowed memory size … exhausted … Unknown on line 0”, Apache child processes crashing with “Segmentation fault” and web server processes spawning a shell (sh -c). Wiz advises watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses.

If you find any of these: take the site offline, bring in specialists, change credentials only from a clean system and – if personal data may be affected – check your notification duty under Art. 33 GDPR (72 hours after becoming aware).

Many people are asking us about websites built with mekyn. The answer is simple: websites created and delivered by mekyn are served as finished, static pages. No PHP runs there. The platform behind them – dashboard, forms, booking – runs on Node.js. PHP2Shell therefore does not affect these websites.

That is a design decision, not luck: a statically delivered page has no program logic on the web server that runs with every visit. Fewer moving parts means a smaller attack surface – and fast load times as a bonus. Platform updates are applied centrally; you don't have to do anything.

If your current website runs on PHP and after this week you are done with server updates, plugin upkeep and emergency emails: mekyn takes over the content of your existing website and turns it into a modern presence with Google visibility, contact channels and booking. Until you move, though: work through the checklist above – your current site needs to be safe today.