PHP2Shell: Two Critical PHP Flaws and the Safe Versions

The PHP security team released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on 21 October 2026 to close two critical flaws nicknamed PHP2Shell. CVE-2026-109618 and CVE-2026-109619 both score 9.2 on CVSS v4.0 and can lead to remote code execution without a login. Any server that runs PHP for the web should be checked now.

What the PHP team announced

On 20 October 2026, the PHP security team gave advance notice of a release scheduled for 21 October at 14:00 UTC, addressing two critical vulnerabilities. It also reserved the right to ship earlier if details leaked or exploitation appeared. According to SecurityWeek, early details had already circulated publicly before the official disclosure.

In its official advisory on php.net, the team said every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The team wrote: “We consider the risk highest for mod_php.” A demonstrated exploit there lets a single unauthenticated request trigger the attack before any application code runs.

That means the quality of application code offers no protection. The flaws sit in the PHP engine itself, so WordPress sites, Laravel applications, and custom systems are all exposed until the server’s PHP version is updated.

How the two flaws work

CVE-2026-109618 involves out-of-memory handling. According to the GitHub advisory, PHP uses longjmp() to leave a request when memory runs out. In some contexts, request data is not fully initialized at that point, so cleanup at the end of the request reads invalid data. Attackers can provoke the out-of-memory condition through multipart upload parsing, for example with nested fields or unlimited headers.

CVE-2026-109619 involves stale global state. Internal state owned by one request can survive after its memory is freed, and a later request handled by the same worker process may then use it.

The PHP team stresses that there is no complete mitigation. Configuration changes only reduce specific attack paths, and updating is the only safe choice.

Affected versions and fixes

Per AWS security bulletin 2026-143 and the PHP advisory, supported branches have a fix and older branches do not.

PHP 8.1 and older no longer receive updates from the PHP project. Some Linux distributions and long-term support vendors ship backported fixes, so check your vendor’s packages. For teams building from source, the PHP team published minimal backports for PHP 7.4, 8.0, and 8.1. AWS notes that CVE-2026-109618 has no fix on end-of-life branches, so moving to a supported branch remains the end goal. PHP 8.2 itself reaches end of life on 31 December 2026.

Exploitation status: sources differ

Early reports on the scale of attacks vary. Security firm watchTowr said its honeypot network observed exploitation of both flaws on 21 October 2026. SecurityWeek’s update noted that after the patches shipped, several companies reported exploitation attempts. Before the release, Huntress said it had not seen exploitation among its customers.

Because the picture is still changing, do not wait for certainty about attack volume. Treat internet-facing servers as if they were already targets.

AWS says AWS services themselves are not affected, but customers running vulnerable PHP versions on services such as Elastic Beanstalk, Lambda (through custom runtimes or containers), Amazon Linux, and Lightsail still need to act. According to the bulletin, AWS WAF users on the default version of the PHP managed rule group are protected automatically while they patch.

What this means for IT teams and site owners

Schools, government offices, online shops, and companies in Indonesia often run PHP sites on shared hosting or their own servers. The first job is to learn which PHP version actually serves each site, since many servers keep several versions side by side. Site owners on shared hosting do not control the server, but they can still ask the provider whether PHP has been updated to a safe version, when that will happen, and whether any other PHP version remains active on their account. Keep the answers on file, because they will be useful if a security review follows.

A few notes on those steps:

1. Do not trust php -v alone. It reports the command-line binary, which can differ from the PHP-FPM or Apache version serving the web. Check with php-fpm8.4 -v (adjust the version number) or a phpinfo() page. On Debian or Ubuntu, Aikido suggests apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619" to confirm the package carries the fix.
2. Update through your distribution or provider. New packages can arrive hours after the official release, so try again if they are not yet available.
3. Restart long-running processes. Queue workers, Laravel Horizon, Octane, and other background processes keep running the old PHP until restarted.
4. Watch for signs of compromise. watchTowr lists indicators such as very large or deeply nested multipart requests, PHP workers that crash on memory, new files in web directories, and unexplained outbound connections.

Laravel Forge users should note one thing: according to Forge’s documentation, automatic security updates do not patch PHP because it is installed from a separate package repository. The update must be applied on each server, including PHP versions that no site currently uses.

If an update cannot be installed today, the PHP team lists risk-reducing steps, such as memory_limit=-1 locked through php_admin_value, a low post_max_size, and session.upload_progress.enabled=0. All of them are stopgaps. On 23 October, PHP added an informational note advising teams to keep session.upload_progress.enabled=0 until the next fix release, covering an attack path judged unlikely that will get its own advisory (CVE-2026-115560). Restricting internet access to servers that cannot yet be updated is also sensible.

Managing many PHP servers takes discipline. Teams without a routine update procedure can start with an inventory of internet-facing systems, supported by a cybersecurity service or a restructuring of applications through web application development. We covered a similar case in the critical GitLab flaw scored 10.

Frequently asked questions

Is my WordPress or Laravel site affected?

Yes, if the PHP on your server is below 8.5.12, 8.4.27, 8.3.36, or 8.2.35. The flaw is in the PHP engine, so updating the application does not replace updating PHP.

My server runs PHP 7 or 8.1. What should I do?

The PHP project is not releasing fixes for those versions. Ask your hosting provider or Linux distribution for backported packages, or move to a supported branch. Until then, limit the server’s exposure to the internet where possible.

Are configuration settings enough instead of updating?

No. The PHP team says settings only reduce specific attack paths and do not make an installation safe. Updating remains the only complete fix.

Conclusion

PHP2Shell touches the most basic layer of many sites in Indonesia. The best time to check your PHP version is today, while the server list is still easy to gather. If your team wants a partner to talk through inventory and update procedures, Merakit is ready to help.

Sources

• PHP.net, security advisory and releases of 21 October 2026, and informational advisory of 23 October 2026
• GitHub php-src, advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618), 21 October 2026
• AWS, security bulletin 2026-143-AWS, 21 October 2026 (updated 22 October)
• Laravel Forge, PHP security advisory, October 2026
• SecurityWeek, PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws, 21 October 2026 (updated 22 October)
• watchTowr, PHP2Shell RCE Exploited, October 2026
• Aikido Security, PHP2Shell: affected versions and fixes, 21 October 2026 (updated 23 October)