All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Security notice: PHP 7.4 is *dead*
With everyone all abuzz about deals, it's easy to forget about security.
Today's big security news is that PHP 7.4 (and thereby 7.x as a whole) is finally dead. It's past time to start thinking about migrating to 8.0 or 8.1, if you haven't yet migrated, as those are the only versions getting new security updates as of this writing.
Some interesting related links:
You may find that LTS distros still backport some of the patches for 8.x to 7.x. But really, you should be looking at migration paths: migrating now is less hassle than potential pwnage later.
If you're on a RedHat-derived distro (RHEL/CentOS/Alma/Rocky/etc.), take a look at Remi's Repo for the best third party packaging I know of. (Remi is a PHP contributor, so you can be pretty sure the builds are done "right", rather than being some rando on the net scratching their own itch.)
From Ubuntu-y friends, I keep hearing that this is the One True PPA to use. I don't use Debian-derived distributions, so I cannot say much more than that.
For openSUSE/SLES, devel:languages:php is the place to look. There are, of course, other OBS repos available. But devel:languages:php is the "official SuSE upstream". You can also install it via sudo opi php8
if you have opi
installed.
And if you are thinking of waiting a few days, consider jumping straight to PHP 8.2 which is coming any time now.
Comments
My website is still on php 5.4
I came prepared with a case of 40s to pour out
YOLO
already upgraded all my php project to 8.1 \o/
I also came prepared with a case of cookies
I am already migrating my code from php8.1 to php8.2
8.2 may release on December 8th 2022
If anyone is looking to migrate between PHP version, I highly recommend using Rector,
https://getrector.org/
get rector or get rekt
PHP 7.x has been outdated for a while (8.0 was released around two years ago) so I'm surprised there's still people running it in production. On the other hand, there's things like this:
and I found something the other day still running on PHP 4...
¯\_(ツ)_/¯
as mentioned in another thread.
Nothing to do here. Keep running as is. Make time to eventually upgrade.
Cloudlinux and imunify360 have a hardened version of the PHP versions that are updated to some degree.
I request link for this miracle.
You can find a bunch in Google. 20 year old builds of PHP, probably abandoned servers running Linux 2.2 or 2.4, still sitting and serving stuff. wow
OMG
It's scarier than that:
You can't necessarily figure out immediately which attacks the Linux hosts would be vulnerable to. But you can with this kind of Windows information.
Latest PHP 7.4 might be without official support, but it also has no critical vulnerability yet. Let's calm down and enjoy the holidays. There is time to upgrade later. Besides, some third party systems will patch it up for many years to come, so once again: there is absolutely no rush.
No drama here. No popcorn here. No "cookies" here.
Wow I haven't seen Windows 2000 in the wild for a long time!
I remember Snopes.com was running on Windows Server 2003 until pretty recently (a few years ago)...
this is a fucking conspiracy.
i have some web-app for my client that running laravel 4.2 (with php 5.6)
To think that I discovered php with php/fi ... it doesn't make us younger
It would take less than 30 mins to setup a script to abuse this stuff and harvest servers for questionable usage. I'm amazed that these are not hacked by anyone yet.
They could be without anyone knowing and the attackers being discrete (not needing/willing to show that the box is pwnd).
The upgrade/update mania.
Nowadays, everything from last year is considered "old," while two years is "ancient." LOL
Our motorcycling forum is still running on PHP 5.6 (using the "hardened" CloudLinux 5.6 version).
Anyone competent and willing to dedicate their time to updating the code (for a tap on the shoulder and a "good job") is more than welcome. Until then, it will stay with 5.6. So far so good.
Oh, and WordPress still doesn't officially support anything beyond 7.4 as far as I know.
WordPress definitely drives PHP major versions adoptions so yeah WordPress needs newer PHP version support.
Bring on PHP 8.2 due in ~9 days for GA!
On Centmin Mod latest beta
Software devs can't use tricks like builtin batteries for planned obsolescence, but there's no need to, when stamping feet and crying "EOL" work impeccably.
One of my website is still on PHP5.6. I am too lazy to work on a legacy CMS.
Wordpress 6.1 is still in beta phase for PHP8.
Alot of WP sites under the issue of themes / plugins(quiite alot of them) not yet even support php 8.0
Cloudlinux's Extended Support for Centos 6.x seems pretty good, but Docker is supposed to be meant for such things, right?
If you add the security layer (firewall / WAF / mod_security) to the outer OS (host inside which docker runs) and run PHP 5.x/7.x on Centos 6.x / etc inside docker, it should mitigate against the attacks that make upgrades "mandatory", IMO.
Any flaws in this idea?
WordPress supports PHP 8 and has since PHP 8 was released. I have lots of not-nice things to say about WP and its community, but I cannot say that Automattic slacks on supporting the latest versions of their requirements.
From the core team's blog a few days prior to PHP 8.0's release:
And a note from that same post (two years old now but still relevant):
So basically, people not upgrading their PHP makes the work of supporting newer versions harder. PHP 9 is likely to bring a large amount of modernization that was "too much" for PHP 8.
Automattic has a hard decision to make for WP 6.2: leave PHP 8 support marked as "beta" as it has been for literal years now (though much of their user base uses 8)? or finally ditch PHP 5.6 support that has caused them to write a ton of polyfill-type stuff to support PHP 8 while also supporting 5.6? Time will tell what they decide, but it will certainly be strange optics if they don't officially support any officially-supported versions of PHP. (And, yes, there are discussions within core on this topic. Again, time will tell what happens.)
If individual plugins don't support new major versions of PHP within two years of release, you should seriously be concerned about whether they're implementing best practices in the WP community, in general. So many times when I've had to clean up after WP pwnage, the vector of entry was some "simple" plugin that "shouldn't" have been able to be abused, yet it was because its maintainer did not take the time and care to feed their creation to be its best.
And I'm not saying to not run commercially-supported "hardened" versions of PHP that actively backport and address CVEs. But the average user (especially places like LET) does not fall into that camp.
Especially if they're using PHP on Windows (as many people do). PHP 5.6.40, since PHP 5 is a popular thing to bring up, has a CVE (fixed in 7.1.24) that can allow an attacker to easily crash the entire web server via a null pointer dereference.
For those of you using downlevel (EOLed by PHP.net) versions of PHP and doing image handling that supports user-provided images, do make sure that this CVE is patched. (Fixed in 7.1.27, 7.2.16, and 7.3.3. The bug report has instructions on how to test it in the comments.) Exploitation is trivial if users can upload files as it just needs one of many magic strings in it for merely using
exif_read_data()
on the file (for example, to see if you need to apply rotation to a scale/rotation) is sufficient. There are a number of nefarious attacks in the wild used to surreptitiously obtain data from vulnerable sites using this CVE. The bug report calls out JPEG files for testing since you only need 8 bytes to trigger it, but you can literally make any image format trigger that badness.There are other vulnerabilities, as well, but that one is actively exploited daily. If your "hardened" PHP is vulnerable to that, it's not very hardened, honestly.
And most Linux distros will only backport fixes for the CVEs that their paying customers complain about. So generally only the most severe, such as the above EXIF bug. Which might leave you vulnerable to various DoSes that require circumstances that those with support agreements and a sensitivity to CVE scanning don't happen to be affected by.
And for those of you who freak out over upgrading major PHP versions only living about 3 years: how often do you change the tires on your car? Why is it about 3 years? Surely those treads are planned obsolescence?
Software requires maintenance, just as your vehicle does. CVEs are the software equivalent to vehicle recalls. Just like with your car, it's up to you to determine whether you care about an individual recall. And jumping on someone letting people know "hey your manufacturer isn't going to put work into your release year getting active recalls anymore" is counterproductive. In software and cars alike, it's not something that gets a lot of attention. And people should be informed as to the fact that what they're using is no longer getting any focus from the manufacturer.
And, in all honesty, if you don't like 3 year major release cycles in PHP, you might want another language. It took 12 years from Python's announcement that Python 2 was being sunsetted until they finally killed it, for instance.
Upgraded from 7.4 to 8.1 yesterday. I'm surprised that I experienced no errors. It helps that all my WordPress plugins are regularly updated.
@lewellyn following your signature, since your post is excellent, should I compliment Elliotj?