News for hackers. Stuff that matters.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by lorenzbrun on Wednesday October 21, 2026 @01:44AM (#50176518)
I'm pretty sure this is not the vulnerability that's still officially under embargo. I think I found the the two actual vulnerabilities (both UAFs and similar). I patched my own stuff (at least I hope so) and am mirroring traffic to a detector, very interested to see when I get the first hits. Unless I see actual exploit attempts or a full leak I think I'm not going to publish my patches yet.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by idlewords on Wednesday October 21, 2026 @02:46AM (#50176932)
I guess the future is people arguing in comments whether a high-severity vulnerability is the one under embargo, or one of various unrelated devastating bugs discovered when people got wind of the embargo and pointed their AI agents at the codebase.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by SSLy on Wednesday October 21, 2026 @03:18AM (#50177161)
the future is now, eh.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by InvisibleUp on Wednesday October 21, 2026 @01:37AM (#50176473)
This may be, according to one of the PHP devs, a completely unrelated exploit. See https://phpc.social/@Girgias/117476477429221001. Seems the best stopgap is SELinux or AppArmor.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by charcircuit on Wednesday October 21, 2026 @01:48AM (#50176546)
You misread. He is saying that the multipart UAF vulnerability part of the overall exploit can't be fixed by session.upload_progress.enabled = off or any other ini option for that matter.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by 4ndrewl on Wednesday October 21, 2026 @02:44AM (#50176922)
Which is also what tfa says btw
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by iambateman on Wednesday October 21, 2026 @01:32AM (#50176445)
I turned the server off on our app until this storm is over.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by tosti on Wednesday October 21, 2026 @01:53AM (#50176595)
Yeah, the circuit breaker is the best firewall!
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by lionkor on Wednesday October 21, 2026 @01:33AM (#50176459)
Someone uses Claude to role play as a hacker... Yikes
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by Mooty on Wednesday October 21, 2026 @01:59AM (#50176629)
If you use Nginx, you can temporarly block the subject by disallowing multipart sendings to PHP. This is quite a problem for a lot of forms, but way better that being hacked.

Here is an Nginx patch : if ($http_content_type ~* "multipart") { return 403; }

You can also turn of session progress in php.ini as mentionned but that does not seem to cover every cases : session.upload_progress.enabled = Off

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by Mooty on Wednesday October 21, 2026 @02:22AM (#50176763)
After digging a little in the PoC code (here https://jackalsyn.com/posts/php-up-2026.html) I'm quite confident it's not a completely working one.

It assumes PHP frees the upload progress data when it reloads the session. But PHP 8.4 (the one we use is 8.4.24, i don't know for other versions) calls Z_TRY_ADDREF(progress->data) to keep that data alive. The fake function call also seems to contain invalid fields.

This makes me question this particular PoC, not the official PHP security warning. I have not reproduced the exploit, so this is a concern based on reading the code, not proof that the real vulnerabilities cannot be exploited.

But anyway the CVE still exists, and the exploitation is tied to multipart, disabling it seems the best thing you can do now without shutting everything down.

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by 80fj0348i on Wednesday October 21, 2026 @01:20AM (#50176375)
Previously submitted with a much better source: https://news.ycombinator.com/item?id=50172041
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by tech234a on Wednesday October 21, 2026 @01:26AM (#50176412)
This one claims to actually be an exploit. The other was an announcement from PHP without details.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by lifeisloving on Wednesday October 21, 2026 @01:29AM (#50176423)
How is this a better source, the current post is a PoC? This is just a warning...

You're not even reading the things you're saying are worse, and reccomending things that arent what you say they are (because you didnt read those either)

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by ffritz on Wednesday October 21, 2026 @02:24AM (#50176776)
Any idea if Cloudflare in front of an unpatched site would prevent this? They did 2 updates already today to their managed rulesets but are not specifying what.

https://developers.cloudflare.com/waf/change-log/changelog/

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by AdamTReineke on Wednesday October 21, 2026 @02:26AM (#50176800)
https://x.com/dok2001/status/2112702593705312467

"We got you covered" - Dane Knecht (Cloudflare CTO)

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by eurleif on Wednesday October 21, 2026 @03:23AM (#50177188)
Now deleted, and replaced with: https://x.com/dok2001/status/2112802620029223193

"Cloudflare has protections in place for known exploit payloads. There will be more variations to come and the only way to fully protect your site is to update php once released."

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by mopsi on Wednesday October 21, 2026 @02:29AM (#50176818)
A little too vague for my comfort.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by indigodaddy on Wednesday October 21, 2026 @02:52AM (#50176980)
CF in front can mess about with L7?
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by minitech on Wednesday October 21, 2026 @03:13AM (#50177125)
Yes? How did you think Cloudflare and other WAFs worked?
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by honeybadger1 on Wednesday October 21, 2026 @06:39AM (#50178688)
A WAF is primarily working at L7.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by Hamuko on Wednesday October 21, 2026 @02:28AM (#50176806)
I think putting my PHP site behind Cloudflare would be the least I would do if I wanted to keep it online before PHP can be patched. The other alternative is trying to block multi-part uploads before they reach PHP.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by mklepaczewski on Wednesday October 21, 2026 @05:24AM (#50178009)
Make sure to create CF tunnel to your server and to reject all traffic frin other sources, or to accept traffic only from known CF ips. Otherwise, you're still exposed, even if CF WAF works.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by nilslindemann on Wednesday October 21, 2026 @02:52AM (#50176983)
"Posting, captcha, sign-in and other dynamic pages are offline while we apply an urgent PHP security update" - https://4chan.org/
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by dataflow on Wednesday October 21, 2026 @01:53AM (#50176590)
If I have a PHP site that doesn't require uploads, how exactly do I disable enough of multipart/form-data POST handling in PHP to mitigate this?
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by bulatb on Wednesday October 21, 2026 @02:09AM (#50176676)
Block it at your web server before it reaches PHP. Ctrl+F "nginx" or ".htaccess" in this thread for configs.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by dataflow on Wednesday October 21, 2026 @02:52AM (#50176986)
Got it, thank you!
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by e12e on Wednesday October 21, 2026 @01:51AM (#50176575)
Can anyone get the sha to match the download? (Given as a29d640e0481ff64a39541faeeeec0f998ecd18fb692816e75a6bcfa0f683017 in TFA)
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by synack on Wednesday October 21, 2026 @01:43AM (#50176509)
It’s use-after-free where the “use” is execution of arbitrary code. Yeah, that’s pretty bad.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by 6510 on Wednesday October 21, 2026 @01:41AM (#50176501)
.htaccess

    <If "req('Content-Type') =~ /multipart/i">
        Require all denied
    </If>
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by secabeen on Wednesday October 21, 2026 @03:10AM (#50177107)
This appears to have global effect if placed in a <Location> block in the root apache2.conf:

  # PHP 20261020 Remediation (Global)
  <Location />
    <If "req('Content-Type') =~ /multipart/i">
        Require all denied
    </If>
  </Location>
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by TekMol on Wednesday October 21, 2026 @01:37AM (#50176479)
What about servers that run PHP from the Debian repos?

How fast will the repos be updated?

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by euph0ria on Wednesday October 21, 2026 @01:55AM (#50176599)
On Reddit they stated that Ondrej is aware of the issue
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by hparadiz on Wednesday October 21, 2026 @02:09AM (#50176678)
Announcing this thing and then putting an embargo on the fix for 24 hours is by far the most irresponsible thing internals has ever done and I have seen them do some insane shit in the past 20 years.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by kalleboo on Wednesday October 21, 2026 @02:58AM (#50177033)
It may have made sense when finding exploits required some skill and time so 24 hours would be safe enough but now when anyone can just point an LLM at it...
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by hparadiz on Wednesday October 21, 2026 @03:08AM (#50177092)
The POC was already out on Sunday apparently. When they announced it they made everyone go looking for it. In the before times even someone with decent cybersecurity and hacking experience might not be able to weaponize a POC. Today anyone can weaponize it immediately.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by shevy-java on Wednesday October 21, 2026 @01:29AM (#50176425)
That website looks weird - was it AI coded?

It is visually interesting but also annoying. I hate to admit it, but as I grow older, I may get dumber and I much prefer simplicity at all times.

As for PHP: it also is a bit weird how programming languages have not yet all fixed existing bugs. Has not AI been used to find bugs or assumed bugs? Why are bugs found in old code still?

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by redox99 on Wednesday October 21, 2026 @01:32AM (#50176452)
Why would they hand code a website for an exploit that they probably found 15 minutes before and will be fixed in a few hours? The copy should have been better though.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by eviks on Wednesday October 21, 2026 @02:17AM (#50176728)
Because it takes less effort to paste text with basic readable formatting than doing this awfulness
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by xaksnTMu2 on Wednesday October 21, 2026 @01:39AM (#50176491)
Well Heartbleed and Shellshock had nice looking sites so we kindoff expect better?
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by redox99 on Wednesday October 21, 2026 @01:47AM (#50176537)
They had more time to prepare
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by nargek on Wednesday October 21, 2026 @02:57AM (#50177022)
That's pure unreviewed slop
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by drum55 on Wednesday October 21, 2026 @01:23AM (#50176400)
The text of this is basically unreadable, any amount of human authorship would be better.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by groestl on Wednesday October 21, 2026 @01:36AM (#50176469)
It's things like "under the attacker's feet" which completely throw me off. While trying to parse the text, my brain tries to imagine a surprised hacker.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by pfannkuchen on Wednesday October 21, 2026 @01:42AM (#50176505)
LLM or Engrish? Reminds me of “thumb rule”.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by frevib on Wednesday October 21, 2026 @01:43AM (#50176511)
It reads like the average PR summary I had to review every day. ‘Had’, because I stopped doing that after being blessed by LGTM https://m.youtube.com/watch?v=3TNpOD6bov8&pp=ygUEbGd0bQ%3D%3...
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by lifeisloving on Wednesday October 21, 2026 @01:56AM (#50176605)
Yeah but this AI music is worse than any AI produced code. They're both awful but I really lose all respect for people who think these Sumo songs sound good. Wow I hate that AI musician voice so much.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by Yokohiii on Wednesday October 21, 2026 @01:47AM (#50176540)
It really reads like it was passed 3 times through Claude.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by raverbashing on Wednesday October 21, 2026 @02:19AM (#50176746)
I'd say pass through any other AI that doesn't talk like someone filled with self-importance
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by shevy-java on Wednesday October 21, 2026 @01:29AM (#50176431)
I just wrote almost the same thing (I start to write my comments before I read what others say, so that it is not influenced directly what I write). I am glad to come to the same conclusion - this website is both visually interesting as well as very annoying.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by altmanaltman on Wednesday October 21, 2026 @01:40AM (#50176497)
The font is terrible on mobile, cannot tell then difference between a comma and a fullstop at all
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by Davidzheng on Wednesday October 21, 2026 @01:24AM (#50176405)
yeah agreed.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by fwlr on Wednesday October 21, 2026 @02:02AM (#50176646)
I can literally feel my eyes physically defocusing trying to read this, and I can’t help but conclude that, at a level below conscious thought, my brain is trying to defend itself from AI-generated text. Perhaps it is more of a cognitopoison than I explicitly knew.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by coatmatter on Wednesday October 21, 2026 @02:23AM (#50176765)
Ctrl-Alt-R for reader view in Firefox, not that it makes the whole thing much more interesting to look at - we'll forget about it all soon enough anyway. Don't forget to tweak the default settings for reader view for a better experience.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by viccis on Wednesday October 21, 2026 @01:40AM (#50176495)
>Steal Everything

>Leave Nothing

Cringe larping skiddie nonsense

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by himata4113 on Wednesday October 21, 2026 @01:32AM (#50176446)
Man, my experience with php was never good. Every php project I've encountered eventually had a monero miner infecting the machine as www-data user.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by AndroTux on Wednesday October 21, 2026 @02:30AM (#50176827)
Maybe that’s because you’ve only worked with WordPress with tons of unpatched plugins.

Every programming language has security vulnerabilities. PHP doesn’t have any more than others.

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by minitech on Wednesday October 21, 2026 @02:46AM (#50176943)
> PHP doesn’t have any more than others.

Yeah it does. Part of it is being a popular starter language before people know what they’re doing, but a lot of it is legitimately terrible language[1] and API design, especially in older versions. It also has CVE-2026-109618, a type of vulnerability many languages aren’t even capable of having (since it wouldn’t be part of the language, and the library that implemented the equivalent would only be present when necessary and usually not written in C - with some exceptions).

[1] People have already covered this in depth, but here’s a lesser-mentioned taste: https://web.archive.org/web/20261017012819/https://www.php.n... (one section, btw)

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by AndroTux on Wednesday October 21, 2026 @06:16AM (#50178478)
> but a lot of it is legitimately terrible language[1] and API design

Unlike well-thought-out languages like JavaScript, of course.

What's the saying? A programming language is either bad, or no one uses it. Discussions about flavors of bad in well-established programming languages are a waste of time.

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by minitech on Wednesday October 21, 2026 @10:20PM (#50190379)
I forget making the claim that JavaScript was a well-thought-out language. But yes, I can see how discussing programming language and library design/implementation, as or with the type of person who trots out trite thought-terminating clichés, could be a waste of time.
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by himata4113 on Wednesday October 21, 2026 @06:05PM (#50188324)
unfortunately php is mosty ...insert forum here...

hell even vanilla xenforo was getting compromised all the time, sure there's smaller frameworks and various government institutions using php, but it has many of the same downfalls that mixing server and client code has, the worst offender that comes to mind that enabled many of these bad practices is next.js

Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by hemlock4593 on Wednesday October 21, 2026 @06:47AM (#50178761)
Disabled everything except GET requests and hope it holds until 2pm
Re:PHP session.upload_progress heap UAF (CVE-2026-109618 / -... by consocio on Wednesday October 21, 2026 @12:38PM (#50183795)
https://github.com/consocio/php2shell-audit/ GLM 5.3 just wrote it to audit all my php sites. I hope it is useful to you

reply