Printable View
I'm sure you're all on top of the PHP situation that's been all over the news in the past 24 hours. If you're not up to speed then there's details here: https://www.ncsc.gov.uk/news/critica...-affecting-php
I get the feeling though that we're just at the very start of this and AI is going to be finding vulnerabilities at an alarming rate as we move forward. The era of perpetual fire-fighting and patching could be upon us. Stay safe everyone.
They did not publish a single version number which is the wrong way to talk about a vulnerability although they did link to the answer.
Answers for that here
https://www.php.net/index.php
I hope cpanel and cwp make sure the fixes and updates work.Quote:
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Rick
Universal4
To add, it does look like the latest version of CWP (control web panel) does support the higher versions of php, at least until php 8.5.9
/edited to add CWP version 1.20 does already support up to php 8.59 (although I feel better about updating all the linux libraries just in case you have not updated CWP in a month or more)
This will allow the selector on a per site basis and how cwp gets it together to allow the root (or main) php to be updated as well.
Have not had a chance to double check cpanel yet. Guessing they either have already or will have updates in place shortly.
I have put feelers out with a few other tech's as I know this is something that a number of members will want to monitor.
Rick
Universal4
A few guys have asked me to update when possible.
What I have found so far is that CWP version 1.20 does not allow for the patched versions of php.
After yum update/dnf update etc updating all the libraries etc cwp does not update by itself. (tried with both AlmaLinux 8 and 9)
Not sure of the outcome of having auto updates turned on for cwp itself, I usually keep that turned off so it doesn't accidentally break anything without a backup etc.
You can however force the upgrade of cwp with a shell script and after that, quick reboot and sure enough the 8.5.12 was available and am rebuilding one php build now.
After this is done with a reboot your cwp should be on 1.21 and allow for the higher php versions.Code:sh /scripts/update_cwp
Keep in mind you might want the cgi and the fpm versions built so you can then change each site independently depending on needs.
As a number of guys at the cwp forum said, this does not update the internal php, but at least this will take care of the php on sites, which is likely the biggest attack vector anyway.
Thanks a bunch to the guys that dropped me a mail and pushed me to read up on this more, anyone needs a hand drop me a line.
Rick
Universal4
OK,
Got it to run using 8.5.12 fpm version as the build usually fails without a few minor changes. (from inside the cwp panel)
Happy to help if anyone needs it, I admit it took me rebuilding php 2 or 3 times looking through the logs to figure it out.
If anyone knows whether cpanel already has this fixed, let us know thinking they will quickly.
Again, thanks for the additional input from others, in case other members need extra input.
Rick
Universal4
Good work Rick. I think we all need to be prepared for significant upheaval over the next few days, weeks and months. This tweet was from the Anthropic security chief Jason Clinton overnight: https://x.com/JasonDClinton/status/2113325263157395456
Quote:
as bad as things have gotten in the past 4 days, they are going to get a lot worse before they get better. security leaders, never let a crisis go to waste: please go to your boards and ask for help right now. not for ai, for the basics. (we need to hold on for ~18 months.)
Thanks to Rick for pinning down the patched versions, because that detail matters more than the headline panic. For anyone running affiliate sites, the first practical step is not just to update once, but to inventory every site and confirm which PHP version is actually running on each one, not just what the control panel claims is available. I have seen cases where a panel update left an older version still serving a live site, so checking the live environment after the change is essential.
The second point is sequencing. Take a backup, test the patched version on a staging copy if you can, and watch for plugin and theme compatibility problems, especially on older WordPress builds. A rushed PHP jump that breaks a review table, a bonus feed, or a comparison layout can cost rankings and conversions just as surely as a security incident, so the update needs a quick front-end check after it goes live.
The wider point in the original post is worth taking seriously too. If AI-assisted discovery keeps accelerating, treating patching as a one-off event will not be enough. A routine check for the PHP version, the panel version, and any unpatched extensions, plus monitoring for unexpected file changes, is now part of basic site maintenance. For gambling affiliate sites in particular, a compromise does not just mean downtime: a hacked page can trigger browser warnings and search warnings, and recovering trust after that is far slower than the update itself.
Yes for those that are able to just go ahead and update their current 8.x versions should do so as soon as they can.
For those upgrading from 7.x versions or lower, be sure to get backups etc just in case you have an older template or plugin that causes issues.
Agree that patching and or upgrading sites, server OS and infrastructure should also be a discussion as part of long term plans.
Rick
Universal4
I saw this on X and thought it was just some fear-mongering and engagement farming going on. Didn’t think for a second that it was real. Come to find out PHP powers 43 percent of the web. Sheesh
There was an interesting case study yesterday to see just how easy (or hard) it is to crack the PHP vulnerability whereby someone created a vulnerable website called xxx.stealmybitcoin.com and put a $2k bounty on it for the first person to successfully hack the site.
Grok's summary of the outcome: https://x.com/grok/status/2114557812395200644
Suggests to me that it was pretty hard work to hack the site which likely means any exploitation of PHP will be very targeted, so the wider internet can probably sleep a little easier.Quote:
a server ran unpatched PHP 8.4.26 vulnerable to the new PHP2Shell RCEs (CVE-2026-109618/109619). A Bitcoin private key (~$500, later ~0.025 BTC/$2k via donations) sat behind a print-flag binary accessible only to the PHP user.
First to exploit and claim it won. It held for 19.28 hours until 15:47 UTC on 25 Oct 2026. Winner KillaBoi used a multi-stage memory-corruption chain (OOM session poisoning, heap/code leaks, forged structures for system()) and posted the PoC.
A portion of the problem is that tools to take advantage of any vulnerability the older versions do have will improve likely.
Additionally, those on the older versions do not necessarily need the extra bandwith and thousands of hits to the sites on the general scans etc. Although I have not seen anyone write about it yet, but wondering if the sciptkiddies will focus more on such targeted attacks. Only time will tell on that one.
Yes it is good that many of the attack vectors of the last few years are not "easy" but I think being aware of the vulnerability is helpful in the end.
Also keep in mind that a small portion of extensions have been deprecated (especially if moving from a 5x or 7x version). In some cases you need to replace the extension, in a few cases they just need to be renamed. Be sure to monitor the phperror logs close after upgrades in case your template is using a function that was changed.
Rick
Universal4
We managed to update our network except for 2 forums which run on older software ,we are still working their solutions for those.
This will become the new norm unfortunately. Can't help but get the feeling that it's not going to end well.
Surprised how many plugins and templates (even those recently updated) have so many deprecated functions etc.
Most often in the way an array is defined or the construct function is what many have seen so far.
What was also odd is when a plugin developer/owner has articles pushing to get the php upgraded and yet their own plugins need a few minor tweaks. Sure fixing the construct statement or adding a ? in the needed places helps, but if they don't fix the plugin code, the next time they update you might have to fix it again if they do not address it.
Rick
Universal4
Seeing more and more errors from wordpress plugins after php updates.
Often simple fixes such as a ? needed, or a few lines needs changed but most plugin developers are extremely slow to fix them, even after some cases where others have shown what the fix is.
WP migrate lite, yoast seo, ad rotate (much older versions have errors here and it require over version 8.x for a long time).
Was surprised yoast was slow so I asked google's AI if rankmath had similar issues, seems they do.
Quote:
Just like Yoast, Rank Math has a backlog of known, community-tested fixes sitting in their support threads that they have failed to merge into production releases. On PHP 8.5.12, Rank Math throws frequent deprecation notices, particularly around data-formatting routines:
If the ai is correct some plugins might trigger errors for a long time to come.Quote:
Users have submitted the exact code fixes required to make these files PHP 8.5 compatible (such as implementing basic type-casting like (float) or short-circuit null coalescing ?? 0.0). Yet, Rank Math’s repository handlers have largely brushed these off, stating that they won't alter the core engine until their internal team completes generalized compatibility cycles.
Sure hope plugin dev's get on the fixes. Sure you can make some of the fixes yourself, but if you do and the plugin pushes out an update it might break your fix.
One suggestion a member told me privately was to put the fixed plugin in the MU folder (must use) as this should skip the others. Have not tried this yet.
Rick
Universal4
As someone mentioned above, don't think there should be any panic about any of this, but it really is sad to see plugin developers post about how it is "ok" to just ignore deprecation errors, as if the word "error" has a different definition.
Granted not necessary to panic over a deprecation error in the log, however when they are completely ignored, if you suddenly have a hard error, it can make tracing that error down much much more difficult. And it also raises the question, well if the soft one was fixed, would the hard error exist?
Rick
Universal4
careful with the mu folder idea. wordpress only auto loads php files sitting directly in mu-plugins, not plugin folders inside it, so you need a small loader file. and if the original plugin is still active in the normal plugins folder you get a cannot redeclare fatal error instead of a fix.
for the deprecation notices themselves, on a live site they don't need fixing right away, they're warnings about future php versions. keep wp_debug and display_errors off in production and log them instead, so the site stays clean while you wait for the plugin update. and if you do patch a plugin yourself, block updates for it so the next release doesn't quietly overwrite your fix.
Deprecation errors are errors IMO and they slow down page loads and queries to the database.
I find it sad and plain stupid that a few of the plugin developers have already been supplied the fixes, but THEY refuse to address it
I am not planning on using the mu folders myself unless it becomes necessary.
Rick
Universal4