First screen, captured 5 days ago.

PHP session.upload_progress heap UAF (CVE-2026-109618 / -109619)

What HN thinks

Half the thread is patching servers in a panic, the other half is critiquing the exploit page's prose.

Block multipart at the web server
Until PHP ships a fix, the practical stopgap is to reject multipart requests in nginx or Apache, since the ini setting alone doesn't cover every case. Some went further and allowed only GET requests or shut their servers off.
The writeup reads like AI slop
Many found the exploit site's text and font unreadable and suspected it was LLM-generated. One commenter also doubted the PoC works as written on PHP 8.4.
A 24-hour embargo is reckless now
Announcing the bug and then holding the fix for a day invites anyone with an LLM to go hunting for it and weaponize it quickly.

Consensus: Most agree the multipart handling is the attack surface and that blocking it before requests reach PHP is the best mitigation until patches land.

Recommended in the comments

Cloudflare WAF ↗ (service): Its managed rules reportedly block known exploit payloads, though you need to lock the origin to Cloudflare's IPs or a tunnel.
AppArmor (tool): One commenter suggested it, alongside SELinux, as a stopgap to limit damage from exploitation.
SELinux (tool): One commenter suggested it, alongside AppArmor, as a stopgap to contain a compromised PHP process.