Oncord Blog. Posted January 1st, 1970

On Tuesday 20 October 2026, the PHP project gave the world a day's notice that something serious was coming. On Wednesday afternoon (UTC) it shipped the fix. By then, government portals in Europe had already gone dark on purpose, Cloudflare was rewriting firewall rules, and every hosting company on the planet was racing the clock.

Oncord customers didn't need to do anything. Every Oncord website is now running on PHP 8.5.12, the patched release, and even before the patch landed, the way we run your site meant an attacker who got in would have found very little to do. Here's the story, in plain English.

What happened

PHP is the language that powers a very large share of the web, including WordPress, Drupal, Magento and Oncord. On 21 October 2026 the PHP security team published an advisory for two critical bugs, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "PHP2Shell". Both are rated 9.2 out of 10 on the industry's CVSS severity scale.

The short version: a single web request, sent by anyone, with no login, could trick a PHP server into running the attacker's own code before your website's code even starts. The PHP team's own words were blunt: "There are no complete mitigations, updating is the only safe choice."

What made this one unusual was the timing. The details leaked onto Hacker News and social media on 20 October, before the fix was ready. The PHP team brought the release forward to 14:00 UTC on 21 October and warned it might go even earlier if attacks appeared. That left a window of roughly a day where the problem was public and the fix was not.

Sites that switched themselves off

When the fix doesn't exist yet, the only guaranteed defence is to unplug. A lot of organisations did exactly that.

• Techzine reported that the Dutch government took MijnOverheid, DigiD (the national digital ID login) and the House of Representatives website offline ahead of the patch, along with universities, Magento-based online stores and public forums running phpBB and vBulletin.
• CERT-EU, the European Union's cyber security agency, told organisations that couldn't patch immediately to consider taking affected sites offline. The UK's NCSC and Australia's ACSC issued the same guidance.
• Help Net Security noted that Cloudflare and Akamai were already seeing automated scans for vulnerable servers worldwide before the patch was out, and that Cloudflare pushed emergency firewall rules to every customer.
• Tenable summed up the advice from PHP's own release manager: configuration tweaks won't save you. Only the update does.

Taking a site offline is a painful call. It means lost sales, lost bookings and lost trust. Those organisations made it because the alternative was worse.

What we did

Oncord builds its own PHP from source rather than waiting for a Linux distribution to package it. That's more work day to day, but it means we don't wait on anyone when it matters.

1. Tuesday: we saw the advance notice and prepared a new build of our PHP runtime so it was ready to go the moment the source was published.
2. Wednesday, 14:00 UTC: PHP 8.5.12 was released. We pulled the source, re-applied our own hardening changes to it (more on those below), and built the new image.
3. Rollout: the patched runtime was rolled across our hosting fleet. Websites were not taken offline at any point.

If you run an Oncord website, you are on PHP 8.5.12 right now. There is nothing you need to do.

Why we weren't losing sleep: how Oncord sandboxes your site

A "remote code execution" bug sounds, and is, as bad as it gets. But how bad it is in practice depends entirely on what the attacker can do once their code is running.

On a typical shared host, the answer is "quite a lot": read other customers' files, open a shell, install a crypto miner, phone home. Oncord is built so that the answer is "not much".

Every website gets its own locked room

Each Oncord customer's site runs as its own user, inside its own container built with a tool called bubblewrap. Think of it as a locked room with one-way glass. From inside, the site can see its own files and the PHP runtime it needs to run. It cannot see other customers' sites, it cannot see the real server, and it cannot see the list of other users on the machine.

A shell gets you nowhere

The usual goal of an attacker with code execution is to "pop a shell": get a command prompt and start exploring. On Oncord they can technically get one. What they can't do is anything useful with it. The shell runs as that one site's user, inside the same locked room, with the same one-way glass: its own files, a read-only copy of the system, and nobody else's data.

Every tenant's PHP process also starts with a seccomp filter, a kernel-level allow-list of the exact system calls PHP legitimately needs. The calls you'd use to change identity, mount filesystems, attach to other processes or poke at the kernel aren't on the list, so the usual tricks for climbing out of a sandbox fail before they start. We built that list of kernel calls ourselves, specific to only what Oncord needs at a bare-minimum to operate. Smaller list, smaller target.

Code can't be read, only run

We've further patched PHP's own file handling so that framework source files can be executed but not read back out as data. A tenant that tries to read another site's code gets "Permission denied". The same guard blocks reads from system directories like /etc and /proc, which are the first places an attacker looks for clues about the machine they've landed on.

Resource limits per site

Each site has its own CPU, memory and process-count budget enforced by the kernel. A compromised site can't starve its neighbours, and it can't fork itself into thousands of processes to try to break out.

Defence in depth

None of these layers is magic on its own. The point is that an attacker has to beat all of them, in order, and each one takes away the tools they'd need for the next. This is the difference between "an attacker ran code on a web server" and "an attacker ran code inside an empty room and then couldn't leave".

To be clear: sandboxing is not a substitute for patching, which is why we patched within hours. It's what lets us patch calmly instead of pulling the plug.

What you should do

If your website is on Oncord, nothing. You're already updated.

If you also run other PHP-based systems elsewhere (a WordPress blog on a separate host, a Magento store, an internal tool), check with that provider today. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything on PHP 8.1 or older is no longer supported by the PHP project and should be upgraded.

You can read further information on Oncord's security at:
https://www.oncord.com/features/security/

Further reading

• PHP security advisory: Critical remote code execution vulnerabilities
• PHP 8.5.12 release announcement
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Techzine: Serious vulnerabilities in PHP, emergency patches on the way
• RTE: EU cybersecurity agency in warning on PHP vulnerabilities
• Help Net Security: PHP2Shell, critical PHP vulnerabilities patched
• Tenable: PHP2Shell FAQ