Skepra / Web recovery & resilience
On 20-21 October 2026 the PHP project disclosed two critical, unauthenticated remote code execution vulnerabilities in core PHP memory handling.
Ask whether this applies to your siteCVE-2026-109618 (out-of-memory handling corrupts memory) and CVE-2026-109619 (stale global state survives a fatal error) allow unauthenticated remote code execution on PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest-risk configuration.
PHP versions prior to 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and earlier are end-of-life and receive no fix from the PHP project.
The PHP project disclosed a third, related issue, CVE-2026-115560, that can lead to RCE only under an unusual combination: the application must set session.serialize_handler to php_binary or php_serialize in configuration, then switch it to php at runtime with ini_set() before calling session_start(), with session.upload_progress still enabled. PHP calls this setup unlikely in practice and is fixing it in the regular release cycle rather than an out-of-band one. The mitigation is the same one already published for CVE-2026-109619 on 21 Oct: set session.upload_progress.enabled=0. A site that already applied that mitigation needs no further action for this issue.
The PHP project's announcement, The PHP Foundation's writeup, the PHP project's informational note on CVE-2026-115560, and CERT-EU Security Advisory 2026-018.
Ask your host or developer which PHP version serves your site, or check it yourself if you have shell or phpinfo() access. Compare it against the affected-versions list above. If you are on a managed WordPress or hosting platform, check whether the host has already patched PHP at the platform level before assuming your site is exposed. For CVE-2026-115560 specifically: it only matters if your application changes session.serialize_handler at runtime via ini_set(), which most WordPress/WooCommerce sites do not do.
