Your password is plain text for about a millisecond. Two new PHP bugs let a stranger read it.

PHP shipped an emergency security release today — 8.5.12, 8.4.27, 8.3.36 and 8.2.35  — for two bugs that let a complete stranger run their own code on a web server without signing in to anything at all. The plan was to announce on Thursday. Then the details showed up on Hacker News on Monday, the post was taken down, and the whole schedule moved up a day. An embargo is a gentleman’s agreement, and somebody wasn’t 🫥

The pair now goes by php2shell: CVE-2026-109618  and CVE-2026-109619 , both rated 9.2 out of 10 by PHP’s own security team. In PHP’s words, one of them lets request data get left half-built and then treated as if it were fine, and the other lets internal state outlive the memory it was using, so the next visitor’s request can pick up something the last one dropped. Two different ways of saying the same thing: PHP can be talked into using a thing that isn’t there any more, and that is the oldest way in the world to end up running somebody else’s code

PHP’s advisory is blunt about who this applies to: “all PHP installations serving web requests.” Not a plugin, not a theme, not a weird configuration you’d have to go looking for. PHP itself. It singles out mod_php as the worst case, with “a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs”

Hold on to that last bit. Before any application code runs. We’ll come back to it, and it’s the whole article

How many servers are we talking about

Nobody knows, and everyone has a guess. Silas Cutler put it at over 1.3 million potentially vulnerable hosts. A Shodan sweep by Henk Poley counted over 1.9 million PHP servers facing the internet at all. Phoenix Security reckons  around 884,000 of those are running PHP versions so old they were never getting a fix in the first place

The list of what’s built on PHP is where this stops being somebody else’s problem. WordPress is on it. So is a large slice of every forum, shop, booking page, parish newsletter and small-business login box you have ever typed a password into. This is not an enterprise appliance story where the worst case is somebody’s VPN concentrator. It’s the software behind the boring websites you actually have accounts with 🏚️

The part nobody puts on the security page

Here is what happens to your password when you press the button, in order

Your browser encrypts it in transit, so the café wifi learns nothing. It travels. It arrives at the web server. And at the moment it arrives, before anything clever has happened to it, your password is text. The real one. Every character, sitting in the memory of the program that just received it, because the site has to look at it to find out whether it’s right

Then the good stuff happens. The site hashes it, compares that against the hash it stored when you signed up, and throws the original away. Every reassuring phrase on every security page — salted, bcrypt, argon2id, “we never store your password in plain text” — is true, and every single one of them is a statement about what happens after arrival

php2shell is about arrival. It puts a stranger’s code inside the program that handles the moment your password is still readable, and PHP says the demonstrated attack lands “before any application code runs.” Before. The site’s careful, expensive, genuinely-good-practice hashing sits downstream of the intruder, which is an unfortunate place to keep your security 🙃

Nothing about that needs clever cryptography to undo. There’s nothing to crack, nothing to brute-force, no rainbow table, no GPU rig humming in a basement. Code running in that process is simply in a position to read what comes in next, the way it was typed. Whether any particular attacker bothered to is a separate question nobody can answer for you — but it is not a hard thing to want

And notice what this does to the usual division of blame. You didn’t get phished. You didn’t install anything. Your laptop is fine, your browser is fine, your two-factor is fine and would have done its job perfectly. The break-in happened in a building you have never been to, to software you have never heard of, and the only thing you did was log in to a website on a Wednesday. This was all meant to happen on Thursday, but somebody couldn’t keep a secret 🗓️

Is anyone actually using it?

This is where the security industry gets to be itself for a day. Hadrian says it is seeing php2shell exploited in the wild at scale . Cloudflare’s CTO Dane Knecht said “we are seeing early attacks emerging”, and the company pushed out firewall rules as a stopgap. Against that: watchTowr, which reproduced one of the two bugs, reported no exploitation in the wild  as of 11:26 UTC. Huntress said the same about its own customers  at 10am Eastern. The Netherlands’ national cyber-security centre said it hadn’t seen the flaw abused. SOCRadar  notes PHP hasn’t reported in-the-wild exploitation either, and neither CVE is in CISA’s exploited-vulnerabilities catalogue

So: one firm says it’s happening at scale, several say not yet, nobody has confirmed an actual break-in, and the official scoreboard says nothing. Pick the vendor whose dashboard you already pay for 🙄 The honest summary is that a working exploit exists, a video of one has been going round credited to a researcher called LCFR, and the gap between “exists” and “everywhere” has historically been measured in days rather than months

You can tell how seriously people are taking it by what they did anyway. BambooHR pulled services offline as a precaution rather than in response to anything confirmed, which is either admirable caution or a very expensive afternoon, and possibly both 🧯

Which is not a hypothetical, because PHP has form here. CISA’s catalogue of vulnerabilities known to be exploited already lists three older PHP bugs, and two of them — CVE-2024-4577  and CVE-2019-11043  — are flagged as having been used in ransomware attacks. This family of bug does not stay theoretical

Credit where it’s due

PHP handled this well, which is not a sentence this Journal gets to write often. No chief trust officer, no crisis comms retainer, no carefully staged announcement at 5pm on a Friday. They gave a day’s advance notice so administrators could be ready. They published mitigations alongside the fix and were honest that the mitigations only narrow specific routes in and do not make you safe. They told people relying on one volunteer-run package repository to switch away from it, because it wouldn’t have the update in time. And they wrote patches for PHP 7.4, 8.0 and 8.1 — versions they stopped supporting long ago and owe nobody anything for

That is a better disclosure than several nine-figure vendors managed this year, from a project that mostly runs on people’s evenings 🫡

What you can actually do

If you run a website: update PHP. If it’s a managed host or cPanel, the version selector is where you want to be, and “we’re on 8.4” is not the same as being on 8.4.27. Distributions got the patches early, so your vendor’s package may already be waiting. PHP’s advisory lists configuration changes for people who genuinely cannot update today, and is clear that they reduce exposure to particular paths and nothing more. If your PHP is older than 8.2, this is the week that decision stops being free

If you just use websites: nothing. Genuinely nothing. There is no setting, no browser update and no amount of personal diligence that touches this one. Most security advice quietly assumes your own behaviour is the variable. Here it isn’t

What you can do is be smart about the aftermath:

• Don’t rush to change your password on a site you’re worried about. If a site is still unpatched and already has somebody camped in it, changing your password there means typing a brand new password into the same compromised server. You’ve achieved an update, for them 🤲
• Wait for the site to say it’s patched, then change it. Boring, correct, and in that order
• If you reused that password anywhere, change it on the other sites first. Those you can fix today, and they’re where the actual damage would land
• Sign out of everything, after the change. A signed-in session keeps working after a password change on plenty of sites, so use “sign out of all devices” if the site offers it
• Turn on two-factor anyway. It does nothing against this, since the attacker is inside the server rather than knocking on the login form. It does a lot against what people do with a password afterwards

Where a password manager helps, and where it doesn’t

Start with the honest part: nothing we make, and nothing anyone else makes, stops a web server being broken into. If a site you use is compromised at the moment you log in, the password you sent that site is a password somebody else may now have. No vault, local or otherwise, reaches into somebody else’s datacentre and fixes that. Anyone telling you different is selling something, and so are we, so here’s the bit that’s actually true

The only thing left to decide is how far it travels. A broken-into website learns one password: the one you used there. What that password is worth depends entirely on what else it opens. One password across your email, your bank and a forum you joined in 2014 turns one unlucky site into all of them. A different password per site turns the same break-in into one annoying afternoon

That’s the whole trick, and it’s unglamorous. Vauz  keeps your logins in a vault on your own computer, each site’s separately, and when a page asks for one it hands over only what was saved for that exact address — and only after you have approved that site yourself, with Touch ID or your V-Key, in a prompt from the Vauz app. Your vault isn’t on our servers, which in this particular story changes nothing at all — the password still arrives at the website in the ordinary way, because that is the only way logging in has ever worked. What it changes is the arithmetic afterwards: a site that gets popped learns what you used on that site, and your inbox doesn’t care

If you’ve been meaning to stop reusing that one good password you’ve had since university, this is a decent week for it. Not because php2shell is coming for you specifically. Because roughly 1.9 million servers just turned out to have been one bug away from reading your post, and the only part of that you were ever in charge of is how much a single one of them gets to learn 📬

What to watch

Whether in-the-wild exploitation gets confirmed by somebody without a product to sell, and how fast. Whether these two land in CISA’s exploited list, which is the moment the argument about honeypots ends. What happens to the 884,000-odd servers on versions nobody is patching, which will still be answering requests next year. And whether any of the sites you have an account with mention this at all — because “we take security seriously” is about to get a workout, and the ones that say nothing are not the ones that weren’t affected