In short: After PHP2Shell, further announcements about PHP are likely, because a third notice came just two days after the patch, a full advisory is still outstanding and distributions are delivering their packages in stages. Anyone who sets up a fixed procedure for monitoring, assessment, update and restart now will respond to the next new PHP vulnerability in hours instead of days.
The patch was not the end of the story
On 21 October 2026, the PHP project closed the two critical vulnerabilities CVE-2026-109618 and CVE-2026-109619 with versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Many of those responsible ticked the box afterwards. Two days later, on 23 October, however, a further notice from php.net followed, on CVE-2026-115560.
This third notice only concerns an unusual session configuration. But it shows a pattern familiar from large security cases: when a component suddenly stands in the spotlight, many specialists look more closely at the same time. Whether further vulnerabilities will emerge from this, nobody knows today. What is likely, however, is that the flow of news will not stop.
For you as an operator, this means: plan for follow-up announcements instead of being surprised by each one. The course of events so far is summarised in our PHP2Shell chronology.
Why further announcements are likely
The following assessment is based on publicly known facts. It is not a prediction of specific vulnerabilities.
- An advisory is still outstanding. php.net is handling CVE-2026-115560 in the regular release cycle and has announced that the full advisory will be published with the next release. Until then,
session.upload_progress.enabled=0counts as the remedy. - The details were public early. According to several reports, details became known before the embargo expired. According to reports, watchTowr says it reproduced CVE-2026-109618. Such work often leads to follow-up questions about neighbouring pieces of code.
- Distributions deliver in stages. On 21 October, Ubuntu supplied the current releases with USN-8948-1 and followed up with USN-8948-2, delivering fixes for 14.04 to 20.04 via Ubuntu Pro. Red Hat wrote in its bulletin that some updates were available and others in progress.
- The development version is affected. According to php.net, PHP 8.6.0 RC4 also contains the fixes. Anyone testing pre-release versions has to bring these environments up to date as well.
- Old versions remain open. For PHP 8.1 and older there are only minimal source backports. Every vendor that ships such versions reports its status independently and at its own times.
How a new PHP vulnerability reaches you
Announcements arrive by different routes and with different reliability. The order is almost always the same: first the PHP project, then distributions and hosting providers, then authorities and media.
| Source | What you learn there | How reliable |
|---|---|---|
| php.net | affected branches, fixed versions, interim measures | primary source |
| Ubuntu, Debian, Red Hat | package status per release, time of delivery | primary source for your system |
| Hosting providers and panel vendors | status of their own PHP builds | binding only if in writing |
| BSI, CERT-Bund | situation assessment, warning level, recommendations | official assessment |
| Trade press and security companies | attack observations, figures, background | helpful, label as a report |
The difference between "a patch exists" and "my system has the patch" is important. The first statement is on php.net. The second you have to prove yourself for each server.
Subscribe to the announcements from php.net and your distribution by RSS or mailing list and forward them to a shared mailbox or a channel that more than one person reads. Holidays and illness are the most common reasons for delayed updates.
What to prepare before the next announcement
The experience from PHP2Shell shows where time is lost: when searching for servers, when clarifying responsibilities and when the restart is forgotten. All of this can be dealt with beforehand.
- Inventory: A list of all servers and websites with PHP branch, operating mode (PHP-FPM, mod_php, LiteSpeed) and package source. Without this list, every announcement starts with searching. How to manage it is described in the article Inventory of all websites and servers.
- Responsibility: For every system it is settled who patches, who restarts and who signs off. With hosting providers and agencies, this belongs in the contract.
- Assessment grid: Three questions are enough for the first classification. Is our branch affected? Do we use the affected function or operating mode? Is there a patch or only interim measures?
- Test route: A staging environment in which a PHP update can be tested in a short time.
- Proof: A fixed format in which package status, changelog hits and restart time are recorded.
How such a procedure works as a routine rather than as a fire-fighting operation is described under Patch management as a process. Background on how the PHP project handles vulnerabilities is provided by the page How the PHP project handles security vulnerabilities.
Your own configuration as an early warning system
Some follow-up announcements concern only certain settings. CVE-2026-115560 is an example: php.net names as a prerequisite that an application switches the session serializer at runtime while upload progress is active. Applications that never do this are not affected, according to php.net.
Anyone who knows their effective configuration can classify such announcements faster. For each branch, therefore, record which values are set on the server side and which applications may override them. A simple comparison of the active settings already helps:
# Effective values of the command line (the web configuration can differ)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Values set in the FPM pools (path differs by distribution)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
The command line does not necessarily show what applies in the web context. Clarity comes from the pool or VirtualHost configuration and, briefly and protected, a phpinfo page.
A further advantage: anyone who knows which interim values from the PHP2Shell week are still set can review them deliberately after the next regular release. Some settings, such as disabled upload progress, can remain sensible permanently. Others, such as very tight upload limits, you should adjust back to actual needs after consulting the specialist departments.
How does PHP SOS help?
- We follow the announcements from php.net, distributions and the BSI and assess new notices for your specific systems.
- Together with you, we create the inventory of all PHP installations and define responsibilities per server.
- Under a security maintenance contract, we install updates, restart all processes and document the status.
- For announcements without a patch, we set interim measures that cannot be overridden and verify them afterwards.
Frequently asked questions
Is there already a new PHP vulnerability after PHP2Shell?
On 23 October 2026, php.net published a notice on CVE-2026-115560. According to it, code execution is only possible with an unusual session configuration. A full advisory is to follow with the next regular release.
Do I have to act immediately after every new announcement?
Not every announcement calls for the same urgency. What matters are the severity, whether your configuration is affected and whether a patch is available. A defined procedure helps to assess this in minutes instead of days.
Where do I hear about new PHP vulnerabilities first?
Primary sources are the announcements on php.net and the security notices of your distribution, such as Ubuntu Security Notices, the Debian Security Tracker or Red Hat. The BSI provides information on warnings. Media reports are helpful but often later and less precise.
Why do distributions sometimes report days later than php.net?
Distributions have to adopt the fix into their own packages, build and test it. For older releases this can take longer or happen only through additional offerings. That is why it is worth following both sources separately.