WordPress 6.4 Bug – Exposing Hosting Providers Utilizing 10 Year old version of cURL

Last Updated on November 13, 2023 EST by Jordan

Introduction

WordPress released version 6.4, which included a PR to the WordPress/Requests library.

Add Connection:close header only when needed by mircobabini · Pull Request #657 · WordPress/Requests · GitHub

Pull Request Type I have checked there is no other PR open for the same change. This is a: Bug fix New feature Code quality improvement Context Fixes #656. Quality assurance This change does NOT contain a breaking change (fix or feature that would cause existing functionality to change). I have commented my code, particularly in hard-to-understand areas. I have added unit tests to accompany this PR. The (new/existing) tests cover this PR 100%. I have (manually) tested this code to the best of my abilities. My code follows the style guidelines of this project.

github.com

A vast number of WordPress sites after updating to WordPress 6.4 had issues with anything that related to accessing external resources, such as WordPress updates, REST API, and the WordPress Site Health checker. The following error could be observed.

Error: RuntimeException: Failed to get url 'https://api.wordpress.org/core/version-check/1.7/?locale=en_US': cURL error 28: Operation timed out after 10000 milliseconds with 807 out of -1 bytes received.

Why did WordPress 6.4 break some sites and not all?

The core of the issue seems to be related to the version of curl that is running on some hosting providers; superficially, it looks as though cURL version 7.29 which was released 10 years ago.

curl version 7.29.0 was released on February 6 2013. The following 78 security problems are known to exist in this version.

Vulnerabilities in curl 7.29.0

curl.se

Most of these hosting providers look to be running RHEL7 and CentOS7, which doesn’t have an end-of-life until June 2024. However, they’re still using an extremely out-of-date version of cURL.

Here’s the Github issue submitted to WordPress/Requests informing that pull request #657 breaks downloads towards https://api.wordpress.org and other functions and endpoints that rely on the WordPress/Requests library.

Connection: Close not set when needed – breaks downloads. · Issue #838 · WordPress/Requests · GitHub

#657 breaks downloads towards https://api.wordpress.org/ and many other sites when using Curl 7.29.0 (and perhaps other versions) Error: RuntimeException: Failed to get url ‘https://api.wordpress.org/core/version-check/1.7/?locale=en_US’…

github.com

#657 breaks downloads towards https://api.wordpress.org/ and many other sites when using Curl 7.29.0 (and perhaps other versions)

Error: RuntimeException: Failed to get url 'https://api.wordpress.org/core/version-check/1.7/?locale=en_US': cURL error 28: Operation timed out after 10000 milliseconds with 807 out of -1 bytes received.

It also causes issues with the REST API in Site Health with the error: REST API response: (http_request_failed) cURL error 28: Operation timed out after 10005 milliseconds with XXX out of XXX bytes received”

It also prevents WordPress plugin and core updates, basically anything that relies on the internal Curl handler in WordPress.

Adding back Connection: Close solves the issue. Please revert #657 ASAP and push the fix to WordPress 6.4

If you are just looking to fix the cURL timeouts issue in WordPress 6.4 Read here:

To fix the issue, replace /wp-includes/Requests/src/Transport/Curl.php with the following file: Curl.php.zip or see #838 (comment)

https://github.com/WordPress/Requests/issues/838

The submitted tomsommer is the creator of simply.com the largest webhosting provider in Denmark.

There’s also adrian-enspired who looks to work for nexcess.net

You can see a couple of posts down that tomsommer states that RHEL7/CentOS7 are affected by this bug.

Who wasn’t impacted and why?

It’s hard to tell, but a fair guess would be any hosting provider running a Linux distribution that ships with a curl version above 7.29. So, let’s see which providers aren’t affected.

Hosting Providers and Control Panels, Running cURL Greater Than Version 7.29

Hosting Providers

• Siteground (curl 7.85.0)

Control Panels

• GridPane (Depends on OS, See Operating Systems)
• Runcloud

Operating Systems Running a Modern Version of cURL

Ubuntu

• Ubuntu 22.04 LTS – “Jammy Jellyfish”: EOL is expected to be in April 2027 – cURL 7.81
• Ubuntu 20.04 LTS – “Focal Fossa”: EOL is expected to be in April 2025. – cURL 7.68.0
• Ubuntu 18.04 LTS – “Bionic Beaver”: EOL is expected to be in April 2023 – cURL 7.58.0

CentOS

• CentOS 8 – EOL was December 31, 2021. CentOS shifted its focus to CentOS Stream, starting with version 8. – cURL 7.61
• CentOS 7 – The full updates ended in Q4 2020, and the maintenance updates are expected to end on June 30, 2024 – cURL 7.29.0 AFFECTED.
• CentOS 6: EOL was November 30, 2020. – cURL 7.19

Debian

I didn’t have time to provide this at this time.

My GitHub Issue Comments Screenshot Backup

I’m putting this here as a backup and to make it easier for folks to read instead of going to the Github issue.

Conclusion

I’ve said my peace on the GitHub issue. Keep your version of cURL up to date, period. Ensure you’re using a modern operating system that ships with the latest software versions and provides necessary security updates, whether as a self-hoster, utilizing a control panel like GridPane or a massive outfit like the ones mentioned above.

Everyone here has a lesson to learn; this could have been done better. I’m not going into details, but I think it’s essential that WordPress looks at setting the required version of cURL to be at least the latest version for all versions of PHP. Ignoring how hard it is for hosting providers to accomplish this, instead provide a timeline.

Changelog

• 11-13-2023 – Added the original error message that was seen.