21 October 2026 | PHP | IT security
On 21 October 2026 the PHP security team released updates for all PHP versions still supported. They close two critical vulnerabilities that have become known as PHP2Shell. The BSI (the German Federal Office for Information Security) has issued a warning and demands that affected systems be patched without delay. Anyone who runs a web server with PHP should act today. That also applies to everyone who “only” runs a WordPress, Nextcloud or Joomla, because these applications run on PHP.
This article summarises what happened, which PHP versions are affected, which version you need now and how to check in a few minutes whether your server is secured.
Contents of this article
- What happened? The timeline
- The two PHP vulnerabilities at a glance
- Who is affected?
- These PHP versions are safe
- How to check and update your server
- PHP 8.1 and older: no official update
- Interim measures and the question “Take the server offline?”
- Frequently asked questions
- Support from Biricon IT Services
What happened? The timeline
The PHP security team announced the release of the fixes in advance so that hosters and administrators had time to prepare. The release itself took place on 21 October 2026. The BSI issued its warning (version 1.1) the same day.
- 20 October 2026: Advance warning from the PHP security team that security updates will appear the following day.
- 21 October 2026, 14:00 UTC (16:00 CEST): The patches for PHP 8.5, 8.4, 8.3 and 8.2 are released.
- 21 October 2026: The BSI warns of the “critical vulnerabilities that threaten web applications worldwide” and recommends patching without delay. According to the BSI, large hosting providers have in some cases taken servers offline as a precaution.
The two PHP vulnerabilities at a glance
These are two separate flaws in the PHP core: CVE-2026-109618 and CVE-2026-109619. According to the PHP security team, either can allow an attacker to execute program code on the server without logging in (unauthenticated remote code execution). The vulnerabilities are rated CVSS v4.0: 9.2 (critical).
| Characteristic | Meaning |
|---|---|
| Identifiers | CVE-2026-109618 and CVE-2026-109619 |
| Rating | CVSS v4.0: 9.2 — critical |
| Impact | Execution of code on the server (remote code execution), without logging in |
| Cause 1 | Corrupted memory when PHP runs out of working memory during processing (out-of-memory) |
| Cause 2 | Stale global state that remains in memory between requests |
| Particularly at risk | Apache with mod_php |
According to the BSI's assessment, there were no confirmed attacks at the time of publication, but there were unconfirmed indications of exploitation attempts. With critical vulnerabilities in such widely used software, experience shows that attackers can be expected to analyse the fixes and prepare automated attacks. The window for patching is therefore short.
Who is affected?
In principle every server on which PHP runs is affected, regardless of how PHP is connected: PHP-FPM, mod_php in Apache, php-cgi, FrankenPHP or LiteSpeed. According to the PHP security team the risk is highest with Apache with mod_php.
The BSI expressly names applications that are built on PHP and can therefore also be affected:
- Content management systems: WordPress, Drupal, TYPO3, Joomla
- Shop systems: Magento
- Cloud and file storage: Nextcloud
- Firewall interfaces: pfSense, OPNsense
The application itself does not need to be faulty for this. The vulnerability lies in PHP, so an update of WordPress, Nextcloud & Co. alone does not help. The PHP version on the server must be updated. For firewalls such as pfSense and OPNsense, the corrected PHP version arrives via the vendor's respective firmware update.
These PHP versions are safe
The vulnerabilities are fixed in the following versions. Anything below is considered vulnerable.
| PHP branch | Minimum required | Note |
|---|---|---|
| PHP 8.5 | 8.5.12 | current branch |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Support ends on 31 December 2026 |
| PHP 8.1 and older | no official update, see bottom | |
How to check and update your server
1. Determine the installed PHP version
On the server's command line, php -v shows the version of the command-line PHP. The web server may use a different PHP version. You should therefore also check the version of PHP-FPM or of the Apache module, for example with php-fpm8.3 -v or via a page that outputs phpinfo() (remove it again immediately afterwards).
2. Install the update via the package manager
On Debian, Ubuntu, RHEL and related systems, the corrected version arrives via the normal package manager, for example apt update && apt upgrade or dnf upgrade. With third-party sources such as the Sury PPA or the Remi repository, the new packages usually appear promptly.
apt changelog php8.3-fpm or rpm -q --changelog php | grep CVE-2026-1096).
3. Restart the PHP service
A package update alone is not enough: running PHP processes keep the old code in memory. Restart PHP-FPM (systemctl restart php8.3-fpm) or Apache (systemctl restart apache2), and then check whether the processes were started after the update.
4. Hosted websites
With shared hosting, the provider usually does the updating. In the customer menu you can usually set the PHP version per website. Choose one of the safe versions named above there, or ask the provider about the state of the patches. According to the BSI, individual providers have taken servers off the network as a precaution. If your site is briefly unreachable, that may be the cause.
PHP 8.1 and older: no official update
For PHP 8.1 and older there are no official security updates any more. Operators of such systems have two options:
- Switch to a supported version (recommended). The older the version, the greater the effort of adapting the application and extensions, so a switch should be tested beforehand.
- Backport the fixes. The PHP security team has made the fixes available in development branches on GitHub. Anyone who compiles PHP themselves can carry these changes over into older versions. This is an interim solution and requires expertise.
PHP 8.2 too is supported only until 31 December 2026. Plan the move to PHP 8.4 or 8.5 now, and do not postpone it to the turn of the year.
Interim measures and the question “Take the server offline?”
With the announcement, the PHP security team also described provisional protective measures. These reduce the risk but do not close the vulnerabilities completely. They do not replace the update and are only intended to bridge the time until the update.
Whether a server should be taken off the network until the update depends on its importance and its reachability. The BSI states that large providers have taken this step. As a rule of thumb:
- Publicly reachable server, update possible now: patch immediately, no shutdown needed.
- Publicly reachable server, update not possible at short notice: restrict access (for example by firewall to known addresses only) or temporarily shut the service down, especially with
mod_php. - Internally reachable server only: patch promptly, the urgency is lower.
Frequently asked questions
Do I need to update WordPress, Joomla or Nextcloud?
Not because of this vulnerability. It lies in PHP, not in the application. Update the PHP version on the server. Updating the application is still worthwhile, independently of this.
How can I tell whether someone has already exploited the vulnerability?
A reliable answer is hard to give. Warning signs include unknown PHP files in the web directory, unusual processes running under the web server user, new user accounts or cron jobs, and unusual outgoing traffic. If you have a specific suspicion, the system should be examined forensically and, if in doubt, rebuilt from scratch.
Is a web application firewall enough?
A firewall can intercept known attack patterns, but it is no substitute for the update. You can read more about how several layers of protection work together in our article Securing Odoo 19: firewall, 2FA & Web RBL. The principles apply to every web application.
Is Odoo affected?
No. Odoo is written in Python and does not run on PHP. Only PHP applications running on the same server would be affected.
Where can I find the official information?
You can find the announcement from the PHP security team in the news archive on php.net (entry dated 20 October 2026), and the versions at php.net/downloads. The BSI warning is numbered 2026-297981-1032 and is published at bsi.bund.de .
Support from Biricon IT Services
If you are not sure which PHP version is running on your server, or need help with patching, we will be glad to support you: with the inventory of all PHP systems, with installing the updates, with moving to a supported PHP version and with checking for compromise. As an IT service provider, we look after servers, firewalls and web applications for small and medium-sized businesses.
As of: 21 October 2026. The situation may change at short notice; the publications of the PHP security team and the BSI are authoritative.