{"id":842411,"date":"2026-10-22T11:49:18","date_gmt":"2026-10-22T11:49:18","guid":{"rendered":"https:\/\/www.knowband.com\/blog\/?p=842411\/"},"modified":"2026-10-22T12:51:09","modified_gmt":"2026-10-22T12:51:09","slug":"critical-php-vulnerabilities-updates-2026","status":"publish","type":"post","link":"https:\/\/www.knowband.com\/blog\/prestashop-blog\/critical-php-vulnerabilities-updates-2026\/","title":{"rendered":"Critical PHP Vulnerabilities (October 2026): What Every PrestaShop Store Owner Must Do Now"},"content":{"rendered":"

Read this first. PHP shipped fixes on 21 October for two critical flaws. If your store runs on an unpatched PHP, an attacker may be able to execute code on the server with no login at all. Neither flaw is in PrestaShop. Today you need three answers: what PHP version is running, whether your host has applied the fix (get it in writing), and whether PHP has been restarted since.<\/p>\n

Most security news is about a plugin or a theme, and the cure is a button labelled “Update”. This is different. Your problem is in the engine beneath your store, and the solution is in the server, beyond any reach of the Back Office. That\u2019s why it\u2019s easy to overlook, and that\u2019s why you need to take an afternoon to fix it calmly and systematically.<\/span><\/p>\n

How this unfolded<\/b><\/h2>\n

The PHP team warned on 20 October that security releases were coming. They were discovered on 21 October, and these have been assigned CVE numbers CVE-2026-109618 and CVE-2026-109619. These vulnerabilities both score 9.2 on the CVSS v4.0 Scale, and are quite critical, and have earned the moniker “php2shell”.
\nA joint advisory was issued by the European Commission (DG CNECT), ENISA, CERT-EU, Europol EC3, and the CSIRTs Network.<\/span><\/p>\n

The European Commission (DG CNECT), ENISA, CERT-EU, Europol EC3 and the CSIRTs Network then issued a joint statement telling organisations to move.\u00a0<\/span><\/p>\n

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.<\/span><\/p>\n

What is actually broken<\/b><\/h2>\n

\"\"<\/a><\/p>\n

Both flaws can end in remote code execution without authentication. Translated: a stranger on the internet could get your server to run their instructions.<\/span><\/p>\n

CVE-2026-109618 is a memory-handling problem. Imagine PHP is building the workspace for an incoming request and the server runs dry of memory halfway through. PHP stops, but the cleanup routine afterwards assumes the half-finished workspace is complete and acts on it.<\/span><\/p>\n

CVE-2026-109619 is closer to a hangover. Something that belonged to one request is still sitting around after its memory was released, and a later request on the same worker can pick it up and trust it.<\/span><\/p>\n

Notice where both of these live: inside PHP. PrestaShop is not at fault, and PrestaShop cannot defend against it, since the attack can land before a single line of PrestaShop code has run. So a module update or a core update changes nothing here. <\/span>The PHP update is the fix.<\/b><\/p>\n

Whose problem is it?<\/b><\/h2>\n

Every way of running PHP for the web is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is the worst case because the attack can fire ahead of any application code.<\/span><\/p>\n

What you need to do depends on your hosting environment and who manages your PHP installation:<\/p>\n\n\n\n\n\n\n\n\n
Hosting Environment<\/th>\nWho Manages PHP?<\/th>\nRecommended Action<\/th>\n<\/tr>\n<\/thead>\n
Shared Hosting<\/td>\nYour hosting provider<\/td>\nContact your host and request confirmation that the relevant PHP security fixes have been applied to your environment.<\/td>\n<\/tr>\n
VPS or Dedicated Server<\/td>\nYou or your system administrator<\/td>\nInstall the appropriate security updates for your PHP version or operating system package, then restart the relevant PHP services if required.<\/td>\n<\/tr>\n
Docker or Containerized Hosting<\/td>\nThe team responsible for the container image<\/td>\nRebuild the image using a PHP base image with the applicable security fixes, then redeploy and verify the running environment.<\/td>\n<\/tr>\n
Older or Unsupported PHP Versions<\/td>\nYour hosting provider or server administrator<\/td>\nCheck whether a vendor security backport is available. If not, plan a move to a supported PHP version after checking compatibility with your store, theme, and modules.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Your checklist for today<\/b><\/h2>\n
    \n
  1. Look up the PHP version.<\/b> Back Office, Advanced Parameters, Information.<\/span><\/li>\n
  2. Write to your host.<\/b> Just ask directly: “Have our servers been patched for CVE-2026-109618 and CVE-2026-109619, and have all of our PHP processes been restarted?” Keep the answer you get. Hint: Some distributions silently apply the patch, leaving the version number unchanged; thus, the age of the version number cannot be used to determine if the server is vulnerable or not.<\/span><\/li>\n
  3. Update, then restart.<\/b> Go to a fixed release or a vendor-patched package. Restart all PHP workers. A restart is the step people forget. On Docker, rebuild the images.<\/span><\/li>\n
  4. On PHP 8.1 or below?<\/b> The PHP project did publish minimal backports for 7.4, 8.0 and 8.1, and many Linux distributions and LTS vendors ship patched packages. Find out if yours does. Either way, start planning the move to a supported version.<\/span><\/li>\n
  5. Think about PrestaShop next.<\/b> Pick a release that supports your target PHP (table below). That comes after the patch, not before.<\/span><\/li>\n<\/ol>\n

    Cannot patch yet? The EU guidance raises one option: isolate the exposed application from the public network until it is fixed. Drastic for a shop, yes. It is still worth having in your back pocket.<\/span><\/p>\n

    Stop-gaps while you wait<\/b><\/h2>\n

    PHP’s own position is that no mitigation is complete and updating is the only safe route. Treat everything in this section as a way to shave down exposure for a few days, nothing more.<\/span><\/p>\n