In this article
If you updated your company website to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 after the PHP2Shell flaw, you did the right thing, but it does not cover everything. On October 23, 2026 the PHP project published a new advisory about a third flaw, CVE-2026-115560, that the October 21 update does not fix. It needs an unusual setup and PHP calls it an unlikely vector, but the temporary fix is simple: ask your team or host today to set session.upload_progress.enabled to 0 and restart PHP, then confirm in writing that the October 21 update was really applied.
What did PHP announce on October 23?
Two days after the emergency release, the project posted a short informational advisory about session «upload progress» tracking, the feature that shows a user how far a large file upload has got. The advisory says this feature can open a remote code execution path in one specific case, and that the fix will ship in the next regular release rather than as an emergency update, with a full advisory for the flaw at that point.
Two points matter for a business owner. First, this is a separate flaw, so running one of the four versions above is not enough on its own. Second, the same temporary measure was already listed in the advisory for CVE-2026-109619 on October 21. If your team applied it then, nothing new is needed: keep it in place.
Is your site exposed?
According to PHP's advisory, the problem only appears when three conditions meet:
- The PHP configuration sets session.serialize_handler to php_binary or php_serialize.
- The application code switches it to php at runtime with ini_set() before the session starts.
- Session upload progress is still enabled, which it is by default.
Most sites do not do this. The catch is that an owner rarely knows what every line does in a system built years ago or in an old plugin. So the safest choice: if your site does not show a progress bar for file uploads, switching the feature off breaks nothing and closes the door. If it does rely on it, ask your developers whether the code changes that setting at runtime.
Three days on: check the October 21 update actually landed
The original flaws, CVE-2026-109618 and CVE-2026-109619, are still the bigger risk. Saudi Arabia's National Cybersecurity Authority issued alert no. 2026-7949 about them, and the US agency CISA advised organisations to inventory every PHP system, patch internet-facing ones first, and take a system offline if it cannot be patched right away. CISA said it had not seen successful exploitation at the time of publication, which does not mean time is on your side.
Three points many people miss:
- Restart, not reload. Red Hat's bulletin states that configuration changes need PHP workers restarted, and that a reload alone is not enough.
- The version number may differ on Linux servers. PHP's announcement says Linux distributions received the patches in advance, so you may see a number other than 8.5.12, for example, even though the fix is in. Ask your host for written confirmation, not just a number. Red Hat notes that RHEL 8, 9 and 10 are all affected.
- How PHP runs changes the risk. The PHP project rates the risk highest for mod_php on Apache, while Red Hat says exploitation is harder in practice with default PHP-FPM. Harder is not impossible, so the update is needed in both cases.
5 questions to send your host or team today
- Which PHP version runs on each of our sites and systems, and does it include the October 21, 2026 fixes?
- Were the PHP workers restarted after the update, not just reloaded?
- Have we set session.upload_progress.enabled to 0? If not, do we actually need the feature?
- Does our site's code change session.serialize_handler at runtime?
- Do we have any site on 8.1 or older? Those branches are out of support, and the supported versions table shows that security support for 8.2 ends on December 31, 2026.
The Origami view
Three advisories in three days is normal after a major flaw: once researchers dig into one part of the language, they find what sits next to it. But it also says something about companies. Whoever patched on the 21st and closed the ticket will miss the warning of the 23rd. Security here is ongoing follow-up, not a task you finish once.
What we see in Saudi businesses is that the hard question is not «what is the flaw?» but «who on our side reads a PHP advisory on a Friday morning and knows which server is ours?». At Origami we build websites and systems and keep their updates monitored from day one. If you want your site checked, or these settings applied without downtime, contact us.
The bottom line
The October 21 update is essential and still matters most; the new advisory does not change that. Add one cheap step today: switch off upload progress tracking unless you need it, restart PHP, and get written confirmation from your host. Then watch for PHP's next regular release, which will carry the final fix for CVE-2026-115560.
Sources
- PHP: informational advisory on session upload progress, October 23, 2026
- PHP: emergency security advisory and releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, October 21, 2026
- PHP on GitHub: advisory for CVE-2026-109619
- Saudi National Cybersecurity Authority (NCA): PHP alert no. 2026-7949
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching
- Red Hat: bulletin RHSB-2026-013 on the three PHP flaws
- PHP: supported versions table
Frequently asked questions
Is updating PHP to 8.5.12 or 8.4.27 enough to protect my site?
It covers the two critical PHP2Shell flaws, but not the new CVE-2026-115560 announced on October 23, 2026. For that one, PHP recommends setting session.upload_progress.enabled to 0 until the next regular release.
Will my site break if I switch off upload progress tracking?
Usually not. The feature shows a progress bar during file uploads, and most sites do not use it. If yours shows that bar, ask your team before switching it off, and either way restart PHP after the change.
My host says our version number differs from the announced ones. Are we exposed?
Not necessarily. Linux distributions received the fixes in advance and may carry different numbers. Ask your host for written confirmation that the October 21, 2026 fixes are applied and that the PHP workers were restarted.
When will the final fix for the new flaw ship?
PHP says it will fix it in the next regular release and publish a full advisory then, not in an emergency update, because the setup needed to exploit it is rare. Until then, the temporary setting is your protection.
Follow Origami in Google
Pin Origami as a preferred source and our articles will surface first for you in Google Search and Top Stories.
