# Is my website affected by the PHP flaw? How to check | Fokuus [Home](https://fokuus.be/en/) [Blog](https://fokuus.be/en/blog/) Is my website affected by the PHP flaw? How to check # Is my website affected by the PHP flaw? How to check Does the October 2026 PHP flaw affect your website? Five steps to check whether your site runs on PHP, which version, whether your host has already patched and whether there are traces of an attack. [Anton Pycarelle](https://fokuus.be/en/about/) 22 October 20267 min read time ## In this article - [Step 1: check whether your site runs on PHP](https://fokuus.be/#stap-1-kijk-of-je-site-op-php-draait) - [Step 2: find your PHP version](https://fokuus.be/#stap-2-zoek-je-php-versie-op) - [Step 3: ask your host whether it has been updated yet](https://fokuus.be/#stap-3-vraag-je-host-of-het-al-bijgewerkt-is) - [Step 4: look for signs of a break-in](https://fokuus.be/#stap-4-zoek-naar-sporen-van-een-inbraak) - [Step 5: if you're unsure, work in this order](https://fokuus.be/#stap-5-twijfel-je-werk-dan-in-deze-volgorde) - [When you can tick it off](https://fokuus.be/#wanneer-je-het-mag-afvinken) You read the news about a critical flaw in PHP and you wonder whether it affects your website. Maybe you don't even know whether your site runs on PHP, let alone which version. You can find that out in five steps, and for the first two you need little technical knowledge. The PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October, fixing two critical vulnerabilities. According to [php.net](https://www.php.net/archive/2026.php#2026-10-21-5) every PHP installation that handles web requests is at risk, and updating is the only complete fix. You can read exactly what happened in [our article on PHP2Shell](https://fokuus.be/en/blog/php2shell-php-lek/) . Affected or not: the five steps below, summarised in two questions. ## Step 1: check whether your site runs on PHP PHP is the programming language behind WordPress, WooCommerce, Joomla, Drupal, Magento, PrestaShop and Craft CMS, among others. A static site consists of ready-made files and doesn't need PHP. With a hosted site builder such as Wix or Shopify, the provider manages the servers, and updating is up to them. If you don't know what your site is built on, check your web developer's quote or invoice: it often simply says "WordPress". Or go to yourdomain.be/wp-admin/. If you get a WordPress login screen, you have your answer. An error page proves nothing: some WordPress sites hide that address with a plugin such as [WPS Hide Login](https://wordpress.org/plugins/wps-hide-login/) , and Joomla and Drupal run on PHP too. Some servers also show PHP in their headers, as `x-powered-by: PHP/8.3.x`; how to look at them is explained in [our explanation of hosting](https://fokuus.be/en/blog/wat-is-hosting/) . If that line is missing, that tells you nothing either. On our own site, fokuus.be/wp-admin/ returned a 404 on 22 October at 11:37, with no trace of PHP in the headers. That test alone proves little. What counts is how the site is built: fokuus.be is a static site on Netlify, with no PHP serving visitors, so there is nothing for us to patch for this flaw. ## Step 2: find your PHP version You can see which PHP version your website uses in WordPress under Tools > Site Health > Info > Server, on the line PHP version. In the Dutch used in the Netherlands, those screens are called Sitediagnose and Informatie. You need an administrator account for this. Many hosts also show the version in their control panel; at Combell it is listed under the [PHP settings](https://www.combell.com/nl/help/kb/hoe-kan-ik-php-versie-en-instellingen-wijzigen/) of your web hosting. If you only see a release series such as 8.3 there, ask for the full number or check in WordPress. Compare what you see with the patched versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you see that number or a higher one within the same series, for example 8.3.37, the fix is included. A lower number doesn't automatically mean you're vulnerable. According to [php.net](https://www.php.net/archive/2026.php#2026-10-21-5) some Linux distributions and vendors backport the fix into their own packages, including for older series. You then see a lower number even though the fix is in there. In that case, check with your host (step 3). If you see 8.1 or older, that version no longer gets updates from the PHP project: for 7.4 through 8.1 only changes to the source code were released, so whether your server has the fix depends on your host. Moving to a newer version is then work to do now, even if your host built in the fix (on 8.2 you have [until the end of December](https://www.php.net/supported-versions.php) ); how to go about that is explained in [our checklist](https://fokuus.be/en/blog/php-wordpress-site-beveiligen/) . ## Step 3: ask your host whether it has been updated yet With shared hosting, the ordinary web hosting package, you can't update PHP yourself. At most you choose in the control panel which version your site uses; your host installs the security update on its servers. First check your host's status page and your mailbox. If you have shared hosting with Combell, your answer is in [the incident on its status page](https://status.combell.com/nl/incident-yxm55r) . According to the update of 21 October at 20:46, all PHP versions from 5.6 up to and including 8.5 have been patched on the shared hosting clusters, and the cloud network has been almost fully updated, apart from a few exceptions (status as of 22 October, 11:56). If you find nothing, email or call and ask specifically: "Does the web hosting for yourdomain.be run on a PHP version with the fixes for CVE-2026-109618 and CVE-2026-109619, or are those fixes built into my version? If not, when will they be? And does that version still receive security updates?" With the CVE numbers included, a helpdesk knows right away what you are talking about. If you have your own server or VPS, updating is up to whoever manages it, and that isn't always your host. If that server runs a version older than 8.2, [WordPress.org](https://wordpress.org/news/2026/10/critical-php-security-release/) says you should consider taking your server offline while you prepare to update to a newer version of PHP. ## Step 4: look for signs of a break-in A patched flaw tells you nothing about what happened before the patch. You can't tell from one place whether your website has been hacked: some break-ins give themselves away through Google, your browser or your host, others only through files, pages or users that you didn't create yourself. Specifically: - The Security issues report in Google Search Console flags a problem when Google determines that your site has been hacked or could harm visitors, with sample URLs and the date on which Google first found the problem. If there is nothing, you see a green check mark ([Google](https://support.google.com/webmasters/answer/9044101?hl=nl) ). Your site must be registered in Search Console for this to work. - Chrome shows a warning that says Dangerous site when someone visits your site, or your site gets a warning label in the search results. - Search Google for `site:jouwdomein.be`: that also turns up hacked pages that are shown only to Google and not to you ([web.dev](https://web.dev/articles/how-do-i-know-if-my-site-was-hacked) ). - Filter in WordPress under Users > All Users on Administrator. New users that you didn't create yourself are listed by [WordPress.org](https://wordpress.org/documentation/article/faq-my-site-was-hacked/) as a clear indicator of a hack. - Have your host or web developer scan the files on the server, a step from the WordPress.org plan: a file quietly left behind isn't visible from the outside. - Your host takes your site offline or reports spam or malware, customers get a warning from their antivirus software, or you receive emails about accounts or passwords you can't place. If you see nothing, that is still no guarantee: not every break-in leaves traces that you or Google notice. ## Step 5: if you're unsure, work in this order If you see something strange, or you don't get a clear answer from your host, don't start deleting things at random. This follows the advice of WordPress.org, in the order I recommend: - Write down what you saw and when. - Contact your host: is the PHP fix in place, and do they see suspicious activity? With shared hosting, a break-in can affect more than just your site. - Make a backup, even if your site looks infected. That way you lose nothing during the clean-up. - Change the passwords for every access point: WordPress, your hosting control panel, FTP or SFTP and the database, including those of other users. If the fix wasn't in place yet at that point, do it again once it is; that second round is my own precaution. - Get help if the clean-up gets too much for you: your web developer, your host or us. If you ask us, we first look at the technology, the access and what you manage yourself, and we agree up front what is needed. More about that at [hosting and maintenance](https://fokuus.be/en/hosting-onderhoud/) . ## When you can tick it off You're done when you have three things in black and white. You know whether PHP runs on your server. Your version is at least 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your host confirmed in writing that the fix is in your version. And the traces from step 4 have been checked: a green check mark in Search Console, only known names among your administrators and a scan with no findings. If you're on 8.1 or older, the switch from step 2 is also on your list. All that checking doesn't prove that nothing ever happened. It does mean that this hole is closed and that you've looked where you could look. Website security WordPress Hosting Search Console Share [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ffokuus.be%2Fen%2Fblog%2Fwebsite-getroffen-php-lek%2F) [DotsApp](https://wa.me/?text=Is%20mijn%20website%20getroffen%20door%20het%20PHP-lek%3F%20Zo%20check%20je%20het%20https%3A%2F%2Ffokuus.be%2Fblog%2Fwebsite-getroffen-php-lek%2F) [Email](mailto:?subject=Is%20mijn%20website%20getroffen%20door%20het%20PHP-lek%3F%20Zo%20check%20je%20het&body=https%3A%2F%2Ffokuus.be%2Fblog%2Fwebsite-getroffen-php-lek%2F) ## Get Fokuus updates. New articles and Fokuus's updates in your mailbox. You can unsubscribe at any time. ## Anton Pycarelle Founder of Fokuus Anton builds and optimizes websites for Belgian SMEs from Kortrijk. He writes about choices and experiences from real projects. [More about Fokuus](https://fokuus.be/en/about/) ## Keep reading. [All articles](https://fokuus.be/en/blog/) Maintenance & Technique · 7 min reading time ### Secure a WordPress or PHP site: 10 things to check Secure a WordPress or PHP site: ten points, from a supported PHP version to an emergency plan, and who does each: you, your web developer or your host. [Maintenance & Technique · 7 min reading timeSecure a WordPress or PHP site: 10 things to checkSecure a WordPress or PHP site: ten points, from a supported PHP version to an emergency plan, and who does each: you, your web developer or your host.](https://fokuus.be/en/blog/php-wordpress-site-beveiligen/) Maintenance & Technique · 6 min reading time ### PHP2Shell: what the PHP flaw means for your website PHP2Shell: two critical vulnerabilities in PHP, the language WordPress runs on. What happened hour by hour, who saw exploitation and which versions contain the fix. [Maintenance & Technique · 6 min reading timePHP2Shell: what the PHP flaw means for your websitePHP2Shell: two critical vulnerabilities in PHP, the language WordPress runs on. What happened hour by hour, who saw exploitation and which versions contain the fix.](https://fokuus.be/en/blog/php2shell-php-lek/) [Bron](https://fokuus.be/en/blog/website-getroffen-php-lek/) · [Agentdocumentatie](https://fokuus.be/developers/)