943 pointsby tuyuri 8 hours ago521 comments

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

Discussion

Loading discussion

tuyuri · 8 hours ago
Versions: 8.2.35 8.3.36 8.4.27 8.5.12 Now are available in the php-src github
- technoknol · 8 hours ago
  can't find it.
  - petecooper · 8 hours ago
    Check the tags: https://github.com/php/php-src/tags
bombcar · 8 hours ago
What I did on our WordPress boxes while waiting for distro packages (CVE-2026-109618 / CVE-2026-109619) 1. session.upload_progress.enabled = Off, in php.ini and as php_admin_flag in every FPM pool, so per-directory config can't turn it back on. It's one of the two confirmed consumers in GHSA-6wmf, and the validated FPM path depends on it. Almost nobody uses it, and the advisory suggests leaving it off even after patching. 2. Refuse multipart request bodies at the web server, before PHP parses them. All of the GHSA-w8hw out-of-memory strategies go through multipart parsing. On Apache it's a rewrite rule matching a Content-Type of multipart/form-data that returns 403. On Caddy it's a header matcher that responds 403. The cost: every browser upload breaks (media library, plugin zips, importers). Check your public forms first. 3. Check your SAPI. Both bugs have confirmed RCE against mod_php. FPM is narrower: the validated path needs upload_progress, and the early INI consumer only applies if your front end sends PHP_VALUE/PHP_ADMIN_VALUE. To check, grep your Apache, nginx and Caddy configs for it, and run apache2ctl -M | grep php. 4. pm.max_requests = 1 in the pools. A worker serves one request and exits, which breaks the stale-state chain: the "producer" and "consumer" requests must land on the same worker. It costs a fork per request. 5. Lower max_input_nesting_level and post_max_size, per the advisory. 6. Housekeeping that should already be done: no .php served from uploads directories, and remove any stray phpinfo.php. Scanners request it constantly, and it tells an attacker your exact build.
- dwedge · 8 hours ago
  This is just Claude output. Did you verify anything or just rehash the links?
  - mistertrotsky · 8 hours ago
    HN should ban comments that are just Claude output
    - whycome · 8 hours ago
      I’d rather just some sort of tag. Because sometimes it can be useful. This is a case where the community here can scrutinize the output and actually pull out useful data or steps or even starting points when information is coming in so fast for a developing story/issue
      - bombcar · 8 hours ago
        The (pretty obviously Claude'd) responses with actual steps you could take to mitigate were 1000% more useful to me than the "SHUT EVERYTHING DOWN WE'RE GONNA DIE" and the "stop posting AI slop" posts were, that's for sure.
        dwedge · 7 hours ago
        It was your response. Of course you prefer your response. The fact is you had no idea how useful or dangerous your advice was. PHP maintainers said to shut it down, how many people followed your advice instead? Did it work or just leave them vulnerable? Do you know? Because you're heavily implying that the people who knew about the details of the vulnerability were panicking and thank god we had you with an LLM
    - throawayonthe · 8 hours ago
      https://news.ycombinator.com/newsguidelines.html#:~:text=Don...
  - DonHopkins · 8 hours ago
    Why don't you do something useful and rewrite it so it's not claude output any more, but says the same thing in a way that you're satisfied with? Then your own comment would not be such low effort and useless human slop. Do you agree or disagree with the comment's claims? Did YOU verify anything? Let's all hear you fact check and proofread and reword what it said so it matches your standards, instead of just listening to you bitch and complain without offering any useful information. Or do you not actually know anything about PHP administration, programming, and security, so you're only capable of information-free drive-by anti-ai posts, without any other useful content or corrections? Ball's in your court.
  - bombcar · 8 hours ago
    It's just Claude output of what I've done; the other URL has the basics.
k1kingy · 8 hours ago
Does anyone know how long it takes for the ondrej/php repo to be patched usually?
- longwave · 8 hours ago
  Ondrej has already said "deb.sury.org will carry packages as they are built". https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
  - dstu · 7 hours ago
    You can see them building here, it looks like most should be ready within the next few minutes: https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
- 00deadbeef · 8 hours ago
  I installed the updates 18 minutes ago, they're live.
  - gregoriol · 8 hours ago
    Definitely not available yet, launchpad says last builds are from 2026-10-12
    - leoprctmp · 8 hours ago
      use packages.sury.org instead follow https://packages.sury.org/php/README.txt
      - gregoriol · 6 hours ago
        Sury's own website and launchpad description are really misleading as to what to use, thanks for pointing to it
    - 00deadbeef · 5 hours ago
      They were because I installed them
tux3 · 8 hours ago
Advisories with the details are public: https://github.com/php/php-src/security/advisories/GHSA-w8hw... https://github.com/php/php-src/security/advisories/GHSA-6wmf...
- simias · 8 hours ago
  >PHP uses longjmp() Well off to a good start here.
  - mort96 · 7 hours ago
    It's not exactly uncommon, it's basically C's equivalent to exceptions. It lets you avoid having to do an extra error checking branch after every fallible operation and can quite significantly speed up the happy path of a language VM.
    - simias · 6 hours ago
      I know but I don't think the risks justify using this, as demonstrated here. "It's fine when it's used correctly" except it's so hard to use correctly. It completely messes up any analysis of codepaths because you have this "time travel" footgun that can bypass everything. Exceptions aren't great for that either, but languages that feature them at least have the tooling and support features to make them work. C has no destructors or anything to handle exception unwinding cleanly. Scheme has call/cc, but scheme has a big runtime and garbage collector to deal with the fallout. Let the branch predictor do its job and implement error checking properly, I say. If performance matters so much that you worry about pipeline flushes and icache thrashing, surely you wouldn't be using PHP anyway. setjmp, longjmp and gets are 3 function I would absolutely ban in any C codebase I would be responsible for. Maybe strncpy too. and strtok. C is fun.
    - wat10000 · 5 hours ago
      It's C's equivalent to exceptions, except without any of the stuff that might actually make exceptions safe and reasonable to use in other languages. There's no automatic cleanup of anything, no built-in way to even register things for manual cleanup, and it doesn't even consistently save/restore the values of your local variables. A local variable that was mutated between the setjmp and longjmp may end up with the old value or the new value depending on where the compiler decided to store it. The documentation does mention this and says that you need to use the volatile keyword to avoid it, but in typical C fashion there's nothing to enforce this, it's just up to the programmer to remember it. It is extremely uncommon in C codebases because it is extremely dangerous. It makes hazards like pointer arithmetic and manually-terminated strings look like a walk in the park by comparison.
    - pinevale · 4 hours ago
      > It's not exactly uncommon, it's basically C's equivalent to exceptions. longjmp is very uncommon, I don't recall seeing any high-quality C codebase using it, and if you want exceptions, you should pick a different language because longjmp doesn't really give you comparable semantics. It's basically saying "ok, computer, f--k my s--t up". The fact that OOM conditions are an enduring source of exploitable vulnerabilities in PHP really should give everyone a pause. Like, that's not a thing in any sane project.
      - mjmas · 56 minutes ago
        > I don't recall seeing any high-quality C codebase using it Lua does. (though it does have the option to use C++ exceptions or MSVC stack unwinding instead)
  - the_mitsuhiko · 7 hours ago
    Never use Ruby then.
    - tuveson · 6 hours ago
      Lua as well
    - godd2 · 2 hours ago
      Ruby even uses goto!
  - wren6991 · 4 hours ago
    Not that uncommon for a language interpreter? Pretty sure MicroPython does some setjmp/longjmp for non-local returns.
- fock · 8 hours ago
  did I skim this correctly that with the mitigation shared this does not (yet) impact fpm-usage and classic CGI (vs. mod_php) is not impacted either?
  - Maxious · 8 hours ago
    No, every platform affected. > Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. https://www.php.net/archive/2026.php#2026-10-21-5
    - CodesInChaos · 7 hours ago
      I'm surprised by CGI. The vulnerability description talks about a second request being affected by corrupted state from an earlier request. But I thought CGI only processes one request per process?
      - bombcar · 5 hours ago
        Iirc one of the main performance tricks for CGI was to get processes to stay alive. But there were two vulns - only the second required the two requests.
charcircuit · 8 hours ago
https://github.com/php/php-src/commit/01a40e89fbfc499936e3b0... What everyone is looking for.
- CodeCompost · 8 hours ago
  It says "3 days ago". The tag is 2 days old. I assume it just got pushed?
  - invokestatic · 8 hours ago
    Yeah… it was patched in the source 3 days ago. Check the linked GHSA.
- Good4boothee · 6 hours ago
  Really makes me appreciate using language with exceptions and not that crazy "manually check if error handling is required - and do it everywhere". The fix adds: if (ZEND_HAS_OOM()) { goto oom_nodeset; } all over the codebase.
- dannyw · 6 hours ago
  Gosh. Let's hope they didn't miss a place.
ytxm · 8 hours ago
Click the associated tag: > This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. Glorious. Today of all days it would genuinely give me pause for caution. edit: yeah, really not feeling that: https://github.com/php/php-src/compare/php-8.2.34..php-8.2.3... Hopefully just a mistake? But looks like a botched release at the least
- OJFord · 8 hours ago
  Same on the older few. I'm not sure I understand it though, seems strange you can have a tag for a commit that's only present in a fork? Is it perhaps a bit misleading, and only means that there's no branch containing that commit?
  - cyberclimb · 8 hours ago
    It can mean either, it's a consequence of how github optimized their backend storage so a 100 forks of a repo initially take up the same space as 0 forks
  - drdec · 8 hours ago
    main (or master) is just another branch to git.
    - OJFord · 4 hours ago
      Correct. ..did you mean to reply elsewhere perhaps?
      - drdec · 1 hour ago
        Yes sorry, missed the reply link
  - CodesInChaos · 7 hours ago
    There is little difference between a tag and a branch in git. There is just the convention that tags reference the same commit forever, while branches move. On github forks are part of the same physical repository. You could imagine that each logical repository is just a namespace for branches and tags, backed by the same physical repository. I do consider the warning a bug if github, it should check both tags and branches for commits which are to be considered part of a logical repository.
  - moritzwarhier · 4 hours ago
    Git doesn't have a concept of "fork". GitHub uses this metaphor, and, as another commenter already aptly described, it could be nothing more than a fancy name for namespaced branches, on the server side. On the client side, "forks" are usually different repository clones with different remotes and a "coincidentally" shared history. But you can also map forked repos to multiple remotes of the same repository for example, instead of folders. Assuming that forks would live in separate clones/blobs on the server is not really based on anything, so I think the warning is a good middle ground between explaining what forks are and how they handle them, and giving actionable advice. It's also better suited for PR: "Fork me on GitHub" vs "Branch and push your own clone on GitHub, using our shared blob optimizations". I think the warning is clear and there's nothing misleading about it, but others have already pointed this out and git can be tricky. It's so good at providing the right level of abstraction to everyone though, it seems! Similarly, GitHub invented the term "Pull Request" (aka PR, lol). Not a git-owned term. But "merge request" isn't a Git primitive either! And, with Forks and Pull Requesrs, GitHub made a particular workflow in Git approachable to anyone! I love GitLab, but people get confused by Merges, myself included, so the GH-enabled workflow of favoring ff-only merges, without merge commits, with quadi-linear history, became the norm and helped Git succceed! But I also appreciate being able to do all kinds of different workflows. So PRs were positive-sum PR at the time, I'd say. When they became popular, I was still taught Subversion and CVS at uni, alongside Git as "the new thing". Ar that time, many people considered the older systems simpler, and pondered SVN as the most reasonable middle ground between CVS and the decentralized concept of Git!
abbbi · 8 hours ago
debian trixie just rolled updates.
- Instantnoodl · 8 hours ago
  Can confirm. Just updated to fixed version
- technoknol · 8 hours ago
  when's bookwarm coming?
  - abbbi · 8 hours ago
    packages are building: https://buildd.debian.org/status/package.php?p=php8.2&suite=...
  - kps · 8 hours ago
    Already, including backports to 7 and 5.
- Pxtl · 7 hours ago
  Debian always seems to be the grown-ups. I'm a Linux novice so I couldn't get Nvidia drivers working on it but that's the only reason it's not running on my desktops.
bstsb · 8 hours ago
i just took down all my PHP sites for the last few hours. they’re proxied behind Cloudflare so i know there were mitigations, but infrastructure can’t be breached if it isn’t running!
- bombcar · 8 hours ago
  Now I need to get the cute name for a vm vulnerability that attacks offline servers ... awake2death or something
  - MertsA · 2 hours ago
    I once wrote a PoC for reading data off of a dead Open Compute Grand Canyon server that wouldn't boot by sneaking it off of the HDDs through a sideband through the BMC. Never say never.
- indemnity83 · 3 hours ago
  Similar here, except I didn't want to actually shut down the servers, because then I can't patch them! My solution was to just turn off Nginx, which prevents anything from reaching PHP. Then I stuck a caddy server with a temporary config so we get actual 503 maintenance responses. It seemed to be helpful for others too so I packaged it up, should work on most Nginx / Certbot servers. hopefully its useful: https://github.com/Indemnity83/popcorn
magar_fos · 8 hours ago
C'mon Ondřej..
- lousken · 7 hours ago
  it's out?
  - dizhn · 5 hours ago
    yup
andix · 8 hours ago
Does anyone know the ETA on the official php:* docker images? I think they only released patched 8.6 RC containers for now.
- rocky_raccoon · 8 hours ago
  How about the Ondrej PPA repos for Ubuntu?
  - nolok · 7 hours ago
    They're updated for all versions
- jhogervorst · 8 hours ago
  The PR with the update is here: https://github.com/docker-library/php/pull/1694 Looks like we need to be patient: > Why is this not merged yet? > I'm not a maintainer and can not merge this. Please wait until a maintainer has come around to look into this. > This is merged, but I cannot find the image? > After this PR has been merged, more steps are to be taken, including an upstream merge on docker-library/official-images and subsequent image builds. For a full description of the timeline, please refer to docker-library/faq#an-images-source-changed-in-git-now-what.
  - dmtroyer · 8 hours ago
    one of the more entertaining PRs I've seen
    - andix · 7 hours ago
      Enough spam comments to create a huge blacklist of misbehaving github users.
- mrintegrity · 7 hours ago
  Might have to wait for the github outage to be resolved first :D https://www.githubstatus.com/
cowlevel · 8 hours ago
So they've added malloc fail checks and tests for malloc fail throughout. Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?
- antiloper · 8 hours ago
  PHP is tracking its own memory usage internally with limits configurable via php.ini.
baggy_trough · 8 hours ago
They bundled the fixes with a regular bugfix release, looks like.
- jayknight · 8 hours ago
  Yeah, there was a new patch release in the works already. They just added this fix and got it out the door. Changelog: https://www.php.net/ChangeLog-8.php#8.5.12
janmo · 8 hours ago
apt-get update + apt-get upgrade fixes it on Debian, but not on Ubuntu for now
- Maxion · 8 hours ago
  You can on ubuntu change to use ondrej/php and update now
  - patrickdavey · 4 hours ago
    I've been trying to update my (noble 24.04) server and an apt update is not showing the 8.5.12. It looks like the binary has been built but not updated in the index http://ppa.launchpad.net/ondrej/php/ubuntu/dists/noble/Relea... (last update 14 yet. https://launchpad.net/~ondrej/+archive/ubuntu/php/+build/338... suggests it finished at ~ 17:00 UTC Though quite possibly I'm missing something ;) --------------- edit: as I was typing the index was updated. So, as far as I can tell only just now (18:20 UTC) was it available for updating!
- reddalo · 8 hours ago
  Add Sury's repo and update from there: https://packages.sury.org/php/README.txt
dmtroyer · 8 hours ago
Have we ever seen the "get ready for a security release tomorrow" email before? https://www.php.net/archive/2026.php#2026-10-20-1
- bombcar · 8 hours ago
  Many vendors do it, but on a set schedule "patch Tuesday" and some will release vague "mitigation steps" but honestly those usually come with the patch.
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)
- darkwater · 8 hours ago
  Why is WordPress out of that list? Isn't it the single major PHP installation in the whole Internet across hosted and self-hosted instances?
  - bombcar · 8 hours ago
    Because the CEO of Wordpress has gone insane, basically.
    - nicce · 8 hours ago
      Automattic is on the list, tho.
  - trollbridge · 8 hours ago
    Well, WP is just a program written in PHP.
    - ImJamal · 8 hours ago
      They have hosted instances as well though. Not sure their market share though.
    - dspillett · 8 hours ago
      One of the most common PHP based applications out there, therefore a good comms channel (via their forums and any mailing lists, both public and for people who have managed instances with them or are otherwise paying for support contracts) to make sure people are aware of the need to update. That would make the company one worth keeping in the loop, if only in one direction, I would have thought?
      - trollbridge · 8 hours ago
        Well, it would help if WP were actually controlled by one entity, but currently it's dominated by factions and infighting.
        dspillett · 7 hours ago
        Fair point. I thought that had died down, though for some years I've not had reason to keep particularly informed about the state of WP so I could be missing a lot of hot gossip.
  - 12837615 · 8 hours ago
    WordPress is down right now. A bit late for patching though ...
  - LoganDark · 8 hours ago
    I agree, WordPress should be like the first thing they point out. I'd imagine most WordPress users don't even know it runs on PHP
- chinathrow · 8 hours ago
  > Over the past two months, we led a coalition of maintainers, researchers, and security providers to address critical vulnerabilities in PHP, an open-source programming language used to run websites and web applications. And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
  - nicce · 8 hours ago
    Wiz is owned by Google and Argon gets the main credits. So difficult to tell these days. But AI is obviously useful here. Edit: was looking Wiz post when citation was from OpenAI
    - chinathrow · 8 hours ago
      Of course it's useful, but you can't absolutely not leak something as big as this.
  - janmo · 8 hours ago
    They haven't even been able to release the patch on time. Ubuntu still hasn't it
    - hdgvhicv · 8 hours ago
      I had an email from usn recently
    - dspillett · 8 hours ago
      Debian has, though only for current stable (updates for oldstable and oldoldstable apparently about to drop) which might imply they had no advanced access to the update so could not pre-test and release immediately upon the coordinated announcement.
      - nolok · 7 hours ago
        Sury is up for all versions too
    - rob · 8 hours ago
      Not true. I was able to `aptitude update` and `aptitude full-upgrade` before 10:00 AM EST (9:50 AM) and received the new php8.* packages and upgraded fine.
      - kijin · 7 hours ago
        Anyone using a non-default version from the semi-official PPA by Ondrej Sury is still waiting for an update. The launchpad server is throwing 503 errors all over the place, so that's probably the reason for the delay. Sury's own repo has the fixes all right.
      - cpncrunch · 7 hours ago
        Still no update for ubuntu 20.04 which has support via ESM, even though the patch is available for php 7.4. There are a lot of people using older servers which still have ESM support.
        cpncrunch · 6 hours ago
        Patches have now landed for 20.04 and other earlier Ubuntu versions. https://ubuntu.com/security/CVE-2026-109618#status
    - unethical_ban · 7 hours ago
      at 15:00 UTC, spot checking, Debian 13 has a fix, Ubuntu 26.04 and Fedora do not.
      - lee_ars · 7 hours ago
        PHP 8.5.4-0ubuntu1.5 (the fixed version for Ubuntu 26.04) has been downloadable for me via apt from security.ubuntu.com for about 30 minutes. Perhaps check to see that you're not using a different mirror?
        unethical_ban · 7 hours ago
        You're correct, I was looking for the upstream patch number.
  - anon1642 · 8 hours ago
    I heard this was leaked several days early and that’s why folks seem to be on the back foot. I’d press go too - if something this big was known to some but not all… We’ll all get through together
  - giancarlostoro · 7 hours ago
    If I understood the timeline correctly, there was an announcement made somewhere that an RCE would be announce w/ a patch, and the internet just scanned the entire codebase, they really fumbled this for the sake of having a PR post for OpenAI. On the other hand, I don't mind AI companies doing this sort of thing, I'm sure a lot of our internet infrastructure could benefit from these sorts of fixes and changes.
    - Maxious · 7 hours ago
      The somewhere was a loser on this very website https://daubois.dev/blog/cve-2026-109618-php2shell-rumors/
      - novafacing · 7 hours ago
        This post reads like pure slop to me
        joquarky · 1 hour ago
        Honestly, who cares at this point? The slop announcements are getting more annoying than the slop.
    - ndiddy · 7 hours ago
      After the HN post came up, one security firm included "session.upload_progress.enabled", "session.use_strict_mode", and "php-fpm" in the SEO tags for their initial disclosure that a vulnerability existed. I imagine this was a good hint. https://web.archive.org/web/20261021005246/https://sansec.io... https://x.com/its5q/status/2112700519261032497
  - pinevale · 4 hours ago
    > And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE. This is a pretty constant theme in the infosec industry. The idea is that you want to do the "responsible" thing and let all the major, multi-billion-dollar companies patch first, so you form a secret club. But then, you share a very juicy, gossip-worthy thing with hundreds of people and ask them to sit on it for weeks. And guess what happens: they don't. Having worked for a big tech company, I've been involved on a couple of processes of this sort, and they all suffered leaks. And rest assured, we'll learn nothing and try the same thing again next month or next year. Because what's the alternative? If you 0-day everyone, you get more hate mail, not less. It's all of sudden about you, not the vulnerable code. Microsoft or Cloudflare calls you irresponsible when asked for a PR statement, industry bloggers bully you, etc.
- tetraodonpuffer · 8 hours ago
  surprising it took nearly a month to acknowledge the bug August 24, 2026: Wiz Research reports the vulnerabilities to the PHP security team. September 21, 2026: PHP acknowledges the reports and begins developing a coordinated fix.
  - bramhaag · 8 hours ago
    Took them almost 7 years even. According to the Calif write-up it was already reported in 2019 ( https://bugs.php.net/bug.php?id=78876 ) and 2024 ( https://ostif.org/php-audit-complete/ ).
    - polishdude20 · 8 hours ago
      Lol wait so OpenAI's LLM to discover this vulnerability most likely just looked it up in an old forum post?
      - charcircuit · 8 hours ago
        That's what my agent did to find a UAF. It just took a public one from calif off the internet and found it still flagged asan.
      - pixl97 · 8 hours ago
        This isn't a terribly uncommon method of 'discovery'. In maths and sciences there have been tons of papers that have highlighted something new but were never really connected to anything else and then largely forgotten. Later they are picked up by someone else and connected to a much bigger whole.
      - hobofan · 7 hours ago
        It's only one piece in the full exploit chain.
      - abc42 · 4 hours ago
        That's how 90+% of script kiddy -type hackings happen, isn't it. That or publically available databases without a password. AI is gonna make our stuff pretty robust, eventually. The transition phase might hurt a bit.
    - akersten · 8 hours ago
      No way to prevent this, says only language where this regularly happens
      - elmer2 · 5 hours ago
        Criticals happen in other languages all the time. You are seeing this with PHP in the news because it's used on 70% of the Internet.
        akersten · 2 hours ago
        https://fedi.katze.sh/@elise/117479383739450605 ¯ \ _ ( ツ ) _ / ¯
    - phplovesong · 7 hours ago
      LOL PHP will always be the slop before AI.
    - gcr · 7 hours ago
      The bug you posted was patched and fixed 6 years ago, and none of the other bugs in the audit showcase that issue. Are you sure these are the right links?
- esquire_900 · 8 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 · 8 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.
    - charcircuit · 8 hours ago
      Why does the PHP security team need to acknowledge it and develop the fix? It's open source software.
      - weird-eye-issue · 8 hours ago
        So anybody can just push out a new release of PHP?
        swiftcoder · 7 hours ago
        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.
        0x457 · 6 hours ago
        Did start writing software this week?
        LordDragonfang · 4 hours ago
        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).
        swiftcoder · 3 hours ago
        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.
        charcircuit · 6 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 · 5 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 · 4 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?
        charcircuit · 2 hours ago
        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.
        Dylan16807 · 1 hour ago
        > 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.
        charcircuit · 52 minutes ago
        And in the situation where they released a security patch 2 months ago, there would be a security patch before the bug was public.
        Dylan16807 · 16 minutes ago
        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.
      - lokar · 8 hours ago
        If you want an orderly fast global rollout you need to have the maintenance team and distributors working together.
      - justinhj · 7 hours ago
        What would you have a security team for then?
        charcircuit · 5 hours ago
        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.
      - wat10000 · 7 hours ago
        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.
        theboblong · 7 hours ago
        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?!
        aDyslecticCrow · 4 hours ago
        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.
      - 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?
        charcircuit · 5 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.
        sam1714 · 4 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).
      - paulddraper · 1 hour ago
        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.
    - bombcar · 8 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.
      - 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
      - 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/
        Twirrim · 7 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.
        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.
        soulofmischief · 4 hours ago
        These illustrations are neat but severely distracting given that each make a mountain out of a molehill.
      - 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 · 2 hours ago
        Are you victim blaming the reporter? If you have a bad process, fix the process.
  - dannyw · 8 hours ago
    Maybe the NSA ‘requested’ some time to use the exploit on some high value targets. Sure, it’s PHP, but plenty of companies or organisations might have some PHP running somewhere; and once you’re in, lateral movement becomes a lot easier.
    - DaSHacka · 7 hours ago
      The NSA does not need to "request" time to use an n-day vuln. They have more 0-days than you can imagine. They literally employ full-time Vulnerability Researchers doing nothing but 0-day discovery and PoC creation 24/7 to add to their horde. Plus contracting with the MIC for their full-time VRs for the occasional project.
      - bombcar · 5 hours ago
        Exactly. Something like this is often the NSA realizing one of their pet vulns is being exploited in the wild by someone “not them” and so they burn it.
  - dspillett · 7 hours ago
    One concern with the current environment is that as soon as a release comes out for such an important open source project, people will immediately point bots at the release to look for changes that might be related to existing security issues. This means that putting out a quick out-of-band release is guaranteed to result in people racing to exploit the problem before many even know there is an update out. Whether keeping the update quiet and including it in the next normal release, where there are more trees obscuring the wood that is the security concern, and announcing the bug a short time later once anyone using distro updates or otherwise keeping on top of things have updated, would be safer overall than what has happened today is up for debate. I can think of arguments in both directions. -------- [1] which does have a slight whiff of AI marketing about it - would a human-found issue, without the option of a big AI company to claim some credit, have been handled differently?
    - chilmers · 7 hours ago
      This is not a "concern", this is literally what happens. Even prior to AI vulnerability scanning, release notes and diffs for any normal release or security patch of popular software were analysed and used to develop exploits, which could then be applied against non-upgraded instances. Nowadays, AI is doing this en masse and automatically producing exploits. And, as has been demonstrated, nowadays even the rumour of a major security bug is enough for people to find it, as people will immediately burn huge volumes of tokens looking for it. Nor can you just keep it quiet and smuggle it out in a regular release as you suggest. For one thing, changes in important software are be linked to commits and have pull requests, reviews, etc. Changes without these will immediately raise suspicion, as either a malicious change snuck into a release, or as a "quiet" fix to a major vulnerability, completely undermining the purpose of keeping it quiet in the first place. Moreover, major vulnerability fixes cannot be "quiet", because the whole point is to get as many people as possible to upgrade as quickly as possible. If PHP (or whoever) push out a release containing a major security fix, but don't make this clear, then many people will be in no rush to upgrade, and will get pwned.
      - dspillett · 4 hours ago
        > This is not a "concern", this is literally what happens. Sorry, I should have been specific: the concern is that this will happen faster than even the more fastidious admins (or daily or even hourly automated checks) will spot and apply updates. > nowadays even the rumour I think a lot fewer people would have paid attention at all without the rumour. Some ne'er-do-wells might have scanned a larger update for security issues otherwise, but I suspect most of those spending tokens on PHP this week would not have bothered had there just been a standard maintenance release that may or may not have included changes for a security issue that may (but probably not) have been so globally significant. That is, at least in part, why the question of how to manage the release of updates like this is not a settled debate. > then many people will be in no rush to upgrade, and will get pwned. The worst case that we may be heading towards is that for any services on public facing infrastructure we might have to automatically apply updates with little or no time to verify, just to try be ahead of the ne'er-do-wells, with even superficial updates not mentioning the changes until a short time after to avoid giving clues to those who will scan for security issues if any such is mentioned (or nothing is mentioned - saying nothing about a security-only update only works if you say nothing about all updates, and you don't want to hold off on security-only updates on a slow moving project that might not have a non-security patch for quite some time).
  - beberlei · 7 hours ago
    Php core security team decided who gets to know. The patch was huge it took that long. See PHP foundation blog post on their timeline
  - Avamander · 7 hours ago
    You can't do secret releases, people will figure out what you added or changed. But they could have accelerated the patch release once the embargo was broken and rumors of a PoC started going around. There was no need to wait 12+h today until the release.
  - stingraycharles · 7 hours ago
    “OpenAI and these security companies sat on this for 2 months” I don’t think this what happened at all, and even less so to specifically call out OpenAI. The issue was discovered using their model, it was disclosed, and the PHP team took months to address it. Eventually it leaked. This is a process / people failure that does not involve the people responsible for discovering it.
    - flanz_10 · 4 hours ago
      this is the same tired conversation whenever coordinated disclosure happens "we the people deserve to know about vulns on day 0" oh yeah? and what happens when a 0 day is released? it's the same ignorance over and over.
  - vikramkr · 6 hours ago
    It's not possible to publish a security patch for an open source software report without revealing security details anymore (and as of the past couple weeks I would not count on being able to do that for closed source binaries either). The moment you push publish everyone knows previous versions are compromised
  - Capricorn2481 · 6 hours ago
    > OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix Amazingly, AWS Linux has not been patched yet.
  - pier25 · 5 hours ago
    > OpenAI and these security companies sat on this for 2 months The PHP team knew about it since September 21st.
  - chairmansteve · 5 hours ago
    Maximizing the PR value...
  - MP_1729 · 5 hours ago
    Of course it was OAI that decided those things, not the U.S. Government
    - john_strinlai · 4 hours ago
      it was neither OAI or the US government.
  - hparadiz · 2 hours ago
    And then they proceeded to cripple any of my agents working on this.
- consp · 7 hours ago
  > https://www.php2shell.com/ Boy, do I hate these PR websites masquerading as vulnerability reports. It's slop all the way down with these companies.
  - bombcar · 5 hours ago
    I wonder how early the domain was registered and when the first certificate was issued for it, whether you could’ve had advanced notice of this by watching the DNS records
    - rollulus · 5 hours ago
      Guess what, there are answers to that question! October 14, 2026 was the date the domain got registered.
      - croemer · 4 hours ago
        Domain registration doesn't mean that much. Many similar domains are already registered, eg python2shell.com is 5k aftermarket but js2shell.com is unregistered. Might not be a bad investment to register the .com for all the top PLs.
- Pxtl · 7 hours ago
  Thank you, Wiz Khalifa.
- wildmXranat · 7 hours ago
  Yet it was leaked and I can't see a single "Here's this piece of code you can run to validate the fix actually works" It's like slop for infosec markters
- pluc · 7 hours ago
  Wiz Khalif AI
- alper · 7 hours ago
  Do they consider this an example of a "good" response?
  - anon83748359 · 7 hours ago
    It’s in-line with the rest of the pho eco system.
- WJW · 6 hours ago
  So how does the exploit actually work? The best I can find is that they manage to use the corrupted generic decoder state to write a single pointer and associated PHP type information anywhere in memory, then immediately claim "this is RCE". Is that enough? From my (admittedly limited) understanding of such things, after writing code to the target memory you also need to be able to start actually running it. Or do they overwrite the PHP code (which is somewhere in memory) and then let the interpreter do its thing?
  - benibela · 5 hours ago
    I am curious about that, too Here was a PoC: https://jackalsyn.com/posts/php-up-2026.html But it was withdrawn; now it says that it (CVE-2026-109618) is not an RCE and not even a CVE, apparently an addref call prevents the use-after-free. CVE-2026-109619 is still a memory safe bug, but they have no RCE for that one
- luca4 · 5 hours ago
  WizCalif.. dude xD
nairboon · 8 hours ago
A bit too early for the announced coordinated release, no?
- cholmon · 8 hours ago
  Their earlier comment said > We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild. https://www.php.net/archive/2026.php#2026-10-20-1
  - nairboon · 8 hours ago
    Good point, at least now Debian has shipped the patched packages.
- kps · 8 hours ago
  Two minutes before the announced 1400UTC? Or have I forgotten how to math?
  - nairboon · 7 hours ago
    More like >10min early. It's close, but given today’s speed of agents..
petecooper · 8 hours ago
>Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
dataflow · 8 hours ago
Is PHP 7 essentially going to be dead and unusable for everyone then? Or will it get fixes?
- Operyl · 8 hours ago
  There are backports already.
- kps · 8 hours ago
  Debian has a new build of 7.4 at least.
  - cpncrunch · 7 hours ago
    Not out on Ubuntu 20.04 yet, but sometimes they are a little slower. Hopefully should be posted later today.
- guffins · 8 hours ago
  PHP 7 hasn’t received an update since 2022 when it went EOL. EDIT: looks like there are backports though