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還包括針對其他三個獨立問題的修復。對於支持自動後台更新的站點，自動更新已於今晚發佈。