WordPress 6.4.1修复了一个关键的cURL/Requests错误。

WordPress贡献者在过去的24小时内迅速准备了一个6.4.1维护版本，之前出现了一个关键的错误，是由于Requests库的更改导致服务器上运行旧版本cURL的更新问题。

托管公司开始报告这个错误的广泛影响。来自丹麦最大的一家托管公司之一的Tom Sommer在GitHub上提交了一个问题，详细说明了cURL超时如何影响网站：

• #657 在使用Curl 7.29.0（以及可能其他版本）时破坏了对https://api.wordpress.org/和许多其他站点的下载
• 错误：RuntimeException：获取网址'https://api.wordpress.org/core/version-check/1.7/?locale=en_US'失败：cURL错误28：10000毫秒后操作超时，已接收807个字节，共-1个字节。
• 这也导致了站点健康中的REST API错误：REST API响应：（http_request_failed）cURL错误28：10005毫秒后操作超时，已接收XXX个字节，共XXX个字节
• 这也阻止了WordPress插件和核心更新，基本上是依赖WordPress内部Curl处理程序的任何东西。

这个问题成为了首要任务，因为不清楚用户如何接收更新。

“即使现在您修复了这个问题，该问题也会阻止任何将来自动升级到6.4.1的操作，因为它破坏了Curl请求，所以人们更新的唯一方式是手动更新，” Sommer说。 “您等待的时间越长，问题就会变得越大。”

Nexcess报告称，数以万计的站点受到了这个错误的影响。这个问题超出了大多数用户自行修补的范围，因此托管提供商必须找出如何更新他们的客户。

“在升级到WordPress 6.4后，我的所有网站都被锁住了，”Javier Martín González报告说。 “没有更新的网站正常工作。”

据报告，这个错误还导致了可能引起Stripe API、WP-Admin和性能问题。

Liquid Web/Nexcess产品经理Tiffany Bridge 总结了这个问题是如何出现的：

看起来像这样：

• 有人报告了一个关于入侵保护系统和WordPress之间互动的错误
• 然后他们提交了自己的补丁给WordPress
• 该领域的项目负责人要求提交者编写测试，但他没有这样做
• 尽管缺乏测试，他们仍然合并了PR
• 与此同时，如果我们运行受影响的cURL版本（已确认为7.29，可能还有其他版本），则所有托管提供商都必须自己恢复更改，以确保我们的客户仍然可以获得核心和插件更新等小事情。

WordPress核心贡献者必须弄清楚这个错误是如何通过的，通过事后分析或其他讨论，以防止将来发生类似的大规模问题。

WordPress 6.4.1 更新了Requests库，从版本2.0.8到2.0.9，作为一个快速修复版本，以减轻问题。它撤销了有问题的更改。版本6.4.1还包括针对其他三个独立问题的修复。对于支持自动后台更新的站点，自动更新已于今晚发布。