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 5 hours ago | parent | next [-]

This is just Claude output. Did you verify anything or just rehash the links?

▲

mistertrotsky 4 hours ago | parent | next [-]

HN should ban comments that are just Claude output

▲

throawayonthe 4 hours ago | parent | next [-]

https://news.ycombinator.com/newsguidelines.html#:~:text=Don...

▲

whycome 4 hours ago | parent | prev [-]

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 4 hours ago | parent [-]

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 4 hours ago \| parent [-]
		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

▲

bombcar 4 hours ago | parent | prev | next [-]

It's just Claude output of what I've done; the other URL has the basics.

▲

DonHopkins 4 hours ago | parent | prev [-]

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 5 hours ago | parent | prev [-]

[flagged]