469 points tuyuri 1 hour ago 194 comments
bombcar 1 hour ago | parent
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 1 hour ago | parent
mistertrotsky 1 hour ago | parent
whycome 1 hour ago | parent
bombcar 1 hour ago | parent
dwedge 54 minutes ago | parent
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 1 hour ago | parent
DonHopkins 1 hour ago | parent
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 1 hour ago | parent
k1kingy 1 hour ago | parent
longwave 1 hour ago | parent
https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
dstu 47 minutes ago | parent
https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
tux3 1 hour ago | parent
https://github.com/php/php-src/security/advisories/GHSA-w8hw...
https://github.com/php/php-src/security/advisories/GHSA-6wmf...
simias 1 hour ago | parent
Well off to a good start here.
fock 1 hour ago | parent
Maxious 1 hour ago | parent
> Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
CodesInChaos 28 minutes ago | parent
charcircuit 1 hour ago | parent
What everyone is looking for.
ytxm 1 hour ago | parent
> 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 1 hour ago | parent
Is it perhaps a bit misleading, and only means that there's no branch containing that commit?
abbbi 1 hour ago | parent
Instantnoodl 1 hour ago | parent
technoknol 1 hour ago | parent
abbbi 1 hour ago | parent
https://buildd.debian.org/status/package.php?p=php8.2&suite=...
kps 1 hour ago | parent
Pxtl 1 hour ago | parent
bstsb 1 hour ago | parent
bombcar 1 hour ago | parent
awake2death or something
cowlevel 1 hour ago | parent
Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?
antiloper 1 hour ago | parent
nr378 1 hour ago | parent
https://www.wiz.io/blog/php2shell-php-rce
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 1 hour ago | parent
trollbridge 1 hour ago | parent
ImJamal 1 hour ago | parent
dspillett 1 hour ago | parent
trollbridge 1 hour ago | parent
dspillett 53 minutes ago | parent
12837615 1 hour ago | parent
LoganDark 1 hour ago | parent
chinathrow 1 hour ago | parent
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 1 hour ago | parent
Edit: was looking Wiz post when citation was from OpenAI
chinathrow 1 hour ago | parent
janmo 1 hour ago | parent
hdgvhicv 1 hour ago | parent
dspillett 1 hour ago | parent
nolok 1 hour ago | parent
rob 1 hour ago | parent
kijin 47 minutes ago | parent
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 40 minutes ago | parent
unethical_ban 33 minutes ago | parent
lee_ars 27 minutes ago | parent
anon1642 1 hour ago | parent
I’d press go too - if something this big was known to some but not all…
We’ll all get through together
giancarlostoro 59 minutes ago | parent
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 53 minutes ago | parent
novafacing 44 minutes ago | parent
ndiddy 47 minutes ago | parent
tetraodonpuffer 1 hour ago | parent
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 1 hour ago | parent
polishdude20 1 hour ago | parent
charcircuit 1 hour ago | parent
pixl97 1 hour ago | parent
hobofan 57 minutes ago | parent
akersten 1 hour ago | parent
phplovesong 40 minutes ago | parent
PHP will always be the slop before AI.
esquire_900 1 hour ago | parent
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 1 hour ago | parent
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 1 hour ago | parent
lokar 1 hour ago | parent
justinhj 59 minutes ago | parent
wat10000 54 minutes ago | parent
bombcar 1 hour ago | parent
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 1 hour ago | parent
i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.
fock 46 minutes ago | parent
dannyw 57 minutes ago | parent
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 50 minutes ago | parent
dannyw 1 hour ago | parent
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.
dspillett 57 minutes ago | parent
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 39 minutes ago | parent
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.
consp 1 hour ago | parent
Boy, do I hate these PR websites masquerading as vulnerability reports. It's slop all the way down with these companies.
Pxtl 1 hour ago | parent
wildmXranat 48 minutes ago | parent
It's like slop for infosec markters
pluc 45 minutes ago | parent
EGreg 1 hour ago | parent
https://news.ycombinator.com/item?id=50181752
https://github.com/Qbix/proxy -- open source MIT licensed, I made github actions compile it as a Cosmopolitan binary so it can work across many operating systems (thanks Justine)
I wrote it so I could deploy it myself on our old nginx + php-fpm setups, thought I would share. It should work with all top servers (nginx, apache, caddy etc)
julkali 1 hour ago | parent
EGreg 1 hour ago | parent
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.
klausa 1 hour ago | parent
bombcar 1 hour ago | parent
kalleboo 1 hour ago | parent
antiloper 1 hour ago | parent
EGreg 1 hour ago | parent
import 1 hour ago | parent
EGreg 1 hour ago | parent
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.
DJBunnies 36 minutes ago | parent
Nobody should trust this.
petecooper 1 hour ago | parent
dstu 1 hour ago | parent
janmo 1 hour ago | parent
Neil44 1 hour ago | parent
I realised that my linode and ovh vm's point at local mirrors not direct to ubuntu, I guess that's why the delay
trollbridge 1 hour ago | parent
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
Amsozzer 1 hour ago | parent
trollbridge 1 hour ago | parent
Amsozzer 1 hour ago | parent
rob 1 hour ago | parent
Trufa 50 minutes ago | parent
It feels like many times PRs could just be that.
DonHopkins 1 hour ago | parent
"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
bombcar 1 hour ago | parent
cholmon 1 hour ago | parent
aftergibson 1 hour ago | parent
bombcar 1 hour ago | parent
sixhobbits 52 minutes ago | parent
sct202 35 minutes ago | parent
rvz 1 hour ago | parent
rkozik1989 1 hour ago | parent
Xyrren 1 hour ago | parent
cpncrunch 37 minutes ago | parent
f311a 1 hour ago | parent
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 1 hour ago | parent
ckbkr10 1 hour ago | parent
jdw64 1 hour ago | parent
torbengee 57 minutes ago | parent
basilgohar 57 minutes ago | parent
danso 41 minutes ago | parent
nicce 27 minutes ago | parent
julian9499 55 minutes ago | parent
theturtletalks 53 minutes ago | parent
spenvo 48 minutes ago | parent
jMyles 39 minutes ago | parent
andrin 28 minutes ago | parent
Edit: Seems like GitHub has issues with merging PRs: https://github.com/docker-library/official-images/pull/22541
phplovesong 41 minutes ago | parent
nairboon 38 minutes ago | parent
and not the github mirror?
bitbasher 34 minutes ago | parent
tikotus 31 minutes ago | parent
tovve 30 minutes ago | parent
redox99 25 minutes ago | parent
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.
deanc 31 minutes ago | parent
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.
alper 25 minutes ago | parent