PHP alert of 21 October: is this already a data breach under the GDPR?

Two vulnerabilities, almost every website

On 21 October 2026, the PHP project released out-of-band security updates. They close two vulnerabilities in the core of the programming language, tracked under the identifiers CVE-2026-109618 and CVE-2026-109619. Both allow an attacker to execute their own code on the web server without logging in, in the worst case with a single crafted request, before the actual web application even starts. Anyone who manages this can read data, alter files and establish a permanent foothold. The PHP security team rates both vulnerabilities as critical, at 9.2 out of 10 points.

The scale of the problem follows from how widespread PHP is. According to figures from W3Techs, PHP runs on a good 69 per cent of all websites whose server technology is known. This includes the common content management systems and many shop systems. Almost every company with its own website is therefore affected, even if nobody there knows that PHP is working in the background. The flaws sit in parts of the code that have existed for more than ten years; according to those who discovered them, every PHP version since 5.4 is affected by at least one of the two vulnerabilities.

The update is out, but not everywhere

Security researchers had reported the vulnerabilities to the PHP project in August 2026. Because initial details leaked on 20 October, the project brought the planned release forward by a day, to 21 October at 4 pm German time. Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 have been safe since then. For PHP 8.1 and older versions, the project no longer supplies ready-made updates, only source code fixes; some Linux distributions offer their own packages. According to W3Techs, more than a third of all PHP websites still run on PHP 7 or 5. For them, the only option is often to move to a newer version.

The situation is serious. A major provider of network services reported the first attempted attacks as early as the morning of 21 October. The Federal Office for Information Security advises installing the updates immediately, and the IT emergency response team of the EU institutions recommends disconnecting systems from the internet until the update has been installed. The interim settings circulating online do not make an installation safe, according to the PHP project.

A vulnerability is not a data breach

From a data protection perspective, one question comes first: does a company have to report the vulnerability to the supervisory authority? In most cases no, at least not because of the vulnerability alone. Under the General Data Protection Regulation (GDPR), a personal data breach means a breach of security that has led to personal data being destroyed, lost, altered, disclosed without authorisation or accessed without authorisation. What matters, then, is that something has happened to the data.

An open door is not yet a break-in. As long as nobody has exploited the vulnerability, there is a security incident but no data breach. The European Data Protection Board says so expressly in its guidelines on personal data breach notification: every data breach is a security incident, but not every security incident is a data breach. It even gives a fitting example. A hosting provider discovers a flaw that would allow any user to see other users' account data. If there is no indication that anyone has exploited the flaw, a notifiable breach has probably not occurred. The incident nevertheless belongs in the internal documentation, and it may amount to a breach of the duty to ensure appropriate security if the company does not close the gap promptly.

Check whether you are affected and close the gap

First, use your own IT, whether in-house or at your service provider, to check whether your systems are affected by the vulnerability and whether anyone has already exploited it. If you have a data protection officer, involve them in this check from the outset; the GDPR requires their early involvement in all data protection matters. Indicators can be found in the web server logs, unusual requests, unknown files in the web directory, new user accounts and messages from your hosting provider. Those who discovered the vulnerability warn that the attacks take place below the application level and leave few traces in the usual application logs. So involve your hosting provider, who has access to the server logs. An IT forensics specialist is only worthwhile for larger systems or where there is a concrete suspicion.

At the same time, you must close the gap immediately as a first response. If your website is run by a web hosting provider, ask them whether the new PHP version has been installed, and get this confirmed. If you run your own server, update it yourself or instruct your service provider. For this you need a list of all systems running PHP: website, shop, customer portal, intranet, test environments and extensions that come with PHP. 

Data breach identified, keep an eye on the deadline

If it turns out that someone has exploited the vulnerability, assess the situation together with your data protection officer. If you have not appointed one, now is the time to bring in a lawyer specialising in data protection law. Because with the access, a personal data breach has occurred, and the obligations under Articles 33 and 34 GDPR apply. You must in any event document such a breach internally: what happened, which data are affected, what the consequences may be and what you have done about it. You must also report a personal data breach to the data protection supervisory authority within 72 hours, unless a risk to the individuals concerned is unlikely. Where a high risk is likely, you must also notify those individuals. How high the risk is depends on the nature and volume of the data: contact details from a newsletter form carry less weight than payment data, health information, login credentials or job applications, and ten thousand customers weigh more heavily than ten. In any case, seek expert advice on the question of the notification duty.

The 72 hours run from the point at which you know with sufficient certainty that data are affected. The European Data Protection Board allows you a short investigation before the deadline starts, but requires you to begin it immediately. If you drag out the assessment, you risk the authority treating your notification as late. And if you decide against notifying, record that too: which systems you checked, when, by whom and with what result. This note shows that you responded appropriately to the vulnerability; if there has been a data breach, it also belongs in your register of personal data breaches.

The hosting provider reports, the company is liable

If you have your website run by a hosting provider, you have a processor in legal terms: the hosting provider processes the data on your behalf, and you remain the controller. If the hosting provider establishes that data have been leaked from its servers, it must inform you without undue delay. With that information you are deemed to have knowledge, and the 72-hour deadline mentioned above begins at the latest at that point. 

Reporting to the data protection supervisory authority remains your company's task, as does the decision whether to notify the individuals concerned. If no message from the hosting provider arrives, that does not release you from your obligations. So request specific information now: which PHP version is in use, since when has the update been installed, have there been any suspicious accesses? Add the answers to your documentation.