A new PHP security warning on October 23, 2026, adds a narrow but important qualification to the emergency patching campaign underway across the web. After releasing fixes for two critical vulnerabilities on October 21, the PHP project advised administrators to disable a session-upload-progress setting in an unusual configuration until a future bugfix release. The warning arrives as security providers and news organizations report large volumes of attempted exploitation.
For website owners, the practical message is not that every PHP website has been breached, or that the emergency fixes are useless. It is that teams must check which runtime they actually use, install vendor-supported security updates, understand a newly described edge case and avoid treating a web application firewall as a complete substitute for patching.
What changed in the October 23 PHP security warning?
The PHP project's October 23 advisory recommends setting session.upload_progress.enabled=0 until the next regular bugfix release to protect against an unlikely remote-code-execution path. The condition is unusually specific: an application must configure its session serialization handler as php_binary or php_serialize, then switch it to php at runtime before starting a session, while upload progress remains enabled.
PHP says applications that never change the serializer at runtime can leave upload progress enabled. It plans a fuller advisory under CVE-2026-115560 with a later release. This is a newly highlighted, narrowly conditioned issue; it should not be described as proof that the two earlier vulnerabilities remain generally unpatched. Administrators should confirm the relevant configuration with their host or developer before making changes that could affect application behavior.
What the emergency fixes already address
On October 21, the PHP project published security releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 for two critical flaws, CVE-2026-109618 and CVE-2026-109619. According to the project's security notice, both could allow unauthenticated remote code execution in vulnerable server configurations. That means an attacker might be able to run code without first logging in, not merely read a page or submit an ordinary form.
The project identifies a particularly serious demonstrated attack path in Apache's mod_php deployment, while warning that PHP web runtimes generally need attention. Organizations on older PHP versions should not assume an upstream release exists for their branch: PHP says some long-term-support distributors provide backported patches, and administrators should verify the actual vendor fix rather than comparing version numbers alone.
That distinction is especially important on managed hosting. A site owner may see one PHP version in a dashboard while the hosting company applies distribution-level security fixes behind the scenes. The right question is whether the active runtime contains the relevant patches, with evidence from the provider.
Why reports of millions of attacks do not mean millions of breaches
Reuters reported on October 22 that Cloudflare observed attempts climbing from thousands before public disclosure to millions afterward. Amazon also reported widespread exploitation activity. These are measurements and observations of attempted attacks across provider networks, not a verified count of successful intrusions or affected organizations.
Reuters documented precautionary website shutdowns at government agencies and major companies in several countries. At least one government technology provider said its service blocks were precautionary and not the result of a confirmed breach. That difference matters: taking a service offline to apply a patch can be disruptive without indicating that attackers gained access.
Why a web application firewall is only a temporary layer
On October 22, Amazon Web Services updated its technical guidance to describe version 2.3 of its PHP managed firewall rule group. The new PHP2Shell_BODY rule targets request patterns associated with CVE-2026-109619. AWS says customers using the default rule-group version should verify that the rule is active; those pinning older versions may need to update their configuration.
A firewall can inspect and block certain incoming request patterns, but it cannot see every condition inside PHP's memory or server configuration. AWS explicitly says its managed rule does not cover CVE-2026-109618, and other protective rules have request-size and inspection limits. A firewall is therefore a risk-reduction measure during patching, not evidence that an unpatched server is safe.
Site owners should also avoid copying firewall settings blindly. A rule that blocks multipart form submissions may disrupt legitimate uploads, checkout forms or administrative tasks. Changes should be tested and logged by someone responsible for the environment.
What a website owner should ask their hosting provider today
Start by identifying whether the website actually runs PHP. A content-management system, reverse proxy and hosting dashboard are not interchangeable evidence about the underlying runtime. Then ask the provider to confirm the installed security fix for both October 21 CVEs, including any vendor backport, and whether PHP processes were restarted after patching.
Next, ask whether the unusual session-serializer configuration described on October 23 exists in the application, and whether disabling session upload progress is appropriate. Finally, request a review of relevant security logs and any blocked requests, with an escalation path if suspicious behavior is found. A spike in probes alone is not proof of compromise, but it may justify closer inspection.
Organizations should document the answer, test important site functions after maintenance and retain a rollback plan for operational problems. Unhyd's earlier guide to software supply-chain security explains the broader challenge: organizations need an inventory of components and vendors before they can respond reliably to a flaw in shared infrastructure.
The larger lesson is about visibility, not panic
The October 23 warning is a useful example of why a security incident can evolve after the first patch notice. One set of fixes addresses two disclosed vulnerabilities; a later advisory describes a separate, rare configuration risk; and network defenders continue to observe attempts while systems are updated. Those facts should be kept separate rather than collapsed into a claim that all websites are vulnerable or compromised.
For businesses dependent on a website, the immediate goal is a documented answer from the people who operate its runtime: what is installed, what was patched, what temporary protections exist and what still needs verification. That is more actionable than an alarming attack-count headline—and more reliable than assuming a firewall has solved the problem.
