WordPress 6.4.1's update addresses a significant bug in cURL/Requests that could potentially cause security vulnerabilities. Users are urged to install the latest version to ensure their websites are protected from potential threats.
Over the course of the last 24 hours, WordPress contributors have been hard at work preparing a 6.4.1 maintenance release, as a change in the Requests library revealed a significant fault that caused updates to malfunction on servers running older versions of cURL.
Sommer stated that even if this problem is resolved now, it would still block future auto-upgrades to 6.4.1 because it breaks Curl requests. As a result, users will have to update manually going forward. The issue will get worse the longer you put it off.
After updating to WordPress 6.4, all of my websites locked, according to Javier Martn Gonzlez. Those without updates are operating as usual.
As a hotfix release to address the issue, WordPress 6.4.1 updates the Requests library from version 2.0.8 to 2.0.9. It undoes the troublesome modification. Three more independent bugs are also fixed in version 6.4.1. This evening, those who have sites that allow for automatic background updates will receive automatic updates.
6.4 timed out rather than throwing a PHP error, locking me out of the admin panel entirely. In the end, I downloaded 6.3.2 and replaced the root.php file, wp-admin/, and wp-includes/ with it. After a database migration, everything started operating once more.
However, the only impacted version I've seen is cURL 7.29, which is ten years old and rife with security flaws. Notably, since that project is no longer active, anyone who hasn't upgraded from CentOS 7 (which will expire in June 2023) is probably still on this version.
It's critical to comprehend the operation of enterprise-level hosting. Because they are dependable and reliable, hosts tasked with providing enterprise-level environments usually purposefully run older versions of Linux. However, this implies that older versions of packages, such as cURL, are frequently included on them.
However, active support for those programs and backported changes are among the advantages of using enterprise Linux distributions. It doesn't necessarily follow that a package version isn't being patched at all if its own maintainers are no longer doing so. For those who are unaware of how Enterprise Linux operates, here is some background. Mitigating issues like older packages requiring fixes is far simpler and better for users than mitigating the instability that comes with the newest and greatest.
The file is called vuln-7.29.0.json.
Our cURL version is 7.81.0, and I manage my own dedicated servers that host hundreds of WordPress websites.
The most expensive hosting plans offered by hosting companies are enterprise level plans. It is also the highest margin strategy, as everybody working in this field knows. Let us consider it while we examine your response.
However, since you bring up Enterprise Linux, RHEL 8 was published more than 4 years ago, and 8.2 (3.5) and 8.1 (4 years) were released not too long after. There have been other variants since then.
According to the issue report, all versions of cURL before 7.45 that did not default to http2 were impacted, not only 7.29.
Although cURL 7.45 is still quite old, it's important to note that CentOS and RHEL7 come with a package called 7.29. While these are long-term support environments, they are very near to being completely EOL, so even though you claim they are still supported by patches, it is evident that they are not really/fully supported.
CentOS 7 is now available, and those using this non-enterprise Linux distribution as hosts. I can relate to their situation in a lot of ways. They have nowhere to go—for those who are unaware, the project was abandoned—and the successor version, centOS 8, actually EOLed in December 2021, or about two years ago. They were thrown on by RedHat from a tremendous height. They must make a difficult decision about where to go and what to do, especially if they are using CloudLinux, which is still in beta.
https://access.redhat.com/security/cve/cve-2023-27535 https://www.cve.org/CVERecord?id=CVE-2023-27535
https://access.redhat.com/security/cve/cve-2022-35252 https://www.cve.org/CVERecord?id=CVE-2022-35252
https://access.redhat.com/security/cve/cve-2022-43552 https://www.cve.org/CVERecord?id=CVE-2022-43552
0 Comments