PHP Security Vulnerabilities 2026: Act Now
Several security updates within a few months, most recently two critical vulnerabilities: PHP has been firmly in the IT security spotlight throughout 2026. For companies running Magento, Drupal or other PHP-based systems, a simple question arises: is your own infrastructure adequately protected?
A website can run flawlessly and still contain known security vulnerabilities. Whether an online shop is reachable, processes orders or exchanges data with an ERP system says little about the security state of the underlying software.
This is exactly what the PHP security updates of recent months highlight. They show why regular maintenance is not a technical side issue, but part of running business-critical systems reliably.
PHP Security Vulnerabilities 2026: What Happened?
PHP is one of the most widely used programming languages for websites, online shops and digital business applications. Established platforms such as Magento or Adobe Commerce, and Drupal, are also built on it.
Between July and October 2026, the PHP project released several security updates. These fixed various vulnerabilities that, under certain conditions, could allow server crashes or the unauthorised execution of external code, among other things. Two releases stand out as particularly relevant.
2026 / September - 24: Vulnerability in the SOAP Extension
Under the identifier CVE-2026-91765, a vulnerability was disclosed that can allow a PHP process to be deliberately crashed.
The cause lies in how the PHP SOAP extension processes heavily nested data. Under certain conditions, attackers can crash a vulnerable, reachable SOAP server with a specially crafted request. Repeated requests can affect the availability of a service.
The PHP project rates the vulnerability at 7.5 out of 10 points under CVSS 3.1. That makes it high, not critical.
The distinction matters: not every PHP application is automatically exploitable. The specific vulnerability affects applications that expose a vulnerable SOAP server endpoint.
2026 / October - 21: Two Critical Vulnerabilities
Under CVE-2026-109618 and CVE-2026-109619, the PHP project disclosed two further vulnerabilities. These are considerably more serious: they can allow the execution of external code on a server, so-called remote code execution. The PHP project itself rates both at 9.2 out of 10 under the newer CVSS 4.0 methodology, while an independent analysis by the US vulnerability database arrives at 9.8 out of 10 under the older CVSS 3.1 methodology. The difference comes down to the methodology used, not a different assessment of the danger: both scores count as critical. The security firm Wiz, which was involved in the discovery, gave the two vulnerabilities the now widely used name "PHP2Shell".
The PHP project explicitly warns of the risks and urges operators of affected systems to update without delay. Unlike the SOAP vulnerability, exposure here is not limited to applications with a particular SOAP interface. It affects, in principle, every PHP installation that handles web requests, regardless of whether it runs via PHP-FPM, Apache, FrankenPHP or another server.
This significantly raises the stakes. While the September vulnerability mainly affects certain server configurations, the two new vulnerabilities need to be checked across the board on every PHP system that processes web requests.
What Does This Mean for Magento, Drupal and Akeneo?
For companies, what matters is not solely which vulnerability was discovered. What matters is whether your own system landscape is affected.
Magento and Adobe Commerce
Online shops often connect product data, customer accounts, orders and external business systems. Security problems at the PHP runtime level can therefore put the availability or security of core business processes at risk.
Magento and Adobe Commerce support different PHP versions, depending on the release in question: for production use of Adobe Commerce or Magento Open Source 2.4.9, Adobe's own system requirements allow only PHP 8.5, with PHP 8.4 permitted solely for the upgrade itself, not for production use. A security update therefore always needs to be checked against the official compatibility requirements of the version in use. Magento is one of the systems we work with.
Drupal
Drupal also runs on PHP. Whether a given vulnerability can be exploited depends on the installed PHP version, the server configuration and any additional modules in use.
An up-to-date Drupal core alone is therefore no guarantee that the underlying PHP environment is also at the latest security level.
Akeneo PIM
With Akeneo, responsibility for PHP updates depends on the operating model. For self-managed installations, the application version in use, the runtime environment and vendor approvals are what matter. With managed cloud offerings, responsibility for parts of the technical infrastructure lies with the provider. For operators working with our partner Akeneo in the PIM space, actual exposure should be assessed based on the product and operating model in use.
Across all three platforms, the same principle applies: an up-to-date application does not replace regular security maintenance of the infrastructure underneath it.
Which PHP Versions Are Currently Required?
The following security versions were released on 21 October 2026:
- PHP 8.2: security version 8.2.35
- PHP 8.3: security version 8.3.36
- PHP 8.4: security version 8.4.27
- PHP 8.5: security version 8.5.12
These versions contain the fixes for the two new critical vulnerabilities. For older version levels, it needs to be checked whether the relevant security fixes have already been provided by the hosting or operating system provider.
One further point deserves attention: PHP 8.2 reaches the end of its official security support on 31 December 2026. Companies still running this version branch should plan their migration in good time.
An update is not simply a matter of moving to the highest available version number. What matters is which PHP version is officially supported by the application in question.
What Companies Should Do Right Now
Anyone running a PHP-based online shop, a CMS or a business-critical web application should be able to answer five questions:
- Which PHP version is running in production? Not just the major version, but the full version level matters.
- Are the current security fixes installed? Updates from the hosting or operating system provider need to be taken into account too.
- Is the application in use compatible with the corrected PHP version? This also covers extensions, integrations and custom development.
- Who is responsible for updates? In-house IT, hosting partner, software vendor or external service provider: responsibility needs to be clearly assigned.
- Is there an established maintenance process? Security advisories need to be reviewed, relevant updates tested and rolled out promptly. For CVE-2026-109618/109619, reports suggest only around 24 hours passed between an early leak of the details and the official release on 21 October. A maintenance process built for a response measured in days or weeks is not enough for a vulnerability in this category.
An additional check is worthwhile especially for older integrations with ERP, PIM or third-party systems. Such interfaces often stay in use for years and can easily be overlooked during security reviews.
Patching as an Ongoing Task
Between July and October 2026 alone, the PHP project released four separate rounds of security updates for the currently supported version branches 8.2 to 8.5. This points to a fundamental issue: software keeps evolving, and the requirements for running it securely evolve along with it.
Anyone modernising an online shop or a digital platform tends to invest in features, usability and new integrations. The technical maintenance running in the background, by contrast, often gets less attention. In our experience of providing technical support for digital commerce projects, it is often the most stable, longest-running platform that stays unpatched the longest: when a system is rarely touched because it simply works, it is easy to forget to check the runtime environment underneath it regularly.
Unpatched runtime environments can become a risk precisely because of this, even when the application itself is being actively developed.
That said, not every reported vulnerability automatically poses an acute threat to every company. A sound assessment always takes into account the affected software version, the specific configuration, possible attack paths and the impact on business operations.
The key question, then, is less whether the next PHP vulnerability will be found, and more whether your company will be ready for it.
When was your PHP environment last reviewed?
Arcmedia has been supporting companies with digital commerce projects since 1995, from analysis through implementation to ongoing operations. Our experts are happy to advise you on your project.
Always up to date with the latest trends and tips: subscribe to our newsletter.
Glossary
Technical terms from this article, explained briefly and simply, in alphabetical order:
- CMS (Content Management System): software for managing and publishing website content, for example Drupal.
- CVE (Common Vulnerabilities and Exposures): the globally used identifier for individual security vulnerabilities, for example CVE-2026-91765.
- CVSS (Common Vulnerability Scoring System): a standard method that rates the severity of a security vulnerability on a scale from 0 to 10.
- ERP (Enterprise Resource Planning): software that runs finance, inventory and order processing behind the scenes at a company.
- PIM (Product Information Management): the central management of product data across all sales channels.
- SOAP (Simple Object Access Protocol): an older, text-based standard that two systems use to exchange structured data.
Sources
- GitHub Security Advisory GHSA-rgrp-mwpx-f6rm (php/php-src repository): CVE-2026-91765, published 24 September 2026
- National Vulnerability Database (NVD), CVE-2026-91765, published 25 September 2026
- php.net, release announcements for PHP 8.2.34 / 8.3.35 / 8.4.26 / 8.5.11, 24 September 2026
- php.net, news archive and ChangeLog-8.php: release announcements and security notice for PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, 21 October 2026
- GitHub Security Advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp (php/php-src repository): CVE-2026-109618 and CVE-2026-109619, published 21 October 2026
- National Vulnerability Database (NVD), CVE-2026-109618 and CVE-2026-109619, published 21 October 2026
- MITRE CVE Services (cve.org), CVE-2026-109618 and CVE-2026-109619
- Cyber Security Agency of Singapore (CSA), Advisory AL-2026-151 on "PHP2Shell"
- Wiz, security analysis "PHP2Shell"
- Adobe, developer documentation on Adobe Commerce web API protocols
- Adobe Experience League, Adobe Commerce 2.4.9 system requirements and release notes
- Drupal.org, Drupal 10 and 11 system requirements
- php.net / HeroDevs, PHP 8.2 end-of-life overview
