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)

Today's PHP security release, and how we're strengthening security - https://smackernews.com/item/50182987 HN - Oct 2026 (114 comments)

PHP2Shell: AI uncovers critical RCE in PHP - https://smackernews.com/item/50180836 HN - Oct 2026 (146 comments)

PHP session.upload_progress heap UAF (CVE-2026-109618 / -109619) - https://smackernews.com/item/50176077 HN - Oct 2026 (61 comments)

Security advisory: Critical remote code execution vulnerabilities, update now - https://smackernews.com/item/50172041 HN - Oct 2026 (631 comments)

Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming - https://smackernews.com/item/50167754 HN - Oct 2026 (60 comments)

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

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

https://github.com/php/php-src/security/advisories/GHSA-w8hw...

https://github.com/php/php-src/security/advisories/GHSA-6wmf...

https://wpenginestatus.com/incidents/969801

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

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.

  # 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

What everyone is looking for.

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.

"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

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"

https://www.youtube.com/watch?v=lfEtbrz4-zY

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

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.

https://www.cisa.gov/news-events/alerts/2026/10/21/critical-...

Now are available in the php-src github

and not the github mirror?

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

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

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

https://github.com/Qbix/proxy

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.

https://www.php.net/archive/2026.php#2026-10-20-1

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?

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

Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?

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.

made it in time hopefully

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.

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

So far, no dice.

apt upgrade

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

Useless. My fault for paying peanuts

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.

Yeah it sucks, but the alternative could be worse.

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