PHP2Shell Part 2: What Changed After the First Patch

PHP2Shell Part 2 means checking the whole deployment after the first patch. Simply Data recommends verifying patched web-serving PHP, reviewing session configuration, rebuilding affected NativePHP Mobile apps and installing refreshed Windows packages where applicable. Vendor advisories and researcher allegations are different evidence, not proof that every WordPress site remains vulnerable.

Updated 27 October 2026.

What is PHP2Shell Part 2, and how is it different from Part 1?

Our first PHP2Shell article covered the 21 October PHP security releases for two critical flaws: CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state). That advice still stands, so keep those patches in place. This second part covers the five days that followed, which brought a mix of vendor follow-up and researcher claims (PHP.net, 21 October).

Keep those two kinds of information apart. The PHP project and NativePHP have published advisories that describe confirmed issues, with fixes or mitigations. A researcher repository dated 24 October claims further serialisation, session and Windows weaknesses, which it says survive the 21 October patch. We have not reproduced those claims, and the PHP project has not confirmed them as a set. Treat them as allegations to watch, not as established facts (researcher repository).

RedEye Security published a report on 24 October and updated it on 25 October to say the NativePHP fixes had shipped. NativePHP gives its own account of how the reports reached it, and the two accounts differ. We do not take a view on that. For site owners, the fixes are what matter (RedEye Security; NativePHP).

What happened between 21 and 26 October?

• 21 October: PHP released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 to fix CVE-2026-109618 and CVE-2026-109619 (PHP.net).
• 23 October: PHP issued an informational advisory on session upload progress. This is a narrow follow-up tracked as CVE-2026-115560 (PHP.net).
• 24 October: a researcher repository and a RedEye Security report claimed further weaknesses beyond the October patch (repository).
• 25 October: NativePHP published seven advisories for NativePHP for Mobile. The /_assets traversal, event-class instantiation and Android cookie-logging findings are fixed in nativephp/mobile 4.6.1 and 3.3.11 for the affected branches. Both async findings affect versions >=4.5.0, <4.6.1 and are fixed in 4.6.1; the core File.Move/File.Copy finding affects 4.x before 4.6.1 and is fixed in 4.6.1. The separate mobile-file plugin finding is fixed in 1.0.3; 4.x apps should remove that redundant plugin (NativePHP).
• 26 October: PHP published rebuilt Windows packages that include Brotli 1.2.1. The PHP runtime versions did not change (PHP.net).

Do you still need to act on the PHP session follow-up?

Only a narrow set of setups is affected, but the mitigation is cheap. PHP says the CVE-2026-115560 issue needs all three of these conditions:

1. session upload progress is still enabled;
2. the configuration sets session.serialize_handler to php_binary or php_serialize; and
3. application code switches the handler to php with ini_set() before it calls session_start().

PHP suggests setting session.upload_progress.enabled=0 until the next regular bugfix release and says a full advisory will come with that release. If you applied this setting after the 21 October advisory, leave it in place. Applications that never change the serialize handler at runtime can keep the feature on (PHP.net, 23 October).

This setting covers one issue, not every risk. For CVE-2026-109619, PHP says it blocks the confirmed session paths but not other variants, so it does not replace a patched release. Set it in php.ini, in the FPM pool or in server configuration that applies before request parsing. Do not rely on ini_set() or an FPM .user.ini file. Then restart every worker (GHSA-6wmf-4rv5-p3rp).

Has the patch reached the PHP that serves your website?

A common gap after an emergency release is patching the wrong PHP. The command-line binary, PHP-FPM pools, Apache mod_php, containers and control-panel PHP selectors can each run a different build. Running php -v over SSH only tells you about the command line, which may not be the worker answering web requests. Check the version and loaded configuration of each web runtime, then restart its workers so old processes stop.

Linux distributions and LTS vendors received the patches early and often backport them, so a version string alone can mislead you. Ask your hosting provider or distribution for the advisory or changelog entry that confirms the backport for your package. PHP 8.1 and older no longer get updates from the PHP project. Its minimal source backports for 7.4, 8.0 and 8.1 were a one-off because of the severity, not renewed support, so plan a move to a supported branch (PHP.net).

What should NativePHP Mobile teams do?

Most of the seven advisories concern the internal routes the web view uses to talk to the native side. Most also need script that is already running on the app’s own origin, for example through an XSS bug or a compromised third-party script bundled with the app. That is serious, but it is not the same as an unauthenticated attacker reaching every app remotely (GHSA-9884-fw9c-mq85).

Not every finding affects every version or platform:

• On the 4.x line, update nativephp/mobile to 4.6.1. The async task findings affect only 4.5.0 and later. The core File.Move and File.Copy issue exists only on 4.x.
• On the 3.x line, update to 3.3.11 for the findings that apply to it. These include the /_assets path traversal on both iOS and Android (GHSA-76px-r497-93p9).
• The session cookie logging issue affects Android only and is fixed in 4.6.1 and 3.3.11 (GHSA-27jx-7m9x-fx5c).
• 3.x apps that use nativephp/mobile-file should update it to 1.0.3. 4.x apps should remove the plugin, because it can override the safer built-in core functions (GHSA-7927-vv5p-fv4f).
• Versions 1.x and 2.x are end-of-life and will not be patched.

Updating the Composer package is not enough. Several fixes change generated Swift, Kotlin or C code, and that code only reaches users after you run php artisan native:install –force, rebuild, test and ship a new release, including app-store submissions. Builds already on users’ devices stay vulnerable until they are replaced. NativePHP has also rebuilt the PHP runtime it embeds on the patched PHP releases, and the same steps pick that up. NativePHP Desktop is a separate product, so follow its own guidance (NativePHP).

Why are there new Windows PHP builds?

On 26 October PHP released Windows packages 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1. They include Brotli 1.2.1, which fixes CVE-2026-111497, an out-of-bounds write in Brotli decompression. In Windows builds of PHP, the vulnerable decoder can be reached through the cURL extension when automatic HTTP response decompression is turned on. cURL leaves it off by default, but applications and HTTP client libraries can switch it on (PHP.net, 26 October; Brotli 1.2.1).

The -1 suffix marks a package rebuilt with updated dependencies. The PHP source and runtime version stay the same, so a version check will still show 8.4.27 or similar. Track the package build instead. PHP does not describe this rebuild as addressing the researcher’s Windows file-handling claim. The researcher describes that as a local issue, and we have not verified it (repository).

How should a SOC monitor PHP servers after PHP2Shell Part 2?

Monitoring only works if the right data is collected. Before you rely on any detection, check that these sources reach your SIEM:

• PHP, PHP-FPM, web server and service logs, including fatal errors, “Maximum execution time exceeded”, worker crashes and restarts, and warnings that repeat before scripts run.
• Process, file and network events from EDR or OS audit logs. Examples include the web worker account starting shells or unexpected programs, new files in web roots and unusual outbound connections.
• Proxy or WAF fields such as request size, multipart part counts and a missing Content-Length, but only if your proxy actually records them.
• HTTP access logs, for timing and source correlation. They cannot prove that a process ran, and they do not contain multipart request bodies.

Read the results with care. Crashes and fatal errors often have ordinary causes and are not proof of an attack. A quiet log is not proof of safety either, and PHP notes that older logs may have left out relevant severity levels. If something looks suspicious, preserve the logs and host evidence before you rebuild, and involve incident response early (GHSA-6wmf-4rv5-p3rp).

What can a VAPT confirm, and what can it not?

An authorised vulnerability assessment and penetration test (VAPT) works within an agreed scope. It can check that in-scope hosts run patched or vendor-backported PHP, that mitigations are set where they actually take effect and that applications still behave as expected. Any findings then need fixing and a retest. No test can promise there are no unknown vulnerabilities. Testing on production systems should avoid destructive or disruptive techniques unless these are explicitly agreed.

What belongs on the change checklist?

Give each item a named owner and a date. For PHP2Shell Part 2, a practical change record looks like this:

1. Change owner: list every web-serving PHP runtime, container, Windows host and NativePHP app, with its package source.
2. Backup owner: take backups of configuration, code and databases, test that they restore, and write a rollback step for each change.
3. Platform owner: install patched or vendor-confirmed backported PHP on the web runtime, then restart every worker.
4. Configuration owner: if the feature is not needed, set session.upload_progress.enabled=0 in startup configuration. Check it on the web runtime through an access-controlled method, not a public diagnostic page.
5. Windows owner: replace Windows PHP packages with the -1 builds.
6. Mobile owner: update NativePHP Mobile, then regenerate, rebuild, test and release the app to installed devices.
7. Application owner: run business smoke tests on logins, contact and payment forms, file uploads, admin pages and scheduled jobs.
8. SOC owner: confirm the data sources above are arriving and record what was checked.
9. Approver: sign off the change, or roll it back if smoke tests fail.

How can Simply Data help?

Simply Data Sdn. Bhd. is a Malaysian cybersecurity company. Our 24×7 Security Operations Centre provides managed monitoring, and our VAPT services include authorised, scoped testing and one retest after the client’s fixes. To discuss PHP security checks, scoped testing or monitoring coverage, contact Simply Data.

What questions do Malaysian teams ask about PHP2Shell Part 2?