What is the PHP hack and who is at risk? — Part 2

If you run a website on PHP, the PHP hack is the thing to check today: a critical flaw that lets an unauthenticated attacker execute code on your server. A patch exists, and the UK's National Cyber Security Centre advised suspending services where patching could not be completed quickly.

Part 2 of a series, after What is the PHP vulnerability and who is at risk?.

What is the PHP hack?

The PHP hack is a critical vulnerability in PHP, the server-side scripting language that arranges page content and runs databases on a large share of the web, and it allows an unauthenticated attacker to execute arbitrary code on a vulnerable server. The flaw was always in the code; what changed was that researchers using artificial intelligence worked out how attackers could use it to reach a web server, and details leaked before many organisations had patched. The UK government took more than 30 services offline while it applied fixes, according to Channel 4 News, which broadcast the interview this article is based on on 22 October 2026.

The practical risk is severe because exploitation does not require a stolen password or a compromised account. A security researcher described the effect in plain terms during the programme: someone on the other side of the wire can execute code and commands on the server without authentication. That places the vulnerability in the remote code execution class, the category that concerns defenders most because it hands over the machine rather than one account.

How bad was the PHP hack, and what do the numbers show?

The PHP hack produced millions of exploitation attempts within hours, but no confirmed compromise of central government systems as of the interview, and no data breach reported by the UK National Cyber Security Centre. Chris for scale: PHP underpins about 70% of the world's websites, according to the researcher quoted in the programme, and Cloudflare said it observed millions of exploitation attempts in a matter of hours.

Two different signals sat side by side. Exploitation attempts and scanning were reported internationally, which shows attackers knew about the flaw quickly. Confirmed successful breaches were not, which the researchers attributed to the complexity of the exploit and to rapid patching and service suspension. The gap between attempts and confirmed compromise is the part that matters for anyone deciding how alarmed to be.

Why the leak and the AI discovery changed the timeline

The PHP hack became urgent because coordinated disclosure leaked: the existence of an upcoming vulnerability reached a wider circle before many organisations had patched, shrinking the defenders' window. In a normal coordinated disclosure, vendors and distributions get the patch ahead of the public announcement. As more people are brought into that circle, word spreads, and in this case what leaked was the existence of the vulnerability rather than its technical detail.

Artificial intelligence sat on both sides of the event. Researchers used it to find the flaw, and the same capability lowers the skill needed to exploit one. A researcher on the programme said exploitation is complex and advanced, and that large language models reduce that difficulty considerably. Charlotte Wilson, head of enterprise and strategic sales for the UK and Ireland at Check Point Software Technologies, described her own conclusion the same way: AI is useful to defenders and to attackers.

One distinction from the programme is worth keeping. Taking services offline was proactive disruption, done before an attack, not a response to one.

Which systems were exposed by the PHP hack?

The PHP hack exposed government and council websites, cloud infrastructure and any forgotten PHP instance, including old versions in places the owners may have overlooked. The researcher called it the largest vulnerability in recent memory because PHP appears in so many places, and the UK's public sector carries a specific burden: many services run on older, interconnected systems where a vulnerable component can sit inside a supplier's software rather than in the department's own code.

The UK National Cyber Security Centre advised organisations that could not patch every vulnerable instance quickly to suspend services for a period instead. Wilson said she could not remember a time when that advice would have been given, which is a marker of how the response was handled rather than a measure of confirmed damage.

How to respond to the PHP hack: a practical checklist

Site owners should assume nothing about old PHP instances and inventory them all, then patch, and suspend anything that cannot be patched in time. The actions below follow the advice given during the incident and the disclosure sequence the researcher described.

Who owns what: the flaw, the discovery, and the response

The PHP hack is a vulnerability in the open-source PHP language, not a flaw in a vendor product, and the security response came from the researchers who found it, the distribution and vendor maintainers who prepared patches, and national bodies such as the UK National Cyber Security Centre. Those roles are separate and they are easy to blur in the retelling.

Cloudflare's figure of millions of attempts describes what one network observed, not an industry-wide count of successful attacks. The absence of confirmed central government compromise describes what the UK authorities knew at the time of the broadcast on 22 October 2026, not a guarantee that nothing happened elsewhere. Treat both as dated evidence.

FAQ

• Was anyone actually hacked by the PHP hack? At the time of the Channel 4 News broadcast on 22 October 2026, the UK National Cyber Security Centre had not reported a data breach and no confirmed compromise of central government systems had been identified. Cloudflare reported millions of exploitation attempts, so attempts and confirmed breaches should be read as different things.

• Why did the UK government take services offline? The National Cyber Security Centre advised that where a patch could not be applied across every vulnerable instance in time, suspending a service was safer than leaving it exposed. The government removed more than 30 services while it applied fixes.

• Did AI cause the PHP hack? Artificial intelligence found the flaw and lowered the skill needed to exploit it, but the weakness itself was always in the code. Researchers used AI to identify how attackers could use it, and large language models reduce the difficulty of building an exploit.

• What should I do if I run a PHP website? Find every PHP instance you run, including old versions on forgotten hosts, apply the available fix, and take a service offline if patching cannot be completed quickly. Check dependencies supplied by third parties, since a vulnerable component can sit in a supplier's software.

• Does the PHP hack mean I should stop giving websites my data? The programme's guest advice was to give companies less personal data than they ask for, because a breach makes exposed data permanent. Buying something rarely requires your date of birth, and reducing what you hand over reduces what can leak.

Source video