Check if you’re affected

It depends on which Cloudflare service you actually have, and even the best case is a mitigation rather than a fix.

• Cloudflare DNS only, or the free plan proxying your site: this hides your server’s address and absorbs some traffic, but it does nothing to the PHP installation behind it. Requests still reach your server and PHP still processes them. You are not protected against these vulnerabilities.
• Cloudflare with a Web Application Firewall (Pro, Business or Enterprise managed rulesets, or custom rules): a WAF can block the known attack patterns once rules are available and enabled. That reduces exposure while you patch, but WAF rules work by recognising requests and attackers adapt them. It is not equivalent to running a fixed version of PHP.
• Either way: if the server can be reached directly, bypassing Cloudflare (for example on its real IP address, or via another hostname that is not proxied), the WAF is irrelevant for that path.

Use Cloudflare as a reason to patch in an orderly way, not as a reason not to patch. Confirm the PHP version on the server itself and update it.

WordPress is not the vulnerability, but WordPress runs on PHP, so the PHP version underneath your site is what matters. The same applies to Drupal, Joomla, Magento, Laravel and most other PHP-based platforms.

In WordPress go to Tools → Site Health → Info → Server and read the PHP version. If it is below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your host has not confirmed a backported fix), contact your host or agency and ask for the update. Updating WordPress plugins or themes does not fix this.

Usually they will apply the update, but confirm it rather than assume it. Ask them two specific questions and keep the answer: which PHP version is serving your website today, and if it is older than the fixed versions, whether the vendor has applied a security backport for CVE-2026-109618 and CVE-2026-109619.

Good hosts had the patches before public release. If yours cannot answer, or says the update is “scheduled” without a date, escalate.

Neither, and that is the honest answer. Most properly configured servers do not reveal their PHP version to the public, so a public check cannot tell whether you are patched. An inconclusive result is the expected outcome for a well-run site.

The only reliable answer comes from the server itself. Use the “Verify your PHP version” step on your results, which explains where to look in WordPress, cPanel, Plesk or over SSH, or ask whoever hosts your site.

Often, yes. Most shared hosting control panels let you choose the PHP version per site: in cPanel look for MultiPHP Manager or Select PHP Version, in Plesk open the domain and choose PHP Settings. Pick the newest patch release of your branch.

If the fixed release is not offered yet, the host has not deployed it. Raise a ticket and ask when it will be available; in the meantime the PHP project’s temporary mitigations only apply if you control the server configuration, which on shared hosting you usually do not.

Updating is the only complete fix. The PHP project has published temporary settings (around memory limits, request sizes and session upload progress) that reduce exposure to specific attack paths, but the project is explicit that they do not make an installation safe.

If you cannot update or apply the mitigations promptly, the NCSC’s advice is to consider taking the system offline until it can be fixed, and to check for signs of compromise before assuming an update alone has resolved the matter.

This check cannot tell you; it only looks at what your website shows the public. Signs worth looking for on the server itself include unfamiliar PHP files in upload or temporary directories, new scheduled tasks or cron jobs, new administrator accounts, unexpected outbound connections, and unusual entries in web server logs around the disclosure date.

If you are not confident assessing this, use an NCSC-assured incident response provider or speak to Espria’s cyber security team before you rebuild or update, so that evidence is preserved.

Fully hosted platforms such as Wix, Squarespace and Shopify do not run PHP for your site, and static sites have no server-side code, so your website is not the exposure. The platform provider is responsible for any PHP they use internally.

That does not mean your organisation is clear. PHP is bundled in many other products, including intranets, monitoring tools, network appliances and self-hosted applications. NCSC-NL maintains an inventory of affected software; review it and check every system you run, not only the public website.

No. The assessment reviews the public front page of the single address you enter, nothing else. Other hostnames (for example a customer portal on a subdomain), internal systems, APIs and anything behind a login are not assessed. Run separate checks for other public hostnames and verify internal systems directly or with help from your IT provider.