Is my website vulnerable to the PHP flaw? How to check

Start with that question. Some rules of thumb:

• WordPress, WooCommerce, Joomla, Drupal, PrestaShop, Magento: always PHP.
• Shopify, Wix, Squarespace, Webflow: no PHP under your responsibility; the platform manages servers.
• Custom development: ask whoever built it.

If unsure which system you use, the check usually identifies it through traces such as a wp-login.php page.

A safe site runs one of these or later within the same branch: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. These contain the fix; see official PHP releases.

Find the version in three ways:

1. your host's control panel (cPanel, Plesk, DirectAdmin), usually under 'PHP version';
2. WordPress under Tools > Site Health > Info > Server;
3. ask your hosting provider or developer.

'PHP 8.3' without the final number tells you nothing: 8.3.35 is vulnerable, 8.3.36 is not.

The free Marketing Scan PHP check requests your homepage normally, like a browser, and reads the server's public information. It produces four possible outcomes:

• Outdated: the server reveals a version receiving no fix. Urgent.
• Unpatched: a supported branch without the fix. Update today.
• Hidden: PHP is present but its version is concealed. Good practice, but you must ask.
• No PHP detected: no PHP traces. Probably unaffected.

The check never attempts an exploit and cannot break anything. It provides no guarantee: only your host can confirm the actual server version.

Send your host or developer this message:

'Regarding CVE-2026-109618 and CVE-2026-109619: does our site run PHP, and what exact version? Is it updated to 8.2.35, 8.3.36, 8.4.27 or 8.5.12?'

If no clear answer arrives within a working day, call. With a CVSS score of 9,2 reported by Tenable, a day is already a long wait.

These can create false confidence:

• 'My site has an HTTPS padlock.' That secures the connection, not the server.
• 'WordPress is up to date.' WordPress and PHP are separate. Updated WordPress on old PHP remains vulnerable.
• 'I have a security plugin.' It runs on PHP itself and cannot close a flaw in PHP.
• 'Nothing has happened yet.' VRT NWS reports Cloudflare already sees initial attempts.

Signs include unknown CMS administrators, new files with strange names, redirects or Google Search Console warnings. If noticed, ask your developer to check for files left behind as well as updating. An update closes the door but does not remove an intruder already inside.

You remain responsible for data collected through your site. Three options, from quick to thorough:

1. Enable a newer PHP branch yourself in your hosting panel if possible. Back up first.
2. Place a firewall in front, for example Cloudflare. VRT NWS reports deployed rules against this flaw. This buys time without solving it.
3. Enable maintenance mode if handling sensitive data and nobody can update soon.

A developer silent for days after a flaw this large also raises longer-term questions. Specify deadlines for critical security updates in your next contract.