Today's PHP security release, and how we're strengthening security

I absolutely loved being here today.

So many brilliant minds screaming and hating together, trying to survive the tide.

There aren’t many places like this left on the commercial internet, especially in this brave new AI-driven world.

I felt a great disturbance in the Force. But in a good way.

Together, we are strong. May the Force be with us all!

Is it so bad? Have you measured the number of attacks?

> So without the HN discussion I wouldn't have found enough people pointing at possible mitigations and I would have lost a server to this

I run a tiny server. I like this server a lot. I only patched an hour after the Debian package was ready and didn't think about it again. Do you mean to imply there's a real chance my little server has been compromised?

[Edit:] My server is quite public too. It hosts four SLDs and many subdomains and receives both human and bot traffic. Only one or two subdomains use PHP, but a reasonable attacker surely tries all of them.

I finished moving the remainder of my stuff off of PHP and WordPress last year and haven't missed it at all. Backwards compatibility was typically pretty bad.

It seemed like maintaining existing working PHP code was always a cycle of: upgrade to newer PHP, that version has breaking changes, fix that code or update to a new WordPress (plus all of the plugins that would inevitably need updating too).

Just saying "hey blocking multipart uploads can mitigate most of attacks early would save people so much trouble. Of course not every CVE will have workaround but many do and whole secrecy about releasing it is only to benefit of few big tech companies and nobody else

The simple version: Alibaba/Express and Amazon buys or kills most online competition etc, the remaining behemoths split the different markets and manage all the delivery. Only them know your personal info and every smaller shops need to go through them. Kinda the same way most of the world need to get with Apple/Google for things happening on mobile phone.

That situation could be completed in 5 years I wouldn't be surprised.

The crazy alternative: we all cooperate to have a common protocol to handle personal info, banks and shipment companies all agree to have standardized public APIs that are robust enough to last and be used more than six months. I don't think my grand children would see that happen.

You can register to reroute address A to address B, give out the address A to e-shops and then the post will deliver the packages to address B, which stays private. The catch is that address A needs to also be yours, it cannot be something arbitrary.

At least AFAIK.

This is the primary economic model of the internet, unfortunately, and thus the reason for all the data collection you described.

One of the biggest metrics businesses track is repeat purchases. They don't want to give up that info because it tells them if their product is good enough to retain customers.

So the token must have some means of connecting purchases for a user across time (at least per merchant) or businesses will never adopt.

So everything developed in an ad-hoc manner. E-commerce web sites just asked for the information they need (and the information they didn't need), those who were comfortable using those websites used them, and the paranoid probably held out for much longer (and rejecting the idea of centralized auth loudly).

Most attempts by private companies to establish some de-facto identity/auth/login service mostly failed (well, the couple Big Tech companies got somewhat close, but none of them got close enough to be able to get other sites to use them exclusively)

Besides, even if there was some protocol to handle the payments and shipping without sending the info to the seller, you'd have to trust the payment processors and the postoffice to be secure. It's basically a choice between whether you want to put all your eggs in one big basket or spread them around somewhat.

This is all new and rapidly evolving technology but giving apps / agents / others just the information they need to know while having a credibly neutral, private, and trustless database mediating is a true cypherpunk vision of how the internet should work and it's being built by people with the right ethos and principles to be as reliable, well engineered, and long lasting as the internet itself.

This reads like some guy tripped and fell on top of his mouse and in so doing, accidentally turned on screen recording, performed the exploit a few times, got the anime girl asset and soundtrack, dropped all of them into Premiere, added the weird effects, rendered the video, and published the video to Twitter. "Ow. What did I fall on? Oh noooo, I broke the embargo!"

Heck of a mistake.

Finding an exploit and publishing is is not against the law. In some cases, publishing immediately is the responsible thing to do. For example, when it's actively being exploited in the wild, and waiting just puts people at risk that don't have any recourse to protect themselves, since they don't know they're at risk. There can be nuance to that as well, but in general, as soon as it's being exploited, anything that makes it harder for end users to a) know there is an exploit, or b) tell if they're susceptible to it (e.g. through a POC) is just taking away people's ability to take the action they deem appropriate.

Not entirely correct as they clearly announced that they were going to release a fix at a specific date and time; the mitigation doing the rounds was not adequate and if the PHP people republished it, it would lull people into a false sense of security. Overcommunication is also bad, especially if the official platform or the individual members are being watched by tens of thousands of people hungry for news or updates.

They knew (since august, arguably since 2024), they had a fix ready, everything was in place. Except for the untimely / accidental early leaks.

Everyone in such a ragtag team would have an overlapping day job where the same crisis management needs to happen.

I have a lot of sympathy for php team - it would be a lot of work to respond to every conspiracy theory on twitter, while trying to get everything ready, in the middle of the night no less.

When a corporation sponsors the language, such as Java, Go, .Net, there's an inherent economic component which acts as a forcing function.

PHP being a foundation sounds nice. But consensus wasn't strong enough to affect the key outcomes.

Several attributes make a safer ecosystem. An important one is diversity - technical diversity.

For an interpreted language, the runtime is important. Python has several runtimes, as does Ruby. Javascript also has several, from the few browsers, to node, deno and bun. PHP has for all practical purposes, only one. So if there's a security incident in PHP, it affects almost all users. But when e.g. JRuby has a vulnerability, it will affect only a fraction of the installed ruby applications.

For compiled languages, the tooling, libraries and runtimes is where diversity is important. With e.g. rust, the vast majority of CVEs come from libraries (crates). But since there often are several crates for a single concept, diversity helps mitigate here too.

In their place I would worry that this was the last time anyone shared an embargoed build with them.

Embargos make sense if no one is exploiting it yet, but if its out in the wild, the best path forward is releaseing as soon as possible.

so, if they saw evidence of exploits in the wild, it is not unusual at all to release the fix.

Because if there are already publicly available exploits seen, it makes no more sense to keep holding patches back just so that OpenAI etc. can get a nice press release

[1] https://news.ycombinator.com/item?id=50176735

But it's also possible, that some attackers got non-public inside information.

If the embargo is already broken in a meaningful way, it suddenly becomes much less clear if it is still in place after all. Emphasis on >less clear<.

For my rust applications, I use "cargo audit" which checks all dependencies against the CVEs. For my typescript and javascript applications, deno audit and/or yarn npm audit.

For the rest of the stack `debsecan` does exactly what you want on Ubuntu: report CVEs for installed software.

I'm not overly keen on the tooling: as far as I can tell the whole industry is prone to flagging false positives as "vulnerabilities" rather than "potential vulnerabilities" and it's a bit too easy to turn those reports into a tick-box "you must update now because the tool says so". But they also do flag true vulnerabilities. And they pay for teams of security researchers to find and fix issues, not least because that's good marketing.

Some have free licenses, many don't.

Maybe it would be worth it to have an agent that knows your stack, reads the top threads on hn all day long and messages you when it thinks there is something serious going on that could impact you.

PHP2SHELL, in particular, made me expand my weekly security review to include my external network resources.

The natural conclusion for this seems to be realtime monitoring CVE and pre-CVE vulnerability indications in exposed stacks.

I hope that someone has some sort of a reasonable approach here / I would love to help work on something open source if not

Examples of the type of alternate questions to ask in 2026 may include:

- Does my software/system have a robust architecture where a failure of one component (e.g. RCE in a PHP process) has a minor impact, rather than a catastrophic impact? For example, a minor impact might be just the opportunity for an attacker to chain a PHP RCE with kernel LPE for some common syscall, rather than mass loss of every user's data to the attacker. I raised some PHP web application specific ideas in another thread at [1] but the answer to this question is product-agnostic and should consider microservices architecture vs. monolithic web application with access to everything, and use case/requirements development that considers matters such as users wanting to isolate their own access. For example, allowing bank users read only login for bank accounts vs. separate login for making transfers. Or implementing business process changes such as delayed commit for sensitive user actions--e.g. force delay a bank transfer by 24h and notify the user via various means giving them a chance to undo the transfer before they no longer can.

- How can I keep up-to-date with the latest software/system security architecture trends? What is the equivalent of [2] for learning about architecture patterns to potentially use for a simple eCommerce site, HR/finance web application, etc in 2026? For components of a web application such as interpreter, database server, etc--what options exist for each and how good is the project's choice of software languages, dependencies, etc to offer the strongest security protections in 2026? When was the last time I checked if someone had written an interpreter for PHP, Python, etc in Rust, SPARK, or whatever, or written an interpreter with much more comprehensive unit testing included?

- How quickly can my users or I detect security incidents / deviations of system behaviour from typical state? For example, [3] was discussed on HN today as once such detection mechanism where canary tokens are deliberately littered throughout a system or dataset. The security incident may have already happened, but early detection forces an attacker to burn their vulnerability chain quickly on their most highly prized target and not be able to use it against a mass of targets over a long duration of time.

[1] https://news.ycombinator.com/item?id=50184239

[2] https://aosabook.org/en/index.html

[3] https://news.ycombinator.com/item?id=50185630

You have your source code public, so you can't commit/push because then you've leaked info.

Your build pipeline is also likely public, so you can't just build from another source code... source.

You can create a private repo, but now you also need to build a private build system.

You don't get the same generous build resources for private repos, so you either:

a) simplify the build to just the essentials

b) pay

Unless you have significant funding, you'll probably go for a).

Now you have to maintain two systems, also with some differences between them.

Plus you need a way to get the build artifacts from the private system to the public one, typically at a fixed point in time.

Any failure/delay (e.g. less powerful build on private repo, errors because you exercise it rarely) causes people to get upset that you didn't respect the announced time.

Maybe you're also using things like image attestation, another can of worms.

Being given advance notice of an upcoming security fix is an immense privilege, organisations should turn around quickly when given such information, they shouldn’t be given more than a couple of days to update IMHO, it’s not like the rest of the world can wait.

For all the long-tail users, PHP is a distro package. That route needed the most work instead, and it got it.

Last time I checked, PHP was pretty solid programming language. Nothing wrong with heart singing.

PHP was great for learning the basics of web development 25 years ago. The world has moved on a lot since then.

Because now a vulnerability in PHP affects practically 100% of the users. But with more diversity, it would affect only a part. And if one runtime proves insecure more often than another one, organizations have a choice to move to an interpreter that better fits their security needs.

I'm really not sure how you mitigate this issue, other than serving static HTML and reducing the attack surface to cut out dependencies like PHP.

Maybe your calculus could hold if Chainguard's registry were the primary distribution mechanism for PHP in use worldwide (such that the benefit of an updated image would at least be widespread compared to the sitting ducks relying on the other repositories), but it isn't.