PHP 8.2.35

921 points by tuyuri 8 hours ago

Related ongoing thread: Today's PHP security release, and how we're strengthening security - https://news.ycombinator.com/item?id=50182987

nr378 - 8 hours ago

Looks like a co-ordinated disclosure between Wiz, Calif and OpenAI:

https://www.php2shell.com/

https://www.wiz.io/blog/php2shell-php-rce

https://calif.io/php2shell/

https://openai.com/index/coordinated-disclosure-of-critical-... (not yet live)

https://thephp.foundation/blog/2026/10/21/todays-php-securit... (not yet live)

esquire_900 - 7 hours ago

I feel like all "non-inner-circle people" here are taken for a laugh. OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix, and then leave the rest out to dry while they failed to properly contain it.
The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details. Specifically once the POC came online. Would have been significantly more useful than these polished blogs.
Perhaps I'm missing something here, but the costs (dev/sre time, missed sales, potential data leaks and hacks) of the way that this was handled is significant.
[1] https://github.com/php/php-src/security/advisories/GHSA-6wmf...
- john_strinlai - 7 hours ago
  
  >OpenAI and these security companies sat on this for 2 months
  these security companies reported it 2 months ago. it took a month for the php security team to acknowledge it and another month for the php team to develop & release the patch.
  if you're going to be upset at anyone it should not be the reporters.
  >The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details.
  publishing the fix = publishing the security details.
  - bombcar - 7 hours ago
    
    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.
    
    dannyw - 7 hours ago
    
    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.
    
    Maxious - 7 hours ago
    
    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/
    
    dwohnitmok - 6 hours ago
    
    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.
    
    Twirrim - 6 hours ago
    
    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.
    
    soulofmischief - 4 hours ago
    
    These illustrations are neat but severely distracting given that each make a mountain out of a molehill.
    
    john_strinlai - 7 hours ago
    
    >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.
    
    fock - 7 hours ago
    
    and they also have plenty of exposure to their motherships burning money on LLMs
    
    ferngodfather - 4 hours ago
    
    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.
    
    letmevoteplease - 3 hours ago
    
    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.
    
    ferngodfather - 2 hours ago
    
    And yet it seems all their forewarning did was lead to the proof of concept being leaked many 'valuable' hours before.
    
    paulddraper - 40 minutes ago
    
    [dead]
    
    paulddraper - 2 hours ago
    
    Are you victim blaming the reporter?
    If you have a bad process, fix the process.
  - charcircuit - 7 hours ago
    
    Why does the PHP security team need to acknowledge it and develop the fix? It's open source software.
    
    lokar - 7 hours ago
    
    If you want an orderly fast global rollout you need to have the maintenance team and distributors working together.
    
    warkdarrior - 5 hours ago
    
    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?
    
    sam1714 - 3 hours ago
    
    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).
    
    charcircuit - 4 hours ago
    
    They already were in communication with each other. They could have come together and decided on one that mitigates the issues they've found.
    
    weird-eye-issue - 7 hours ago
    
    So anybody can just push out a new release of PHP?
    
    charcircuit - 5 hours ago
    
    Yes, someone could have published a safe version for people to use for the 2 months to get the actual fix done.
    
    john_strinlai - 5 hours ago
    
    >Yes, someone could have published a safe version
    this is basically the same as releasing a working exploit.
    
    charcircuit - 4 hours ago
    
    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.
    
    solyin - 3 hours ago
    
    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?