I'd put a bigger warning next to memory_limit=-1. It's easy to copy that as a fix and forget you've removed PHP's per-request memory cap. The PHP advisory also calls for request-size limits at the frontend. That section needs to read as a temporary workaround, not "change these settings and you're patched."
AI Application Engineer · Node.js & PHP · LLM tool calling, MCP, SSE & payments. I build WooCommerce speed fixes, Stripe billing and AI features at jeemmo.com
Good, practical write-up. One thing I learned patching my own server this week: on Ubuntu the fix was already sitting in the security repo (backported into the distro's 8.5.4 package) before I installed it. Nothing applies it unless unattended-upgrades is on. So php -v still saying 8.5.4 isn't proof you're unpatched; check the package changelog for the CVE IDs instead. It was mod_php too, so afterwards I also searched the access logs for phpinfo probes and any new .php files since the leak. Nothing found, but worth ten minutes.
Former Java engineer turned Ruby engineer who is trying to understand Ruby and Rails, MacOS and a lot of other things. Worked at Flywheel, FNBO, ACI Worldwide.
This is the write-up most WordPress site owners actually need. Pointing people to Site Health instead of SSH makes it usable for folks who never touch a terminal.
Two gotchas worth adding:
Managed hosts and distro packages often backport security fixes without changing the version string. A site can show 8.3.x below 8.3.36 and still be patched. If the version looks old, check the host's changelog or ask support before panicking.
The PHP version on the command line is not always the one serving the site. php -v over SSH can report the CLI binary while PHP-FPM runs a different build. Site Health (or a phpinfo() page you delete right after) shows the one that matters.
The table with 8.1 and older getting no release is a good nudge for anyone still on an old branch.
Timely writeup. One thing worth adding for shared hosting users: ask the host for the patched build, not just the PHP version number. Distros often backport the fix without bumping the version, so the Site Health screen can show a scary number that is already patched.
Former Java engineer turned Ruby engineer who is trying to understand Ruby and Rails, MacOS and a lot of other things. Worked at Flywheel, FNBO, ACI Worldwide.
Thanks, Christine! One useful check on shared hosting is asking for the package changelog entry for the CVE. It confirms a backported fix even when the version number still looks old.
Custom software & AI development company. We build production-ready AI integrations, mobile apps, and web platforms for businesses that want real results. lycore.com
Worth stressing for WordPress owners that updating plugins and themes does nothing here, because the flaw is in the PHP engine itself and not in any WordPress code. Also check the less obvious PHP on your estate: a marketing site on old hosting, phpMyAdmin, or a vendor appliance that bundles its own runtime tends to get missed in inventories. On shared hosting where you can't pick the version, the host's own notice about the fixed builds is the thing to look for.
Good catch on the bundled runtimes - those are the boxes that never show up in a plugin audit. One more layer to the inventory: some installed PHP branches no longer receive security fixes at all, so on those 'update' is not an available answer, only upgrade or retire. php.net's supported-versions page is the source of truth for which branches still get fixes, and it changes every December. Worth keying the inventory off that list rather than off 'is there a patch for this one CVE', because an engine-level flaw on an end-of-life branch means the exposure outlives this week's news cycle.
The "updating WordPress won't fix it" point deserves its own paragraph in every client email this week, because that is the update everyone will think they already did. The version that works with non-technical site owners: your site runs on WordPress, WordPress runs on PHP, and PHP is the layer with the bug, so the fix is on the server, not in the admin panel. For agencies with a fleet: wp-cli across installs gives you the version list in an afternoon, and clients remember who told them first.
We're a place where coders share, stay up-to-date and grow their careers.
I'd put a bigger warning next to
memory_limit=-1. It's easy to copy that as a fix and forget you've removed PHP's per-request memory cap. The PHP advisory also calls for request-size limits at the frontend. That section needs to read as a temporary workaround, not "change these settings and you're patched."Good, practical write-up. One thing I learned patching my own server this week: on Ubuntu the fix was already sitting in the security repo (backported into the distro's 8.5.4 package) before I installed it. Nothing applies it unless unattended-upgrades is on. So
php -vstill saying 8.5.4 isn't proof you're unpatched; check the package changelog for the CVE IDs instead. It was mod_php too, so afterwards I also searched the access logs for phpinfo probes and any new .php files since the leak. Nothing found, but worth ten minutes.Thanks for the example, and thanks for sharing what you learned.
This is the write-up most WordPress site owners actually need. Pointing people to Site Health instead of SSH makes it usable for folks who never touch a terminal.
Two gotchas worth adding:
php -vover SSH can report the CLI binary while PHP-FPM runs a different build. Site Health (or a phpinfo() page you delete right after) shows the one that matters.The table with 8.1 and older getting no release is a good nudge for anyone still on an old branch.
Timely writeup. One thing worth adding for shared hosting users: ask the host for the patched build, not just the PHP version number. Distros often backport the fix without bumping the version, so the Site Health screen can show a scary number that is already patched.
Good call Rishabh! Thanks for sharing.
Thanks, Christine! One useful check on shared hosting is asking for the package changelog entry for the CVE. It confirms a backported fix even when the version number still looks old.
Worth stressing for WordPress owners that updating plugins and themes does nothing here, because the flaw is in the PHP engine itself and not in any WordPress code. Also check the less obvious PHP on your estate: a marketing site on old hosting, phpMyAdmin, or a vendor appliance that bundles its own runtime tends to get missed in inventories. On shared hosting where you can't pick the version, the host's own notice about the fixed builds is the thing to look for.
Good catch on the bundled runtimes - those are the boxes that never show up in a plugin audit. One more layer to the inventory: some installed PHP branches no longer receive security fixes at all, so on those 'update' is not an available answer, only upgrade or retire. php.net's supported-versions page is the source of truth for which branches still get fixes, and it changes every December. Worth keying the inventory off that list rather than off 'is there a patch for this one CVE', because an engine-level flaw on an end-of-life branch means the exposure outlives this week's news cycle.
The "updating WordPress won't fix it" point deserves its own paragraph in every client email this week, because that is the update everyone will think they already did. The version that works with non-technical site owners: your site runs on WordPress, WordPress runs on PHP, and PHP is the layer with the bug, so the fix is on the server, not in the admin panel. For agencies with a fleet: wp-cli across installs gives you the version list in an afternoon, and clients remember who told them first.