What happened with PHP2Shell?
On 21 October 2026, PHP released security updates for CVE-2026-109618 and CVE-2026-109619. Under the relevant conditions, both can allow remote code execution without authentication. Each has a CVSS v4.0 score of 9.2. This describes technical severity, not the probability that a particular business has already been attacked.
The PHP Foundation describes delays in fixing the memory issue and problems with coordinated disclosure. Early disclosures brought the release forward by one day. The immediate question for operators is which running systems have actually received the fix. [1] [3] [4]
Which PHP versions contain the fixes?
The table lists the first corrected upstream releases for the two vulnerabilities disclosed on 21 October. It does not give an all-clear for the additional CVE-2026-115560 announced on 23 October. Check subsequent vendor advisories as well.
Linux distributions and managed hosting packages may carry a backported fix under an older PHP version number. In that case, use the full package version and the vendor's security bulletin. PHP 8.1 and older branches no longer receive regular PHP project updates; vendor backports or the available minimal source patches need separate verification. They do not replace a planned move to a supported branch. [1] [4]
Swipe or scroll sideways to read the table.
| PHP branch | Corrected release | Evidence required |
|---|---|---|
| 8.2 | 8.2.35 | Active web package or documented vendor backport |
| 8.3 | 8.3.36 | Active web package or documented vendor backport |
| 8.4 | 8.4.27 | Active web package or documented vendor backport |
| 8.5 | 8.5.12 | Active web package or documented vendor backport |
Check the additional 23 October session advisory
PHP recommends temporarily setting session.upload_progress.enabled=0 until the next regular bugfix release. The notice concerns CVE-2026-115560 and an unusual combination of configuration and application code. Treat it separately from the two vulnerabilities already patched.
The stated condition is specific: session.serialize_handler starts as php_binary or php_serialize. The application changes it to php at runtime using ini_set(), before calling session_start(), while session upload progress remains enabled. PHP says applications that never change the handler at runtime can leave the feature enabled.
Ask the administrator to verify the effective setting. Precautionary disabling must take effect in server or PHP configuration before request parsing; restart affected workers. A later ini_set() in application code is not a substitute. Keep the setting if already applied. The notice does not yet name a date or new versions for the regular fix. This assessment was checked on 24 October 2026. [1] [2]
Why updating WordPress alone is not enough
The CMS and its PHP runtime are separate components. An updated WordPress, Drupal or Joomla installation does not establish that the web server is running corrected PHP. A website loading normally does not establish its patch status either.
Include shops, customer portals, subdomains and older installations alongside the main website. Identify the actual web execution path for each system. PHP-FPM is not automatically exempt; PHP also names mod_php, CGI, FrankenPHP and LiteSpeed. The command line may use a different PHP installation from the web server. Do not publish an openly accessible phpinfo() page to investigate. [1] [5]
Further reading: Why known vulnerabilities remain open despite available updates
Identify the system
Record the domain, application, hosting owner and PHP runtime actually serving requests.
Activate the fix
Install the appropriate package, replace affected workers and check session configuration separately.
Verify operation
Record the active package, functional checks and timestamp. Leave unresolved systems open.
A verifiable outcome, not just an update ticket
Each system needs an owner, a vendor reference and a check of its running instance. A command-line version string alone is insufficient.
Original schematic. These checks document operational state; they do not establish that a system was never compromised.
What to ask your hosting provider
A general answer such as “our servers are up to date” leaves important questions unresolved. Request confirmation for your particular systems. You can use this wording:
Please confirm the PHP web runtime and package version used for our website, the fix status for CVE-2026-109618 and CVE-2026-109619, and how the PHP advisory of 23 October 2026 concerning CVE-2026-115560 has been addressed. Please include the activation time and the relevant vendor or distribution advisory.
Swipe or scroll sideways to read the table.
| Question | Evidence needed | Unresolved if … |
|---|---|---|
| Which systems? | Domains and their web runtimes | only the main website is listed |
| Which fix? | Package version and vendor advisory for both CVEs | the answer only says “PHP 8” or mentions a CMS update |
| Already active? | Activation time and confirmation workers were replaced | the package is merely available to install |
| Session advisory checked? | Effective setting or a documented reason it does not apply | the answer only cites the 21 October update |
| Application still works? | Checks of login, forms, uploads and relevant jobs | only the homepage has been opened |
What WAF alerts and attack attempts actually show
A web application firewall may provide additional protection against particular attack paths. It does not replace a PHP update or verification of effective configuration. If an update is not immediately possible, agree limiting measures or temporary isolation with the responsible administrator; follow the complete vendor guidance.
AWS documented attempts in its MadPot telemetry before public disclosure. AWS also states that it is unclear whether those attempts would have succeeded on real systems. Attempt counts therefore do not count compromised businesses. Equally, a quiet dashboard does not prove an instance was untouched. [1] [5] [6]
When the work is ready to close
For each system, record the owner, active package, vendor reference, activation time and functional test result. Keep patch verification separate from incident investigation: a system patched today does not explain what happened before the update.
If file changes, unexpected processes or suspicious access suggest compromise, preserve available logs and involve the responsible incident-response team. An external security assessment can examine visible systems and anomalies; it cannot conclusively confirm internal package state or compromise without additional evidence.
- Relevant PHP web systems and responsible owners recorded.
- Fixes for both original CVEs verified in the running instance.
- The 23 October session advisory checked and documented separately.
- Business-critical functions checked after the change.
- Unresolved systems assigned a next action and deadline.
- Suspected incidents investigated separately; patching not treated as a forensic all-clear.
Sources
- PHP · Critical remote code execution vulnerabilities (21 October 2026)
- PHP · Session upload progress advisory (23 October 2026)
- PHP Foundation · Security release and disclosure background (21 October 2026)
- NHS England · Critical Vulnerabilities in PHP, CC-4875 (21 October 2026)
- NCSC · Critical security issue affecting PHP (21 October 2026)
- AWS · PHP2Shell attempts observed in MadPot (21 October 2026)