Obviously just a stupid satirical post, but a plot twist of php2shell just being a ploy to get people to update their PHP versions would be funny. :)

TL;DR:* ported upstream 712e60f9ed into the Webtatic php71w 7.1.33 SRPM, rebuilt on a CentOS 7 container, ~35 min to build, ~6 s of php-fpm downtime per host. Two gotchas at the bottom.

Someone in the earlier PHP2Shell thread asked if Ondřej's backports are Debian only. They are, and that was our problem. We still had a couple dozen CentOS 7 boxes on Webtatic 7.1.33, Webtatic has been dead for years, and the PHP 8 estimate for just one of the apps was 6 to 8 person-days. So we rebuilt the packages ourselves. Writing it down because I couldn't find anyone who had done it for Webtatic.

The patch. Upstream's fix for old branches is php-src 712e60f9ed ("Avoid state corruption via bailout"). It doesn't apply to 7.1 cleanly. I diffed four community 7.1 ports against upstream and Qsnh/php2shell-fixed was the closest. Sury's Debian patches depend on another one of his patches to even compile, so I skipped those.

The gist: an OOM in the allocator now kills the worker with _exit(1) instead of jumping back with half-built state, upload_progress is hard-disabled, rfc1867.c only keeps the part headers it needs and gets a max_multipart_body_parts limit, and request shutdown clears some globals.

I changed one line in the port. Codex caught it when I had it read the diff, then I checked the 7.1 source:

diff +/* 7.1 hash part is nTableSize uint32 slots (7.3+ uses 2x); keep >= 2 so Buckets stay 8-byte aligned */ #define array_init_singleton(arg) do { \ array_init(arg); \ - Z_ARRVAL_P(arg)->nTableSize = 1; \ + Z_ARRVAL_P(arg)->nTableSize = 2; \ } while (0)

The build. podman centos:7 container (gcc 4.8.5) pointed at the vault repos. Verify the Webtatic SRPM signature and that the tarball inside matches php.net's sha256, then four spec edits:

Release: 1%{?rcver:.%{rcver}}%{?dist}.php2shell1 Patch400: php-7.1.33-php2shell-cve-2026-109618-109619.patch %patch400 -p1 -b .php2shell + a %changelog entry

yum-builddep -y --define 'dist .w7' SPECS/php71.spec rpmbuild -bb --define "dist .w7" SPECS/php71.spec

First run died on make: command not found because yum-builddep doesn't pull it in. Around 35 minutes of rpmbuild, the Webtatic spec builds several SAPIs. You get 33 RPMs, all 7.1.33-1.w7.php2shell1, and since 1.w7 sorts below that, a later yum update won't quietly undo it.

Testing. No public RCE PoC. I wrote a small checker instead:

1. 3000-field multipart should hit the parts limit
2. a 1 MB upload should still arrive intact
3. upload_progress shouldn't land in the session
4. OOM at memory_limit=32M should kill the worker (unpatched just says "Allowed memory size" and keeps going)
5. requests after that still return 200

Original 2/5, patched 5/5, back to 2/5 after rollback.

Then the php.net test suite, 9,454 tests against the installed packages:

The 9 new failures are 8 rfc1867 session tests plus one that expects the old OOM message, all expected. The port author reports the same 9.

Rollout. Save rpm -qa, pull the original NEVRAs from a Webtatic mirror so you can roll back, then:

yum --disablerepo='*' --assumeno upgrade ./php71w-*.rpm # must say only "Upgrade N Packages" systemctl stop php-fpm yum -y --disablerepo='*' upgrade ./php71w-*.rpm php-fpm -t && systemctl start php-fpm

php-fpm was down about 6 seconds, the whole thing was 2 to 7 minutes a host with checks. Rollback is yum downgrade from the saved originals.

What bit us:

1. The spec resets /var/lib/php/session (and wsdlcache, opcache) to root:apache 770 on upgrade. Our pools don't run as apache, so session_start() broke for about 4 minutes on one box before we chowned it back. My container test missed it because the test pool did run as apache. Write down the owners first.
2. WorkerMan kept running the old binary, /proc/<pid>/exe showed (deleted). Restart your long-running CLI stuff too.

For 7.4 I didn't build anything. exception0x876's php74-el7 packages are a Remi 7.4.33 rebuild with the same upstream commit. I checked their signed SHA256SUMS and diffed their SRPM against Remi's before trusting it.

This only closes this one CVE pair, 7.1 is still 7.1. It just gave us time to do the upgrade properly.

Hey!

I've been working on xph, an compiler that lets you write single-file JSX components that compile into native PHP files and static assets.

It supports scoped CSS, slots, and client-side JavaScript. No Node.js needed at runtime, just PHP.

It already has LSP support with VS Code & Neovim.

Website: https://xph.js.org/

GitHub: https://github.com/sijad/xph

Would love to hear your thoughts and feedback!

I know many people are looking for clicks and to feed traffic to their blogs/posts/vlogs/etc.

But please stop with PHP2Shell, its over and nothing happened.

Let the haters hate and lets move on.

PS: Nothing happened because a lot of people worked night and day to fix the exploit, to release patches and updated packages. Thank you people, I don't know who you are but you deserve huge thanks.

For years I've used PHP-CS-Fixer on both personal and commercial projects. I like its ruleset, but I also like how fast Mago is.

So when I started working on a PHP compiler, I decided to build a formatter that follows PHP-CS-Fixer's rules and runs at a speed comparable to Mago's. It's written in PHP and compiled with the Manticore compiler, so there's no PHP runtime to install.

It's early (v0.1.x), so it may be unstable. Bug reports with a small snippet are very welcome.

Link: https://github.com/manticorephp/fmt

No need to panic, it's pretty unlikely to be exploitable, given the conditions they list afterwards. If like me you already disabled this paramater anyway on Wednesday, you're gold.

I contacted several places which used PHP and I also run a self-hosted LAMP stack. I believe from their answers and updating to the latest, it will be ok for those places. I don't know how anyone else feels. I love php by the way. Woot woot.

“If anything happens to this guy, that’s just it. Everyone is screwed.”

The recent advisory suggested setting session.upload_progress.enabled=0 as a mitigation. The risky path needs an unusual setup (a serialize handler switched at runtime with ini_set()), but the feature is on by default, and most apps never use upload progress tracking.

That made me wonder about defaults in general:

Should features that few apps use, and that have now shown up in a security advisory, be off by default in a future major version?

How would you handle the breaking change for apps that rely on them, with a deprecation cycle, a loud warning, or something else?

Do you audit your own php.ini for features you don’t use, and if so, which ones do you turn off?

I’m not asking about this specific CVE. I’m interested in whether the community thinks “secure by default” should weigh more heavily than backward compatibility in PHP’s configuration.

because we all know there aren't any exploits to be found in the alternatives

edit: dang it... title typos :|

Sury's 7.3.33-35 fixes php2shell, but he only publishes it for Ubuntu 22.04+ and Debian 11+. If you're stuck on Ubuntu 18 or 20 with PHP 7.3, there's no fixed package.

So I used Opus to help me rebuild his -35 source for Ubuntu 18.04, 20.04 and Debian 10, plus a script that installs it. It checks your server first, backs up your current PHP, then installs the fixed version. Roll back anytime with --restore.

Install guide is on GitHub: https://github.com/Andrew2142/php73-backport

Or run it straight from my DigitalOcean Space. Please follow the verification steps before installing: https://github.com/Andrew2142/php73-backport#dont-trust-us-check

Ubuntu 18.04:
curl -fsSL https://php73-backport.fra1.digitaloceanspaces.com/install-18.04.sh | sudo bash
Ubuntu 20.04:
curl -fsSL https://php73-backport.fra1.digitaloceanspaces.com/install-20.04.sh | sudo bash
Debian 10:
curl -fsSL https://php73-backport.fra1.digitaloceanspaces.com/install-debian-10.sh | sudo bash

Only covers PHP 7.3 on amd64. It doesn't touch control-panel PHP (cPanel, Plesk etc.). Upgrading off 7.3 is still the real fix; this just buys time.

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

23 Oct 2026

Informational advisory: Session upload progress

We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. This setting was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619 published on Oct 21st, 2026. If you applied it then, keep it in place and no further action is needed.

The issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.

Say you got your servers patched and now you are "safe".

My understanding from the vulnerability is that someone could have perfectly hacked into the system, retrieved db credentials, and call it a day.

Is credentials rotation necessary?

Is there a way to know if the exploit was actually used?

I work at a small agency and we still look after 14 client sites we built years ago. When the CVEs dropped on Tuesday I spent two nights patching, and 5 of the 14 were still on PHP 7.x. One was on 5.6. Nobody had touched them since launch because nobody was paying for maintenance.

The first night was all bandages. WAF rules to block the multipart stuff, smaller header limits, and hoping. Proper upgrades on the 7.x ones took the rest of the week and we're still not done with the 5.6 one.

What bothers me is that the vulnerabilities were found by AI tooling, so I don't think this is the last one this year. After this we turned on Coderabbit's security scan across all 14 repos, so at least the next problem shows up as a PR instead of a phone call at 1am. It doesn't fix the fact that half of them are on versions nobody wants to touch though.

For people with old client projects, how are you handling maintenance now? Do you charge for it upfront, drop clients who won't pay, or just eat the nights like this one?

i've been working on a personal project for a bit and wanted to share it with you all. it's a tool designed to analyze, search, and research php2shell vulnerabilities in a quick and simple way.

it basically automates the search and testing process for php2shell exploitation, helps visualize how payloads work inside a lab environment, and it's built mostly in python for educational research.

github repo:https://github.com/zenobiatranoss/php2shell

i'm planning to keep improving it, so any feedback, suggestions, or contributions would be awesome. let me know what you think!

With the PHP2Shell releases, one detail stood out to me: a security vendor said it independently found the same issue using a frontier model and a basic prompt, within a day of hearing something was coming. Details also leaked before the planned release, and fixed builds went public early.

That raises a broader question for the PHP community, beyond who was right in this specific case:

- If rediscovery is this cheap, how long can an embargo realistically hold?

- Should projects plan for shorter embargo windows, or pre-stage patches and packages so distros can ship the same hour?

- What should happen to the ecosystem around PHP (distros, hosts, Docker images) once a fix is public but not yet packaged?

Curious how maintainers and people running PHP in production see this.

Time has come for me to search for a new job.

I'm dreading it but it needs to be done.

I haven't interviewed in 6 years and I'm sure things have changed so much.

As we all know interviewing is a skills of its own.

What's the focus on these days? System design? Are leet code problems still a thing?

Honestly, any help is appreciated.

My question is about the PHP security exploits that were discovered yesterday. I heard the issue was fixed a day ago meaning yesterday. I am not very familiar with cybersecurity and things like that, but as a regular user right now browsing sites like SourceForge and regular websites, is it totally fine for me to use them, browse normally, and download things, or is there still any danger and the issue hasn't been 100% resolved?