Excerpt: Critical PHP flaws were disclosed on 21 October 2026, and fixes exist. From that point, a controller running unpatched PHP cannot say the risk was unknown. Here is what Article 32 UK GDPR expects, and how fast.
Read time: 5 min
Tags: #UKGDPR, #Article32, #PHP, #PatchManagement, #DataSecurity
What happened
On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution (RCE), and both are scored 9.2 on the Common Vulnerability Scoring System (CVSS) v4.0 scale. PHP says all installations serving web requests are at risk.
Google Cloud reports that affected versions run from PHP 5.4 through 8.5.11.[2] Patchstack notes that WordPress, Drupal, Magento, Joomla and Laravel sites are exposed if they run a vulnerable PHP version. Details leaked on 20 October, before the coordinated disclosure.
The UK’s National Cyber Security Centre (NCSC) is encouraging UK organisations to take immediate action. Its alert tells them to identify PHP systems across their infrastructure, starting with internet-facing ones, and not to limit that search to outdated versions, because all versions may be affected. CERT-EU, the computer emergency response team for the EU institutions, said proofs of concept had begun to circulate, which raises the likelihood that attackers are already exploiting the flaws. Cloudflare’s CTO said the company was already seeing early attacks before the patches were released.
PHP states there is no complete mitigation and that updating is the only safe choice. PHP 8.1 and earlier no longer receive fixes from the project, although some vendors provide backports. PHP 8.2 reaches end of life on 31 December 2026.
Why this is a data protection problem
Article 32(1) UK GDPR requires controllers and processors, “taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons”, to “implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk”.
Appropriateness is not fixed at the point you built the system. It moves with the risk. Before 21 October, this flaw was not public. Now it is public, a fix exists, and exploit code is circulating. The likelihood of harm has gone up and the cost of the fix is low. In my view, leaving a known critical remote code execution (RCE) flaw unpatched on a system that processes personal data is very hard to defend as “appropriate”.
Article 32(1)(b) requires the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of your measures.The ICO adds that where testing reveals potential critical flaws, you should act on the findings or have a valid reason for not doing so, and document it.
The point is that speed of reaction is itself an organisational measure. A patching process that takes six weeks does not meet the risk presented by a flaw that attackers can use this week.
The ICO also says it must consider the technical and organisational measures you had in place when deciding on an administrative fine.
What a defensible response looks like
If you’re the DPO, start talking to your IT Team (support vendor) NOW.
- Find your PHP. List every system that runs it: your own sites, agency-managed sites, hosted applications and plugins. Record the version.
- Patch to a fixed release (if possible and prudent). For PHP 8.1 and earlier, get written confirmation from your vendor that a backport is in place, or upgrade.
- Treat workarounds as a stopgap. PHP lists configuration changes that reduce exposure to specific attack paths, but says they do not make an installation safe.[1]
- Check for compromise. If exploitation began before you patched, patching does not remove an attacker. Review logs and look for unexpected files and accounts.
- Write it down [ACCOUNTABILITY]. Record when you became aware, what you decided, who decided it and why. That record is your evidence of an appropriate process.
- Ask your processors. Article 32 applies to processors as well, and the ICO says your contract must require them to take the measures Article 32 requires. This is a real ‘hotspot’ for vulnerabilities. Ask your ‘vendor base’ where they stand today. Document your findings (save your emails).
If an attacker gets in
Article 33(1) requires notification of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals. Article 33(5) requires you to document every breach. If an attacker gains code execution on a server holding personal data, treat it as a personal data breach until you can show otherwise.
The takeaway
The law does not ask the Controller (or DPO) to predict the next flaw, it asks you to REACT to the known ones in a way that matches the risk. For this flaw, that means days, not weeks. ‘Tick tock’.