Website security: what the PHP vulnerability reminds us of

On 21 October 2026, the PHP team released emergency fixes for two critical flaws. Very quickly, attacks were already being seen. PHP runs a large share of the web: website security is not a topic reserved for big companies.

This article covers what happened, why it also concerns a small business, and what we check at Kayo, for a website as well as for an application or a SaaS.

The PHP2Shell flaw: what happened

Two vulnerabilities, referenced as CVE-2026-109618 and CVE-2026-109619 and nicknamed “PHP2Shell”, were fixed on 21 October 2026. They let a person without an account, from the Internet, run code on the server that runs PHP. CERT-EU gives them a severity score (CVSS) of 9.2 out of 10.

Time to act is short. Proofs of concept are circulating, according to CERT-EU. The company watchTowr says it observed attack attempts from 21 October. And on 26 October, the US agency CISA added these flaws to its catalogue of known exploited vulnerabilities. In Belgium, the Centre for Cybersecurity Belgium has also issued a warning and recommends updating as a top priority, or taking vulnerable systems offline in the meantime.

CERT-EU also reported, on 23 October, a third identifier (CVE-2026-115560) whose details were not yet published. As of 3 November, it still has neither a fix nor a full advisory: in the meantime, CERT-EU advises turning off the session.upload_progress option. PHP considers that it only affects applications configured in an unusual way and that the risk is unlikely. The situation changes fast: always check PHP’s official advisory before acting.

Are you affected?

If your site runs on WordPress, on an online shop or on a tool built in PHP, the answer is probably yes. Many shared hosting plans also run PHP, even when the site itself is not written in that language. Three questions to place yourself:

• Which PHP version runs at your host? It is usually shown in its management panel.
• Who applies the updates: your host, a contractor, or nobody?
• Is the version still maintained? Versions 8.1 and earlier are not, and PHP 8.2 will no longer receive security fixes after 31 December 2026, according to the official PHP schedule.

At Kayo, the websites we build run on Next.js by default, not on PHP. This particular flaw therefore does not affect them, except for a special project built on a PHP CMS. That does not make them invulnerable: the tools they use also publish security fixes, and those must be applied.

Why secure a website, an application or a SaaS

A flaw like this one is not an isolated case. It illustrates a trend.

• Unpatched flaws have become the main way in. According to the 2026 Verizon report, exploiting a vulnerability is behind 31% of the breaches analysed, ahead of stolen credentials.
• Belgium is not spared. The Centre for Cybersecurity Belgium received 588 incident reports from Belgian companies between 1 January and 28 September 2026, more than the 556 reported in all of 2025, according to ITdaily.
• Attacks are automated. Bots scan the web and test vulnerable versions, regardless of the size of the company.

The consequences of an intrusion are concrete: a site that is down, customer data exposed, a damaged image with your customers. If personal data is affected, the GDPR may require you to notify the data protection authority, in principle within 72 hours.

Applying a fix generally takes far less time than handling an incident. That is what makes prevention worthwhile.

Website, application, SaaS: same reflexes, different risks

• A showcase website: hosting, CMS and extension updates, contact forms, the HTTPS certificate.
• An application or business tool: accounts, everyone’s access rights and the data that flows through it.
• A SaaS: everything above, plus the isolation of data between your customers, access keys to third-party services and backups.

The more data a tool holds, the higher the bar. That is why we adapt the protections to the project, instead of applying the same setting everywhere.

What we put in place at Kayo

Before every go-live, we go through a security checklist point by point and fix any open points before delivery. Depending on the nature of the project, it checks in particular:

Once the site is live, security needs follow-up. That is the role of website maintenance: updates, backups and monitoring. In our packs, security, technical updates, backups and monitoring are never deducted from the month’s small changes. We detail what a contract should cover in our article on the maintenance contract.

Was your site built elsewhere? We start with an entry audit at €125: hosting, code, dependencies, security, backups and bugs already present. If fixes are needed before we take over, they are quoted separately. If the site is too old to be updated properly, the question becomes one of a redesign: see redo your site or update it.

For a mobile app or a custom SaaS, the same logic applies, with a framing of what must be protected on top: who accesses what, where the data is hosted. As soon as we process personal data on your behalf, a data processing agreement (DPA) is attached to the quote and signed separately. For automations between your tools, data hosting is agreed in the quote according to how sensitive the data is.

No checklist guarantees absolute protection, and our Digital Audit does not cover security in depth. For a thorough check, our security audit at €999 covers only that subject. This work rules out common mistakes and keeps the site up to date: that already makes the difference against automated attacks.

What to do this week

• Find out who hosts your site and which PHP version it uses.
• Ask your host or contractor whether the fix is applied, and whether the services were restarted afterwards.
• If your version cannot be updated right away, the authorities advise taking it off the Internet in the meantime. A web application firewall can help, but only protects partially. Then plan the migration.
• Check that your backups exist outside the server and that they restore.
• Turn on two-factor authentication on admin access, and remove extensions and accounts that are no longer used.

If you do not know where to start, book a 20-minute call: the pre-audit is free, a first spoken look. Together we see what to start with.