PHP 8.2.35

8 hours ago (github.com)

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

564 comments

tuyuri

Reply
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.

      36 replies →

    • 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?

      2 replies →

    • 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

    • stingraycharles  6 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.

      1 reply →

    • Avamander  6 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.

    • dannyw  7 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.

      2 replies →

    • beberlei  6 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

    • pier25  5 hours ago

      > OpenAI and these security companies sat on this for 2 months

      The PHP team knew about it since September 21st.

    • Capricorn2481  5 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.

  • 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.

    • 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.

      4 replies →

    • 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.

    • nicce  7 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

      1 reply →

    • anon1642  7 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

  • 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

  • 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?

  • 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

OscarCunningham  6 hours ago

Looks like there might be a second vulnerability: https://fedi.katze.sh/@elise/117479383739450605

  • modeless  5 hours ago

    There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.

    • anonymous908213  4 hours ago

      "The entire world should use 2x more compute" is not a real answer. You can do that on your own personal computer which has compute to spare. For servers, you're already paying for the relevant amount of compute to serve your thousands or millions of users, and every % of overhead matters at that scale. You are suggesting everyone allocates a 2x budget for server-compute, or I suppose you're only talking about hobby servers where people are running tiny workloads and had so little traffic it doesn't matter?

      8 replies →

  • dannyw  5 hours ago

    The patches are very dirty (thousands of `if (ZEND_HAS_OOM()) { .. return failure`); my first reaction is they've probably missed something.

    • akersten  2 hours ago

      People keep defending PHP (as they have been for ages) saying things like "oh, it could happen to any platform, this one's just so popular so the odds are higher" but then you take a peek at the diff for this fix and realize that nothing has changed since Fractal of Bad Design was published a decade ago. PHP is a scourge and unfortunately a still too popular one. The best time to realize the only safe option is to stop using it was in 2010, the 2nd best time is now ..

  • sharess  4 hours ago

    Extremely embarrassing for OpenAI marketing. How did they not catch this?

    • andix  4 hours ago

      For now this is just one person posting about it. Can be real, can be a mistake, can be a hoax. But if it's real, then OpenAI once again fudged up really bad.

spenvo  7 hours ago

Edit: and it's live now 1hour 43minutes after. Edit 2x: well I spoke too soon. not actually live - the 8.4.27 tag appeared, but it's still an empty shell with no amd64 image to build from. Maybe other architectures can be built from though. Ugh. Now we're at 2hours 24minutes in. I know process steps take time/can't be rushed, and I know people mean well and surely some are unappreciated for what they do. That said: this debacle is making me want to reassess my deployment pipeline choices.

how does Docker not yet have a new, official PHP image ready, given such a big heads up? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are 52 minutes past due. (posting comment again, because the other thread i posted in was marked as dupe.)

basilgohar  7 hours ago

This is obviously bad, but in my 20 years of hosting with PHP, I've never had to take the steps of taking down servers preemptively. It's not good, but honestly, and I think the way this was handled could leave a lot to be desired, I think this might be the "worst" we've had with PHP, and it took a while to get here.

  • danso  7 hours ago

    FWIW this is the most mainstream vulnerability in the new era where everyone has access to AI agents that have the potential capability to find and widely exploit the vulnerability far faster than the past timeframes for disclosure and patching.

smusamashah  4 hours ago

Someone is saying there is a new vulnerability that works on the newest 8.5.12 https://x.com/_annieversary/status/2112933589943742598

cholmon  7 hours ago

Ondrej might appreciate some monetary love on a day like today.

https://www.patreon.com/cw/oerdnj

  • aftergibson  7 hours ago

    Not even $700 a month? Seriously, there must be thousands of highly profitable companies depending on this guy’s maintenance. Once this is all sorted, please hassle your employers to give something back to him!

  • basilgohar  6 hours ago

    Thank you for calling this out. I absolutely rely on him so I decided to contribute $100/month even though I'm a solo dev with a business yet to see profit. But I absolutely rely on him for my server(s) PHP packages.

  • sct202  7 hours ago

    There is a one time option on his github as well for those who don't want to do subscriptions.

  • jijijijij  26 minutes ago

    Speaking of, the PHP PPA was pretty unusable all day. I wonder, if this was just high demand or intentional attacks on launchpad servers to prolong the exploitation window.

  • jdhawk  4 hours ago

    Dude even backported the fix to his 5.6->8.0 branches

    Newest: 5.6.40-104 which has the CVE fixes.

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...

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?

    • moritzwarhier  3 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!

    • CodesInChaos  6 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.

    • 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

      1 reply →

majewsky  7 hours ago

> out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.

If only we could come up with a way to manage memory automatically. Alas, one can only dream.

  • kg  7 hours ago

    I'm pretty sure this class of problem would exist in GC'd environments too unless they're configured to abort on OOM, in which case you'd still be dealing with denial-of-service.

    In some environments OOM is a trappable exception, so it's possible that incorrectly authored code would trap the OOM and 'recover' with partially initialized data sitting on the heap. Hopefully it's a memory-safe language so that partially initialized data isn't RCE...

andrelaszlo  7 hours ago

Just pulled the new matomo that was published on dockerhub 26 minutes ago, thinking it has the patched PHP version:

  # docker pull matomo:latest
  latest: Pulling from library/matomo
  Digest: sha256:6e63589d31ec653f78e029084d21488640fdbbd9a42c96c872098f42c8678a02
  Status: Image is up to date for matomo:latest
  docker.io/library/matomo:latest
  
  # docker run --rm matomo:latest php --version
  PHP 8.4.26 (cli) (built: Oct 21 2026 00:31:19) (NTS)
  Copyright (c) The PHP Group
  Built by https://github.com/docker-library/php
  Zend Engine v4.4.26, Copyright (c) Zend Technologies
      with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies

The PHP build is from today, which is doubly misleading. 8.4.27 is the patched release, not 8.4.26. I wonder how many people will pull this image thinking they're good to go online again.

  • andix  4 hours ago

    The "official" PHP Docker images turned out to be a shit show tody. Seems like many maintainers fell for it and published updates that aren't really updates.

    I'm currently waiting for a new docker image for another project, and their maintainer noticed the old PHP versions in the freshly built images and is still waiting or working on releasing a new container build.

    • xorcist  3 hours ago

      There is nothing official about these images.

      "Let's use this packaging some rando on the Internet built" is a strategy that is exactly as good as it seems, but that's the Docker ecosystem for you.

      Packagers who actually understand the software put in good work to package that software in small and well maintained packages. Use them instead!

      1 reply →

    • lol768  4 hours ago

      Fully agree. Moved to FrankenPHP's static build (which was ready very quickly) to get away from it. Don't intend to ever use the "official" images again.

      2 replies →

  • bityard  1 hour ago

    I had to build and deploy my own Nextcloud images earlier today. :( Not a big deal because docker, just obnoxious that this got released into the wild and was being actively exploited before patches were available everywhere.

  • teekert  7 hours ago

    Same goes for Wordpress indeed, which I'm waiting for.

        $ docker pull wordpress:fpm && docker image inspect wordpress:fpm --format '{{.Created}}' && docker run --rm wordpress:fpm php --version
    fpm: Pulling from library/wordpress
    Digest: sha256:c6d271a445510a3e08cfcc487750ac014f4464165ad6df6356da04680be8e907
    Status: Image is up to date for wordpress:fpm
    docker.io/library/wordpress:fpm
    2026-10-21T01:27:06.695704995Z
    PHP 8.3.35 (cli) (built: Oct 21 2026 00:33:17) (NTS)
    Copyright (c) The PHP Group
    Zend Engine v4.3.35, Copyright (c) Zend Technologies
      with Zend OPcache v8.3.35, Copyright (c), by Zend Technologies

    I guess they were planning an update for today, for a moment the 8.2.35 threw me, but .35 is patched on 8.2, unpatched on 8.3 :)

  • trvz  7 hours ago

    If you need Docker to run PHP software you're beyond any help already.

    • teekert  7 hours ago

      Yeah, I really enjoyed messing with php.ini back in the day! Setting it juuuust right for every different project on my dear pet.

dataflow  19 minutes ago

Is there a curl command I can use to test if the vulnerability is fully patched on a server (not merely mitigated) without causing any harm?

Note I want it to work with the backports too, not just the latest version.

bartnp  6 hours ago

If LLM's are going to keep finding vulnerabilities of this magnitude, we'll be sure to face a computer worm event of unprecedented scale soon. Best be ready for the moment the lights turn off

imzadi  8 hours ago

FML. Can't get in to update our servers because of MFA and our director, who gets the codes, isn't in

  • bartread  7 hours ago

    Great example of performative enterprise security practice that contributes to degraded security posture, I suppose. Best of luck.

    • andix  7 hours ago

      What would happen if the director suddenly gets sick or decide not to come to work anymore? A lot of people assume that humans are reliable, they are not.

      10 replies →

  • openclawuser  7 hours ago

    With AI agents, I've been using sites/services that are bot friendly and don't require MFA.

    Not everything needs hyper security. Heck, I've given AI access to spend money on websites and my only restriction is that the websites limit the daily spend(website side... Although I guess a rogue AI could have changed it... )

k1kingy  8 hours ago

Does anyone know how long it takes for the ondrej/php repo to be patched usually?

dstu  8 hours ago

So far Ubuntu LTS isn’t picking up the new packages for me via apt update, and Laravel Forge appears completely unresponsive as a result of being flooded by people trying to update their servers.

  • trollbridge  7 hours ago

    And I'm maintaining a box on 18.04 over here, and lo and behold its Pro subscription isn't showing up as active, so I couldn't get the update even if they do release it.

    Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)

  • Neil44  7 hours ago

    Same, I'm spamming the apt update and so far nothing on 22.04 or 24.04 lts

    I realised that my linode and ovh vm's point at local mirrors not direct to ubuntu, I guess that's why the delay

    • mminer237  4 hours ago

      Yeah, Linode still hasn't updated their mirror. Vultr has though.

      Edit: Linode just updated its mirror.

spenvo  7 hours ago

how does Docker not yet have a new, official PHP image ready, given such a big heads up? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are 27 minutes past due.

  • reddalo  7 hours ago

    Yes, it's embarrassing for Docker. Makes me wish I still had the classic LAMP stack.

    • geerlingguy  7 hours ago

      A PR was posted within a minute or two of PHP's source code update. Then within a minute of the PR's CI job completing, it was merged, and the build took a while but is now complete: https://github.com/docker-library/php/actions/runs/396158697...

      It would not be easy (or reasonable) to take a public build like that private to build a 'secret' image version, and I'm not sure GitHub even has the capability to do that. I would not trust a build pushed to Docker Hub separate from the established / public / auditable process they have in place.

      4 replies →

  • KaiserPro  7 hours ago

    Docker have been carrying a broken python build for months.

    they are wanting people to pay for the hardened version.

conradfr  5 hours ago

Hard to deploy if you also install extensions from PECL right now (probably slammed).

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.

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!

  • 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

  • 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.

tikotus  7 hours ago

Has there yet been any signs of any service actually being successfully hacked due to the vulnerability?

  • redox99  6 hours ago

    I'd expect agents to be hacking hundreds of thousands of websites as we speak.

    They'll of course install a backdoor and patch the exploit so others can't come in. They won't deface the website, so there won't be signs.

  • tovve  6 hours ago

    Watchtowr reports yes, but doesn't say where exactly right now: https://watchtowr.com/intelligence/php-cve-2026-109618-faq/#...

    • decidu0us9034  6 hours ago

      Well they did specify "successfully." EITW is a pretty broad tag, just means attacker are probing servers. I'm not saying it's good but there are usually some pretty big caveats with remote-remote memory corruption, don't know if all the people dooming are aware of that

      > Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout.

janmo  8 hours ago

Still no release for Ubuntu... They are already half an hour late. Debian got the patch almost immediately...

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.

Amsozzer  8 hours ago

Since I have to go through a bunch of php repos today at work I ended up releasing a CLI tool that automates that process by listing out the steps you need to take to stay away from the vulnerability. Here's the link incase it helps anyone https://github.com/Amsozzer1/php2shell-repo-audit

  • trollbridge  7 hours ago

    Dude, today of all days is not when I'm going to trust some random CLI tool that was vibed out. I'm not saying your work isn't helpful, but it would probably be a lot better to just release your prompts you used to build this and let others build it on their own.

TekMol  8 hours ago

Why is the description of "RCE via OOM corruption" mentioning all these settings like memory_limit, post_max_size, max_input_nesting_level etc under "Mitigation" but not blocking multipart requests? Isn't that a solution?

The description of the vurnurability "Several multipart parsing problems" makes it sound like it is?

blain  4 hours ago

Great that its out but if you depend on pecl for additional extensions and need to rebuild docker container it will probably fail because pecl is having issues for last few hours[1].

[1] https://status.php.net/

It says pecl.php.net recovered but downloading source for extensions ends up with 504 most of the time.

jillesvangurp  5 hours ago

My hosting provider just informed me that they took down my website over this to "protect" me. It's a static website that does not use any php. But it's a generic LAMP hosting provider so they just took down all their hosted websites. I had it on my to do list to migrate that to cloudflare anyway. So, I guess I'll be doing that soonish now.

  • ytxm  4 hours ago

    When every neighbour decides to leave their doors unlocked simultaneously,and the entire world knows it, maybe barricading the village is protecting you

dabinat  3 hours ago

Trying to install this update but it appears that Launchpad doesn’t have the bandwidth for half the world to all update at the same time.

pier25  7 hours ago

Apparently about 40% of PHP apps are still on PHP 7 and 5...

  • kps  7 hours ago

    I see Debian has packages.

    5.6.40-104+0~20261021.134+debian12~1.gbp7401dd

    7.4.33-31+0~20261021.121+debian12~1.gbpe9c428

  • abanana  7 hours ago

    There are rare occasions when circumstances are more important than preserving an "EOL" designation. This appears to be one of those times where "official" centralized patches really should be made available for at least PHP5.6 and PHP7.4, and perhaps even 5.5 and all of 7.x. They're not covering themselves in glory by refusing.

    • nolok  7 hours ago

      If those place at using a LTS release of their OSes they will be patched quickly (Debian already has). If they're not, they're already screwed by a lot more than just PHP I guess.

      1 reply →

londons_explore  5 hours ago

I was under the impression that this sort of bug is fairly common in both php and common php frameworks?

I thought the real lesson was "assume your web server is compromised if you use php, and try to make sure php doesn't touch anything too critical"

  • user43928  4 hours ago

    I'm struggling to see any reason to use PHP in the first place if it can run without access to private data.

    At that point I would not need a backend.

  • arm32  5 hours ago

    Yes, there have been decades of talk about this already—ensuring you isolate/jail the PHP-related processes and run them with an unprivileged user, etc.

  • dizhn  5 hours ago

    It's usually scripts that can write to /tmp and run unrelated stuff with web user rights. This seems more involved.

RoshanAmble  3 hours ago

Seems like they finally decided to release it after so many people had access. What happened to security as a priority.

janmo  8 hours ago

apt-get update + apt-get upgrade fixes it on Debian, but not on Ubuntu for now

a-nych  4 hours ago

I've created patched Dockerfiles for EOL PHP versions. The patch is obtained from official source trees.

I've also published the built images from them to GitHub Registry, but of course it's best to inspect any public repo/docker image before using them blindly.

https://github.com/a-nych/php-eol-backports

abbbi  8 hours ago

debian trixie just rolled updates.

alper  6 hours ago

They have to backport this fix or else leave a large part of the internet broken.

charcircuit  8 hours ago

https://github.com/php/php-src/commit/01a40e89fbfc499936e3b0...

What everyone is looking for.

  • 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.

butler14  6 hours ago

I’m not especially technical, but I have clients with WordPress websites. Can anyone perhaps put in a sentence or two what I need to suggest they do?

  • schleck8  6 hours ago

    Tell them to take anything with PHP offline, so that it isn't available from the public internet. That is how Netcup and Contabo are handling Wordpress hosting until they've upgraded all affected packages.

    There are already functional exploit scripts on GitHub, you can target any Wordpress site right now.

  • qwm  6 hours ago

    Shut the sites down until you are able to update to the latest PHP patch for your version.

system7rocks  1 hour ago

I'll give a shoutout to Lithium Hosting. I was able to log in and update my PHP Pool per their custom control panel and switch all of my sites over to the latest fix: 8.5.12.

ljm  6 hours ago

So this only affects 8.2 are other patches coming?

dhruvagoyal  3 hours ago

there is clearly some drama w.r.t. who takes credit here, 3 companies credited for a single flaw is super odd.

nairboon  8 hours ago

A bit too early for the announced coordinated release, no?

DonHopkins  8 hours ago

Time to restart Apache again!

"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests." -Rasmus Lerdorf

alrenai  7 hours ago

Anyone know if Microsoft updates azure web-app built-in php runtimes fairly quickly in this sort of scenario?

torbengee  7 hours ago

Looks like the upgrade instructions for PHP 8.3 for Fedora 39 and earlier are not working ... yikes.

dataflow  8 hours ago

Is PHP 7 essentially going to be dead and unusable for everyone then? Or will it get fixes?

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?

f311a  7 hours ago

This reminds me of the old days when PHP was such a vulnerable language.

By simply searching for websites that used local includes to load other pages, you could get RCE.

At this point, running webapps in JS workers/sandboxes sounds like a good idea. Vendors take care of patching.

  • dannyw  7 hours ago

    Have a search for V8 RCE/CVEs over the past year.

    • f311a  6 hours ago

      That's why I mentioned vendors. They patch it before announcements.

      Also, sandboxing makes automatic exploitation harder. There is no FS persistence, so some checks simply do not pass.

deanc  7 hours ago

I think there's a lot to learn from the last twenty four hour's events. An absolute nuclear bomb of an exploit affecting every version of PHP back to 2012 (which nobody should be using of course, but I've worked in plenty of environments that are not up to date).

The thing that's annoyed me the most is the speculation and misinformation, filling in the gaps. Folks looked into the php-src and figured out one of the vulnerabilities, starting saying you should disable certain php settings and then core PHP developers on obscure mailing lists hinting this isn't enough.

Given how inexpensive it is for agents to scan popular OSS projects, disclosure needs to be more discrete and you cannot publish fixes to OSS before disclosure. People will be and are watching for this kind of thing already.

lexoj  6 hours ago

While the fix was not published I genuinely thought a quick service rewrite to some other stack (say Go) would make sense as a fix. (Assuming high integration test coverage )

shevy-java  3 hours ago

I have this slight suspicion this was not the last critical PHP apocalypse ... :(

Some web-services are back up again here in central Europe, but some are not, which is very annoying. Kind of surprising to see how much PHP is actually used. Hate it or love it, PHP really is very important still - lots of the web depends on it.

phplovesong  7 hours ago

This is pure gold. A critical vuln like this is such classic lolphp. Luckily you can port away from PHP pretty easily with AI.

ramesh31  8 hours ago

PHP runs literally half the web. Half the web will not apply this patch in any reasonable amount of time (a huge portion will never). This is going to be absolutely catastrophic.

  • xydone  7 hours ago

    The union of hosters which will not update to this patch, and users who have not updated to the past 283762 CVE is literally the same circle. I think that maybe a couple new not infected machines will get infected with a cryptominer - the rest will just get one new miner fighting for resources

    • jacquesm  7 hours ago

      > the rest will just get one new miner fighting for resources

      Hehe. That's funny.

      I can imagine a truce, either on machines ('ok, you take that one') or on cores ('16/8, deal?')

      1 reply →

  • xyst  8 hours ago

    So if I wanted to build a botnet, then it would be very easy ;).

    Infiltrate vulnerable PHP sites. Install backdoor(s). Secure root access. Patch PHP to lock out script kiddies. Let it sit dormant until you need to launch attack

cute_boi  4 hours ago

> 8.1 and earlier Not patched: these versions have reached end of life and will not receive an official fix

I would not recommend using PHP. The PHP team keeps breaking backward compatibility and trying to introduce new features instead of focusing on fixing bugs and hardening the compiler.

teekert  7 hours ago

Doing a...

    docker pull wordpress:fpm && docker image inspect wordpress:fpm --format '{{.Created}}' && docker run --rm wordpress:fpm php --version

... every now and then until that 8.3.35 turns into 8.3.36.

So far, no dice.

varispeed  6 hours ago

Why they can't publish an expoit so people can run it against their own servers to check the impact?

jdw64  7 hours ago

What I've been feeling lately is that security vulnerabilities will inevitably keep being discovered, and I worry whether humans can ever patch all of them.

Capricorn2481  5 hours ago

This is extremely damning for Cloudflare. I had a bunch of clients telling me Cloudflare is all they need to prevent this, and they want to get that on their site instead of upgrading PHP.

I have not seen confirmation Cloudflare is doing anything except playing whack a mole with certain request patterns. PHP Core Devs have been clear you need to upgrade. If this is true, it's disgustingly opportunistic that Cloudflare is using this critical security time to lie to people that they are safe.

Anyone from Cloudflare want to speak to this?

  • cr3ative  5 hours ago

    I'm not from Cloudflare, or particularly a fan of theirs, but they are doing a few things about this, including a new WAF capability: https://blog.cloudflare.com/full-transaction-waf/ and automatic protection for all customers https://blog.cloudflare.com/php-vulnerabilities-waf-protecti...

    These were rolled out before the exploit became public.

    I would wouldn't describe that as damning.

    • Capricorn2481  5 hours ago

      It's great they are doing mitigations, but they admit themselves, in fine print, that this will not protect you from the vulnerability

      Why is word circulating that you can just sign up for Cloudflare and be 100% protected from this? They are burying the leed and trying to get new customers, and it's working.

  • AtNightWeCode  4 hours ago

    When log4j came out CF helped a lot. The rules are called stopgap. A TEMPORARY fix. CF added some for this exploit.

    The old way of doing things like putting old unpatched stuff behind firewalls is pretty much a dead pattern today.

gib444  2 hours ago

Hetzner's control panels are PHP. And they're totally unresponsive. Perhaps people storming to manage their services or submit support requests.

Maybe Hetzner know a company that can help out with extra computer resource...? /s

Useless. My fault for paying peanuts

EGreg  8 hours ago

[flagged]

  • Shank  7 hours ago

    I really do not think anyone should trust a vibe coded repo that launched 1 minute ago as a viable defense for any service.

    • bombcar  7 hours ago

      Yes, you should vibe-code your own instead.

      (Not even joking, if you're going to go hog go whole-hog.)

    • EGreg  7 hours ago

      You're right, you should just leave your PHP totally unprotected.

      I would recommend running this binary as a user that has no access to any files, it can just proxy traffic through a port. I will put that in the README.

      2 replies →

EGreg  8 hours ago

[flagged]

  • julkali  8 hours ago

    Please stop pushing your slop to profit off the situation.

    • EGreg  8 hours ago

      You know, normally I'd be okay with these comments, but in this case you're actively hurting a lot of people by this bullshit. Many people need something other than patching PHP.

      It's free and MIT licensed, open source and it is currently the only alternative to patching your PHP. The "profit" is for people who don't get PWNED today!!!

      Many people can't patch your PHP. If you can't be bothered to even look at the repo, you may want to sit this one out.

      https://github.com/Qbix/proxy

      4 replies →

  • import  7 hours ago

    Hi, your build is failing my friend.

    • EGreg  7 hours ago

      You're right – need to fix the Cosmopolitan build in GitHub actions. On it!

      UPDATE: Just going to ship a Linux binary for now, that's where most hosting is. Almost no one hosts from a MacOS or Windows machine. The Cosmo binary was overkill here.

      2 replies →

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?

    • DonHopkins  7 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.

rvz  7 hours ago

PHP is done.

  • rkozik1989  7 hours ago

    People have been saying this for the past 16 years, but the reality is once a system is in production over time it becomes increasingly risky to replace it. Because over the life of a piece of software you make tons of small fixes, resolve bugs, adding customer-specific functionality, etc. that you'd completely overlook when planning our requirements for a rewrite. Which is a big problem when other systems are dependent on the software operating a specific way i.e. APIs, web services, and so forth. Not to mention the economics of a rewrite also has to make sense. Nobody is going to spend 2-3 years recreating what they already had and get no additional functionality out of it. Certain software basically has to get so bad that literally anything replacing it is better than what came before for replacing it to be the right approach.

    • hn_submit  6 hours ago

      People shouldn't be using PHP. I was shocked some security focused websites are even using it. I just hope there's nothing of value on their servers and that it's not connected to their internal network in any way. In my experience this is almost always the case because it makes maintenance and development easier but effectively exposes your entire organization to the internet.

      That 70% of the internet still uses it is shocking to me. These organizations deserve to get burned badly. Let this incident be a warning to all of them!

      2 replies →

gslepak  7 hours ago

If you're tired of having to upgrade Wordpress, point your agent at this tutorial:

https://blog.okturtles.org/2024/10/convert-wordpress-to-stat...

  • donohoe  7 hours ago

    …or just enable automatic updates.

    • toast0  7 hours ago

      last I looked, automatic updates for wordpress meant letting the web server write to the document root, which may be on the same level of negligence as not updating quickly.

      Plus, wordpress updating isn't going to help you upgrade php.

bitbasher  7 hours ago

So-- if PHP's sourcecode was unavailable (closed source), would this ever have been found? Probably not. Maybe it is safer to be closed source.

  • kstrauser  6 hours ago

    Know how recompilers are porting video games from one platform to another these days? That exact trick works just as well for finding vulnerabilities. Broadly.

    1. Hey LLM, turn this binary into source code.

    2. Hey LLM, see any glaring security issues with this source code?

    • anonymous908213  4 hours ago

      > Know how recompilers are porting video games from one platform to another these days?

      They actually aren't. Most of the claimed cases of "recompilation" are just an emulator packaged into the same binary as the game so you can't tell it's an emulator, or are for projects that already had their source code available (in which case "porting" to WASM is trivial because all of the hard work is done by the people who write your-language-to-WASM compilers, and you just need to do a little bit of work to adjust your toolchain to use it). Everyone just takes slopshit at face value and shares clickbait without actually checking any of the work done. It's infuriating how empowering this software is for liars, honestly.

small_model  7 hours ago

Does anyone use PHP anymore? I assumed it was abandonware

  • CookieCrisp  7 hours ago

    No, the entire world abandoned it when you realized it wasn't the perfect language. The rest of us are just role playing today basically. It's a bit of a lark, kind of like civil war reenactment.

  • openclawuser  7 hours ago

    I see the downvotes and I don't really disagree with you.

    This hurts because my resume has laravel and WordPress on it. I built sooo many sites/apps on it.

    With AI agents, I just can't imagine using PHP anymore unless I'm patching legacy stuff.

    I loved laravel too... WordPress, love hate.

amelius  4 hours ago

Can't we fingerprint the code in github and elsewhere and tell AI labs to not do security reviews on the code unless (A) someone is a legitimate security researcher or (B) someone is the owner of the code.

Yeah it sucks, but the alternative could be worse.