PHP Emergency Patches: What Site Owners Must Check

On October 21, 2026, PHP announced emergency security releases for two critical vulnerabilities that can allow remote code execution without authentication. For website owners, the immediate task is to confirm that the PHP runtime serving the site has been patched—not simply that WordPress or its plugins are current. The PHP security announcement urges immediate updates and says temporary mitigations are not a complete solution.

Our recommended response is to obtain patch evidence from your host, verify the running version, and test the customer journeys that matter to your business.

What PHP announced, and why it matters

PHP issued an advance notice on October 20, followed by release announcements on October 21. The official records identify:

• CVE-2026-109618: memory corruption associated with out-of-memory handling, potentially leading to remote code execution. PHP's official CVE record, published October 21, rates it Critical, CVSS v4.0 9.2.
• CVE-2026-109619: stale internal state involving freed memory, also potentially leading to remote code execution. PHP's official CVE record, published October 21, rates it Critical, CVSS v4.0 9.2.

PHP's advisory covers unpatched installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest-risk configuration and says an attack can occur before application code runs. Consequently, do not treat a CMS security plugin or application login as proof that the underlying runtime is protected.

Help Net Security's October 21 report independently reports the released fixes. Some coverage remains pre-release: the retrieved Tenable FAQ still describes patches as forthcoming. Use PHP's release announcements for current availability. Active exploitation is not independently verified for this article.

Match your PHP branch to its fixed release

Both official CVE records list the same affected ranges for supported branches. The corresponding PHP release announcements confirm these fixes:

PHP branch	Affected upstream versions	Fixed release
8.2	8.2.x below 8.2.35	8.2.35
8.3	8.3.x below 8.3.36	8.3.36
8.4	8.4.x below 8.4.27	8.4.27
8.5	8.5.x below 8.5.12	8.5.12

These announcements are dated October 21. The retrieved PHP changelog labels its 8.5.12 entry October 22 while listing the security fixes. That date discrepancy is unresolved; October 21 here refers specifically to the release announcements.

PHP 8.1 and older no longer receive regular PHP-project updates. The current advisory nevertheless provides exceptional minimal source backports for 7.4, 8.0 and 8.1, and directs owners to distribution or long-term-support vendors. These backports are not renewed ongoing support. Do not assume an old branch is safe because the CVE records enumerate only supported branches.

For vendor-maintained packages, ask for the vendor advisory and installed package revision covering both CVEs. PHP explicitly recognizes backported fixes; assess those using vendor evidence rather than the upstream version number alone.

Check the runtime your website actually uses

Start with the hosting panel

Open your site's PHP settings and inspect each relevant domain. For example, cPanel's MultiPHP Manager displays the PHP version assigned to each domain and whether it inherits the system default. Different domains can use different installed versions. If the panel gives only a branch label, ask support for the complete version and patch status.

Check WordPress Site Health

In WordPress, open Tools → Site Health → Info → Server, then find PHP version. This is the route documented in WordPress's PHP update guide. Compare the complete number with the table, not merely with a general recommendation to use PHP 8.3 or newer. That guide's broad minimum-version advice does not establish protection against these newly disclosed flaws.

Use the command line as an additional check

If you have authorized shell access, run:

php -v

The PHP manual documents this option as reporting the PHP version and server interface. A result marked cli describes the command-line executable. Do not use that alone to sign off the web runtime: ask your host to confirm the version serving web requests as well.

Keep verification records private. Do not publish diagnostic dumps or create a public information page just to check a version.

Request a specific update, not a general reassurance

WordPress's update guidance recommends backups, compatibility checks and coordination with the hosting provider. Our recommendation is to keep emergency patching focused: where practical, patch the existing supported branch rather than combining this incident with an unrelated redesign or migration.

Ask your host to confirm:

1. Which fixed PHP release or vendor-patched package is assigned to each site.
2. Whether that package addresses both CVE-2026-109618 and CVE-2026-109619.
3. Whether every relevant web-serving process has been restarted or replaced with the patched runtime.
4. When deployment completed, and how the running version was verified.
5. What remains unpatched, with an accountable owner and completion deadline.

For self-service cPanel hosting, the documented procedure is to select the domain, choose an available PHP version and apply it. If the required version is unavailable, contact the administrator; selecting an existing branch is not evidence that its security update has been installed.

Before the change, arrange a backup and a short acceptance checklist with your developer. If compatibility problems block the update, use website development support to resolve them rather than silently leaving the vulnerable runtime online.

If you cannot patch immediately

Treat this as an unresolved exposure, not a completed remediation. Consider asking your host to isolate the affected application from public traffic while arranging the update. Tenable's FAQ reports this isolation recommendation from CERT-EU; it is an operational option to discuss, not a claim that every site must follow the same shutdown plan.

PHP lists partial configuration measures in its security advisory, but explicitly warns that they do not make an installation safe. Have the host assess those measures together with availability and application requirements. Do not copy isolated memory-setting advice into production without administrator review.

If your host offers a web application firewall rule for this incident, ask whether it is enabled and what it covers. Treat it only as temporary protection, never as a substitute for the PHP fix. Neither a firewall status nor a configuration workaround closes the patching task.

Confirm security deployment and business operation separately

After deployment, repeat the panel and Site Health checks, and obtain the host's running-runtime or backport evidence. Our recommended business acceptance checks are:

• Open important public pages and sign in normally.
• Submit an authorized test inquiry and confirm its intended delivery.
• Test checkout in the approved test mode, where applicable.
• Check uploads, scheduled work and CRM handoffs your site depends on.
• Ask the administrator to review application and server logs for new errors or suspicious activity, keeping sensitive records private.

Record the results and unresolved issues separately from the patch confirmation. Do not equate a working homepage with proof of patching, or a patched runtime with proof that every customer journey works. If you took the site offline, include availability and indexing checks in your technical SEO review.

Close the task only when you have evidence for both outcomes: the runtime is patched, and the site's essential business functions have passed their checks.