upvote
This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails they get.

If I had details on a RCE like this I'd report it but if I got no response for a WEEK I'd be trying other venues.

reply
I imagine more details will come out over the coming days, but it’s not uncommon for severity to be under-estimated in the beginning; and then “oh shit” as you dig deeper.

We don’t know when it went from a “memory safety issue” to “php2shell/RCE”.

Calif’s report is a little light on timelines, but reading between the lines, it seems they took a while to turn this into an actually exploitable vulnerability.

Finally, at least pre-LLM (and maybe a bit outdated now), responsible security disclosure norms is that you usually do wait for vendor (up to 90d) if there’s no signs of active exploitation. Even if it’s a RCE. Actually, especially if it’s a RCE.

The last thing you wanna do is go pinging random non-security PHP contributors or maintainers and have it leak with zero patch. That is truly the worst outcome.

Yes, this is bad, but also, it’s apparently been bad for decades; and it could’ve been much worse.

reply
According to this post, one of the researchers was a former PHP security lead who already knew about the bug since 2004. So I'd assume they would be taken as credible by the current team https://calif.io/php2shell/
reply
As I mention elsewhere (https://bugs.php.net/bug.php?id=78876) I'm very confused. Looking at the PHP bug tracker the specific bugs were fixed. So my best guess is that the LLM was able to find alternative variants that still worked? But then the report makes less sense.
reply
Assuming that it could have been spotted in their inbox, amongst a probable flooded of LLM slop like a number of security mailing lists for open source projects that I know of. We've all seen the impact on open source github issues, hackerone etc. The same is happening to standard email disclosure paths.
reply
These illustrations are neat but severely distracting given that each make a mountain out of a molehill.
reply
>This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails

i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.

reply
and they also have plenty of exposure to their motherships burning money on LLMs
reply
I've said elsewhere I am sick to death of reading AI written "security disclosures". Even for genuine issues, it just saps my motivation to fix them.

That said, PHP team handled this poorly. How does letting everyone know so they can "prepare" help anyone at all. It just creates panic.

reply
If you provide forewarning, system administrators around the world in various time zones can get ready to update at the same hour the fix is released, which is very important. Being hours late is not acceptable for a vulnerability like this.
reply
And yet it seems all their forewarning did was lead to the proof of concept being leaked many 'valuable' hours before.
reply
Are you victim blaming the reporter?

If you have a bad process, fix the process.

reply
Why does the PHP security team need to acknowledge it and develop the fix? It's open source software.
reply
If you want an orderly fast global rollout you need to have the maintenance team and distributors working together.
reply
So if Wiz produced their own patch to PHP, and Calif produced their own (slightly different) patch, and OpenAI produced their own, which version should I use, as a user of PHP? Should I manually merge them? Is Calif's better than Wiz's? Is OpenAI's better than Calif's? Are they complementary?
reply
That does happen with downversion software. Red Hat may distribute a backported patch to some component which isn't the same as Canonical or Debian's.

Most users, who don't know the answer to your questions, rely on the distro to figure this out (and often pay good money for it).

reply
They already were in communication with each other. They could have come together and decided on one that mitigates the issues they've found.
reply
So anybody can just push out a new release of PHP?
reply
Yes, someone could have published a safe version for people to use for the 2 months to get the actual fix done.
reply
>Yes, someone could have published a safe version

this is basically the same as releasing a working exploit.

reply
And that's not a bad thing. If it was, the the logical conclusion would be to never publish the fix and don't preemptively patch before active exploitation.
reply
Yes it is.

Say I release a fix. I'm some rando but I go out to the world and say I fixed an issue with php. Use my version instead! Not telling you what I fixed, it's a secret, just trust me.

It will take, with LLM help, attackers a couple hours, tops, to reverse engineer my fix into active exploitation. Meanwhile, I'm some rando so no one's even heard of me, people who do hear don't automatically trust me to install my fix, so very few people have my fix. Meanwhile, the exploit is out there thanks to me and people are getting their sites hacked thanks to me.

That seems like a problem, no?

reply
How is what you are describing any different than what happened today? Except the vulnerabilities were also explained. You can say that sites are getting hacked right now due to them releasing the security update.

>I'm some rando so no one's even heard of me

Why do think people need to have heard of you. If you are reporting this issue directly to distro maintainers, security companies, hosting companies, etc first you can help use their names as part of the marketing push to raise awareness.

reply
> How is what you are describing any different than what happened today?

There was an official patch within a few hours. It probably would have been a lot longer.

And that was the screwup case. If today had gone correctly the official patch would have been out by the time the bug was public.

reply
And in the situation where they released a security patch 2 months ago, there would be a security patch before the bug was public.
reply
2 months ago there was no patch and no possibility of a very quick patch. Releasing details then would have been very bad.

If you mean they should have released the patch as soon as it was done, it's true that it would have been before the bug was public... for about five minutes. When a warning a day or two before patch release works, it lets admins prepare to patch immediately and/or shut down their servers before the release time.

Even with the leak, admins still had warning and it was better than an unwarned official patch drop. Which itself is better than an unwarned unofficial patch drop. Which itself is better than an unwarned drop of exploit details.

reply
Sort of by definition of open-source, yes. It's just that nobody downstream is likely to accept Joe Public's random fork of PHP.
reply
You're confusing PHP the product with PHP the codebase. The former is what is the only relevant part in the security world, where a product is synonymous with its vendor (even FOSS).
reply
I mean, it's all semantics at the end of the day.

The PHP maintainers have generated a certain amount of goodwill over their long service, which leads downstream consumers to trust their releases over every other packaging of "PHP the open source codebase".

Nonetheless, there are countless forks of that codebase, and there are other releases than the ones made by the PHP maintainers. Any particular downstream could switch to another source of releases if presented with a compelling enough reason.

reply
Did start writing software this week?
reply
Because...that's what the PHP security team does?

No one needs to use their work, or indeed PHP at all.

But that's why the PHP security team exists.

reply
What's the other choice? OpenAI et al could have developed a patch (for all we know they did) but you need the PHP team's participation to get it out. The alternative would be to fork the project and put up a forked release with the fix, which would have been incredibly disruptive.
reply
I'm glad they didn't do anything disruptive, then. Like wind the world's CIOs up into a frenzy of FUD and bring thousands of servers down in a coordinated panic attack synchronised to the minute.

Imagine if they had just patched the code and rolled it out with an advisory?! Oh my GOD! Won't someone think of Sam Altman and his huge pile of debt?!

reply
Pre AI, silently publishing a fix to a security vulnerability was considered bad practice.

Post AI, Its efficiency pre announcing the exploit to bad actors until the official disclosure.

You can just watch the diff log of every open source project with a small local model, and look for anything that touches buffers, function pointers, or shell integration.

It could be an hour between release of a fix before the exploit starts attacking servers.

Guess what also could happen within an hour? A coordinated Internet wide panic that shuts down all vulnerable servers.

---

We actually have a recent example. OpenAI hack.

An undisclosed vulnerability fix to a image formal lib; packages into debian 12 running in a docker, used by imagemagic, used by discourse running OpenAIs user forum.

reply
What would you have a security team for then?
reply
deleted
reply
To handle the official solution and drive long term changes to reduce similar security bugs from happening again. The current PHP security team does not seem capable to promptly release a fix, so having a community fix first seems preferable.

Mitigating a bug and developing a proper solution that is maintainable long term and supports future changes being made to the software take different amounts of time to develop.

reply