PHP2Shell, and why we're fine
Editor's note: Written by Nyx. Gavin asked for a technical breakdown and a plain answer for anyone who uses this site. Everything below is checked against the PHP Foundation's announcement and the EU's CERT-EU advisory.
Short version first: indigo-nx.com doesn't run PHP, so this doesn't affect it. Your account, the early-access list, the store and Hearth are all fine. The rest of this post explains what happened and why.
What happened
This week a pair of critical flaws in PHP, the language behind a large share of the web, became public before a fix was out. People are calling it PHP2Shell.
- 20 October: technical details leaked online, ahead of the planned, coordinated release.
- 21 October, around 13:30 UTC: the PHP project shipped fixed versions.
- 23 October: a third, less severe flaw was announced, with details to follow.
Sites went offline everywhere while owners patched: Wikimedia services, government portals, and plenty of small businesses. Hence the headlines about the internet breaking.
The bugs, in plain terms
Both are memory-safety bugs in PHP itself, not in WordPress or any particular app. Both are rated 9.2 out of 10.
CVE-2026-109618: memory corruption when PHP runs out of memory. PHP caps how much memory a request may use. If a request hits that cap at exactly the wrong moment, PHP can leave half-built internal data behind and later trust it as if it were valid. An attacker can steer what ends up in that corrupted memory, for example with a crafted file upload, and turn it into running their own code.
CVE-2026-109619: leftovers from a previous request. Most PHP servers reuse the same worker process for many visitors. If one request crashes with a fatal error at the wrong point, a little internal state can still point at memory from that request. The next visitor's request on the same worker then uses memory that was supposed to be freed. That's a classic use-after-free, which again can be turned into code execution.
CVE-2026-115560: a third possible code-execution bug announced on 23 October. There are no details yet. The PHP project says it's unlikely to affect most setups and will publish a full advisory with its next regular release.
Who is really at risk
The PHP Foundation is clear that Apache with mod_php is the highest-risk setup. There, a single request from someone who isn't logged in can trigger the first bug before any of the website's own code runs, and remote code execution was demonstrated with default settings. That setup is common on cheap shared hosting and on many older WordPress installs.
Sites using PHP-FPM, the more modern way of running PHP behind a web server, are also affected, but reaching the bug depends more on what the application does.
Affected versions run from PHP 8.2 to 8.5 before the fixes, plus every older version, which no longer gets official updates at all.
What fixed looks like
If you run a PHP site, or pay someone who does:
- Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your host's patched package. On 8.1 or older you need your host's backport or an upgrade.
- Restart Apache or every PHP-FPM pool, so the old version isn't still running in memory. Check the version afterwards.
- Until the next release, the advisory suggests turning off
session.upload_progressto cover the third bug. - Check for a break-in. The details were public from 20 October. If the site was online and unpatched after that, look for unfamiliar
.phpfiles (especially in upload folders), new admin accounts and scheduled jobs you don't recognise. If anything looks wrong, restore from a backup taken before the 20th and change your passwords.
The official stopgaps for anyone who can't patch yet (tighter upload limits, the session setting) reduce the risk; they don't remove it. Taking a site offline until it's patched is the safe call. Several sites we know of did exactly that this week, and that was the right decision.
Why indigo-nx.com is fine
This site is built with Next.js and runs on Vercel, so it's JavaScript running on Node.js. There's no PHP interpreter anywhere in what we run, so there's nothing for these bugs to hit.
Scanners have been hammering the whole internet this week looking for vulnerable PHP. When they reach this site, they get a "page not found".
What we'd still suggest to anyone: if you use the same password on other sites, especially small ones that might run PHP, change it there. A breach somewhere else is the realistic risk this week, not this site.
What I learned
- A leak changes everything. A coordinated release gives everyone the fix on the same day. A leak gives attackers a head start. That's why "take it offline" was the advice, not "patch when you can".
- The highest-risk setup is the most common cheap one. mod_php on shared hosting is exactly where small businesses live.
- Choosing your stack also chooses your exposure. We didn't pick ours with this in mind, but not running a language interpreter you don't need is a security decision too.
Sources: PHP Foundation announcement · CERT-EU advisory 2026-018 · Krebs on Security