Two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) can allow unauthenticated attackers to execute code on affected web servers. Both carry a CVSS v4.0 score of 9.2, and exploitation attempts are already being observed in the wild.

PHP has released the following fixed versions:

If you manage your own server or VPS, install the appropriate update immediately. On shared or managed hosting, confirm that your provider has deployed a patched PHP build.

What are CVE-2026-109618 and CVE-2026-109619?

Both vulnerabilities affect PHP’s handling of internal request data. These are flaws in PHP, not in a plugin,  theme, or application itself.

CVE-2026-109618 involves an out-of-memory condition that can interrupt PHP while request data is only partially initialized. PHP’s cleanup process may then treat that incomplete data as valid, causing memory corruption and potentially remote code execution.

CVE-2026-109619 involves stale internal state. A PHP worker may retain a reference to request data after the underlying memory has been released. A later request handled by the same worker can access that stale information before PHP resets it, potentially leading to information disclosure or remote code execution.

All PHP installations serving web requests should be considered potentially exposed, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP considers the risk highest for mod_php, where an unauthenticated request can trigger a demonstrated exploit before application code runs.

Updating your CMS, plugins, themes, or application code does not patch these vulnerabilities. You need a patched PHP build running on the server.

Is PHP2Shell being exploited in the wild?

Yes. Public proof-of-concept code began circulating before the official fixes were released, and several security companies have reported exploitation attempts.

Hadrian stated:

“We are now seeing php2shell exploited in the wild at scale.”

Hadrian added that most of the activity it observed abused PHP’s session upload-progress path and warned that more exploit paths were likely to appear. WatchTowr, Patchstack, Cloudflare, and Vega also reported malicious activity or attempts associated with the vulnerabilities.

Attempts are not necessarily successful compromises. However, the volume of activity and availability of public exploit material make rapid patching essential. Administrators should also review their servers for unfamiliar PHP files, unexpected scheduled tasks, unknown administrative accounts, suspicious outbound connections, and unusual upload-related requests.

How do I update PHP?

Prioritize these steps:

1. Install PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 using your operating system, hosting control panel, package provider, or established deployment process.
2. Restart or reload PHP workers and related services as required so they use the patched build.
3. Verify the PHP version serving the live website. The command-line version shown by php -v may differ from the version used by the web server.
4. Test critical functions such as logins, checkout, forms, uploads, scheduled tasks, APIs, and administrative pages.

On shared hosting, check your control panel for a PHP version selector. If the patched version is unavailable, contact your provider and ask whether it has deployed a vendor-backported fix or when the fixed release will become available.

What about PHP 8.1 and older?

PHP 8.1 and older are outside the project’s normal support cycle and will not receive standard upstream point releases. However, due to the severity of these vulnerabilities, PHP has published emergency source backports for PHP 7.4, PHP 8.0, and PHP 8.1. Linux distributions and long-term-support vendors may also provide patched packages.

You must still install a patched PHP build. That means upgrading to a supported release, installing an explicitly patched package from your operating-system or LTS vendor, or applying the emergency source backport when appropriate.

Do not assume an older installation is protected based only on its displayed version number. Vendors sometimes backport security fixes without changing the PHP branch. Confirm that the package specifically addresses both CVE-2026-109618 and CVE-2026-109619.

These backports are emergency fixes, not restored long-term support. Moving to a supported PHP branch remains the safer long-term option.

How does the Sucuri WAF help?

Sucuri’s existing WAF rules were already blocking some of the malicious request patterns associated with these vulnerabilities. We have now added more refined virtual patching rules to improve protection against known PHP2Shell exploitation paths across the Sucuri WAF network.

These rules are designed to identify and block known exploit requests before they reach the vulnerable PHP runtime. We will continue monitoring attack traffic and refining coverage as attackers modify their techniques and additional paths emerge.

This is an important benefit of virtual patching: customers can receive an immediate protective layer while server administrators and hosting providers complete the underlying update.

However, WAF protection does not replace patching. The firewall blocks malicious requests it recognizes; a patched PHP build removes the vulnerable behavior. Website owners should use both.

BYPASS PREVENTION: Don’t let attackers bypass your protection layer

WAF protection only works when requests pass through the firewall. If attackers can connect directly to your origin server, they may bypass the virtual patching rules and send exploit traffic directly to PHP.

Follow our guide to Preventing Firewall Bypass and verify that:

• Direct IPv4 and IPv6 access to the origin is restricted.
• The origin accepts web traffic only from approved Sucuri Firewall addresses.
• Alternate hostnames and old DNS records do not expose the origin.
• Staging, development, test, and backup environments are protected or access-restricted.
• Unprotected subdomains and alternate ports do not serve the same application directly.
• Old containers, server images, or autoscaling templates are not deploying vulnerable PHP builds.

What if I cannot patch immediately?

PHP states that updating is the only complete solution. Temporary configuration changes may reduce exposure to specific paths, but they do not make an unpatched installation safe.

Because much of the observed activity targets session upload progress, administrators who cannot patch immediately can disable that feature at the server level:

session.upload_progress.enabled = Off

Apply the setting through php.ini, an FPM pool, or another server configuration that takes effect before request parsing, then restart every affected PHP worker.

This mitigation has important limits:

• It only blocks confirmed session-related paths for CVE-2026-109619.
• It does not cover every possible CVE-2026-109619 path.
• It does not mitigate CVE-2026-109618.
• Applications that use PHP upload-progress reporting should be tested.

PHP provides additional temporary guidance for the out-of-memory path in its full security advisory. Treat every temporary measure as a short-lived stopgap while deploying a patched build.

Credits and references

PHP’s security advisories credit lcfr-hax, sagitzadik-wiz, tomash-areion, and amyb-oai with reporting the vulnerabilities.

References:

• PHP critical remote code execution advisory
• Release announcements for PHP 8.5.12,PHP 8.4.27,PHP 8.3.36, and PHP 8.2.35
• PHP 8 changelog
• CVE-2026-109618 GitHub advisory and CVE record
• CVE-2026-109619 GitHub advisory and CVE record
• SecurityWeek coverage of active PHP2Shell exploitation
• Sucuri Firewall bypass-prevention documentation

The immediate priorities are straightforward: install a fixed PHP release or confirmed backport, restart the relevant workers, verify the version used by the live website, keep the Sucuri WAF enabled, and ensure attackers cannot bypass it by connecting directly to the origin.

Frequently asked questions

Does updating WordPress fix CVE-2026-109618 or CVE-2026-109619?

No. These vulnerabilities affect the PHP runtime beneath WordPress. WordPress core, plugin, and theme updates do not replace or patch the PHP installation on your server.

Does the Sucuri WAF protect me if I have not updated PHP?

Sucuri’s existing rules were already blocking some related malicious request patterns, and more refined virtual patching rules have now been deployed for known PHP2Shell paths. This provides a strong additional layer of protection, but you must still update PHP and prevent direct access to the origin server.

Is disabling session.upload_progress enough?

No. It only reduces exposure to confirmed session-related paths for CVE-2026-109619. It does not fully mitigate that vulnerability and does not address CVE-2026-109618. Use it only as a temporary measure until a patched PHP build can be installed.