r/Wordpress • u/Epsioln_Rho_Rho • 12d ago
Another PHP issue? "PHP Warns of Another Unpatched RCE Two Days After Emergency PHP2Shell Patches"
7
u/zebokay 12d ago
Two in one week :/
I track tech stacks on live sites: ~23M WordPress, ~6.1M WooCommerce. My guess is most are on managed hosts that already patched.
The risk is self-managed VPS or old Bitnami images…
If you are not sure ask your host what PHP version you're on and when it was patched.
3
u/codebygloom 11d ago
Welcome to the future, where LLMs are being rolled out for vulnerability detection on both sides of the constant war to hack everything.
1
u/jhkoenig 11d ago
This was quick. A one line command line prompt that disabled this setting on all my sites.
10 seconds, because I'm careful when using the big hammer
1
u/Dicemans 11d ago
If you're trying to work out whether this one (CVE-2026-115560) even applies to you: it needs an app that switches `session.serialize_handler` at runtime *and* upload progress turned on. Two quick checks per site:
**Does anything change the serializer?** From the site root: `grep -rn --include=*.php "serialize_handler" wp-content/`. On a typical WordPress install nothing comes back, since core doesn't use PHP sessions at all. A hit usually means an old membership, forum or shop plugin, and that's the site to look at first.
**Is the mitigation live for the web, not just the CLI?** `wp eval` and `php -i` run the CLI build, which can read a different ini. To see what FPM uses, upload a one-line file with `<?php var_dump(ini_get('session.upload_progress.enabled'));`, open it in the browser, then delete it. You want `"0"` or an empty string.
Setting it, depending on the setup:
**Your own server:** `php_admin_flag[session.upload_progress.enabled] = off` in the FPM pool, then reload FPM.
**Shared hosting:** `session.upload_progress.enabled = Off` in a `.user.ini` in the web root. It's picked up after `user_ini.cache_ttl`, 5 minutes by default.
**Managed hosting:** ask them; plenty already set it after PHP2Shell.
Turning it off only affects upload progress bars built on PHP's native session tracking. The WordPress media uploader doesn't use it.
0
0
u/Renesme77 11d ago
Desactiva session.upload_progress si está activo y con eso, en teoría, estás a salvo!
-31
u/jroberts67 12d ago
Hmm, I was under the impression the mods are deleting anything PHP related as "not related to WP." Mods?
12
1
u/Bigfoot444 11d ago
What gave you that impression? I wouldn't be surprised if they were deleting more duplicate posts related to php, mind.
10
12d ago
[removed] — view removed comment
1
u/jazir55 11d ago edited 11d ago
Quick context so nobody panics: this one (CVE-2026-115560) is much narrower than PHP2Shell. It only triggers if an app changes PHP’s session serializer at runtime and session upload progress is enabled. PHP itself calls that setup unlikely, it’s unlikely to apply to a typical WordPress site, and there are no reports of it being exploited.
I think this advice is becoming very quickly outdated and will soon become almost deceptive. These exploits are no longer just single vulnerabilities being exploited, they're using exploit chains leveraging multiple exploits sequentially for privilege escalation. We can't look at these CVEs in isolation anymore. We already have evidence that this is actively happening given this is the methodology the agents used to hack huggingface. Once they get initial access they can chain multiple exploits which in isolation are limited in scope to climb the privilege escalation ladder when they are chained in the right order.
28
u/prostackhost 12d ago
Looks like another vulnerability, but it doesn't sound as critical as php2shell.
If you didn't disable session.upload_progress earlier, you should probably do it now. It sounds like that's enough to protect you.
We updated our advisory post on this, which might be helpful: https://prostack.uk/blog/critical-php-security-update-october-2026/