Critical PHP vulnerabilities: what website and online store owners should do

On 21 October 2026 the PHP Group shipped emergency updates fixing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both allow arbitrary code to be executed on the server without any authentication: an attacker only needs to send the site a specially crafted request. Practically every PHP website is affected — WordPress, WooCommerce, OpenCart, ocStore, Laravel, custom-built systems. Updating your CMS or plugins does not help here: the flaw is in PHP itself, not in the site's code.

What happened

The PHP security team rated both vulnerabilities 9.2 on the CVSS v4.0 scale — critical. The details were supposed to stay under embargo until the fixes shipped, but some information leaked early, together with a screenshot of a ready-made attack tool. Security researchers expect mass automated attacks within the first hours after the fixes are published: bots simply sweep the internet and probe every site they find.

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older is vulnerable.

Every way of running PHP on a web server is affected: PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed, FrankenPHP. The risk is highest with mod_php, where an attack has been demonstrated that fires before any of the site's own code runs.

Why this matters for a business

Code execution on the server means the attacker gets everything your website can access. For an online store that includes:

• Your entire customer database — names, phone numbers, delivery addresses, emails, order history. That is a personal data breach, with all the legal consequences.

• Payment module keys. LiqPay, WayForPay, Monobank and other payment providers keep secret keys in the site settings. With them, payment confirmations can be forged — for example, marking orders as paid when no money arrived.

• A tampered checkout page. A fake card form can be quietly injected into the checkout. Your customers' cards get stolen, and the reputational damage is yours.

• Integration tokens — delivery services, 1C/BAF data exchange, site mailboxes, advertising accounts.

• Neighbouring sites. On regular shared hosting, all sites under one account can usually reach each other: compromise one and the rest are at risk.

• Your site turned against you — spam campaigns, phishing pages on your domain, SEO spam. The result is Google blocklisting and trouble with advertising and email delivery.

An attacker will not get direct access to your bank account through the website: online banking clients and qualified signature keys are not stored on a web server. But everything listed above is entirely realistic.

Who is at risk: version table

Note that PHP 8.2 is supported only until 31 December 2026. If you are upgrading now, go straight to 8.3 or 8.4.

What to do: a step-by-step plan

Step 1. Find out the actual PHP version of your site

Hosting control panels usually show only the branch — "8.2" or "8.4". What matters is the full version: 8.2.34 is vulnerable, 8.2.35 is not. The most reliable method is a temporary file in the site root. Create a file with a random name, such as v_8264.php, containing:

<?php echo PHP_VERSION, " ", PHP_SAPI;

Open it in a browser (https://your-site/v_8264.php), note the result and delete the file immediately. Do not use phpinfo() for this and never leave such files on the server: they hand attackers information they should not have.

Running php -v over SSH shows the command-line version, which may differ from the one actually serving your site.

Step 2. Shared hosting: contact support

On shared hosting only the provider can update PHP. Open a ticket today rather than waiting for the host to announce it. You can send this as is:

Hello. Regarding the critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (php.net, 21.10.2026): when will the fixed PHP versions 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 be installed on our hosting? Do you apply backported fixes for 8.1 and older branches? Which PHP handler serves our sites (mod_php, PHP-FPM or LSAPI)? Thank you.

Meanwhile, check in the control panel which version each site runs on. Anything on 8.1 or below is priority number one (see step 5).

Step 3. Your own server or VPS: update the packages

Linux distributions received the fixes in advance, so the updates should already be in the repositories. For Debian/Ubuntu:

apt update
apt list --upgradable 2>/dev/null | grep -i php
apt install --only-upgrade 'php*'
systemctl restart 'php*-fpm'   # and apache2 if mod_php is used

After updating, be sure to restart all PHP processes — otherwise the server keeps running the old code from memory. Distribution packages may carry a version number different from the upstream one, so confirm the fix in the package changelog by CVE number.

If PHP comes from the remi repository, note that according to the PHP Group its updates will arrive with a delay. Until then, apply the temporary measures from step 4.

Step 4. Temporary measures until you can update

These do not replace the update; they only close known attack paths. In your hosting panel (PHP settings or "Custom php.ini" section) set:

session.upload_progress.enabled = Off
post_max_size = 32M
upload_max_filesize = 30M

If the site does not accept file uploads from visitors at all, post_max_size can go down to 8M. On PHP 8.5, also add fatal_error_backtraces = Off.

Important: these settings must apply at server level — via php.ini, the PHP-FPM pool configuration or the hosting panel. A .user.ini file or ini_set() calls in code do not work here: they take effect only after the request has already been parsed.

For sites where visitors never upload files (most OpenCart stores and brochure sites), you can additionally block file-upload requests at web-server level. On Apache, at the top of .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/admin/
RewriteRule .* - [F,L]

If your admin panel lives at a different path, substitute it — otherwise uploading product images will stop working. After the change, test checkout, contact forms and the payment flow.

Step 5. A site on PHP 7.x or 8.0–8.1

This is the hardest case. There are no official fixes for these versions, and an old site often simply will not run on newer PHP. Your options:

1. Ask your host about a backport. The PHP team has published minimal fixes for 7.4, 8.0 and 8.1 as source code, and some providers (for example, those on CloudLinux) maintain their own builds of old versions. Ask them directly.

2. Test the site on PHP 8.2+ using a copy. Many OpenCart 3.x stores and older WordPress sites run on newer PHP after fixing a few modules. That is far cheaper than building a new site. Test on a staging subdomain, not on the live site.

3. Plan an engine upgrade. If the site cannot be moved to current PHP, the problem goes beyond one vulnerability: the next one will be left unfixed too. Until the work is done, the temporary measures from step 4 are a must.

Step 6. Backup and monitoring

Take a fresh backup of files and database right now and store it separately as a "before" reference. For one to two weeks after the update, keep an eye on the site: that is how you catch a compromise that happened before the fix was installed.

What not to do

• Do not rely on CMS, plugin or theme updates — the vulnerability is in PHP itself.

• Do not put it off until the weekend: automated attacks are already running.

• Do not treat the temporary measures as full protection — they are a safety net until you update.

• Do not switch the PHP version on a live store without a backup and testing — you can end up with a blank page in the middle of the business day.

Signs your site may already be compromised

• New .php files in image, cache or upload folders (image/, uploads/, cache/, storage/).

• Modified template files, especially the checkout and payment pages.

• Unknown administrators in the site admin, changed payment module settings.

• Customers complaining about a strange payment form or redirects to other sites.

• Google Search Console warnings, a sudden spike in outgoing mail from the server.

If you find signs of a breach

Do not delete suspicious files one by one — it is easy to miss the main one. Save a copy of the current state for analysis, change the passwords for the database, admin panel, FTP/SSH and hosting account, and reissue payment module keys and integration API tokens. Then restore from a clean copy or carry out a thorough clean-up that includes finding the entry point.

This article reflects the situation as of 21 October 2026. The official announcement with full technical details is on php.net.

Need help?

We will check which PHP version your sites actually run on, deal with your hosting provider, set up temporary protection, test your site on a newer PHP version and, if needed, investigate a possible breach. We work remotely with clients across Ukraine and abroad. Get in touch or see our 24/7 technical support service.