因此，它會受到 ALAS2023-2025-835 公告中提及的一個弱點影響。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

因此，會受到 ALAS2023-2025-833 公告中所提及的多個弱點影響。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

    攻擊者可特製 Parse 函式的輸入，而該輸入的長度會遭到非線形處理，進而導致剖析速度極慢。如此可能造成拒絕服務的狀況。(CVE-2024-45338)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 containerd 版本為早於 1.7.25-1 的版本。因此，會受到 ALAS2NITRO-ENCLAVES-2025-049 公告中所提及的一個弱點影響。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端 Azure Linux 3.0 主機上安裝的 cert-manager / cf-cli / docker-buildx / docker-compose / moby-compose / moby-engine / packer 版本比測試版舊。因此，此版本會受到 CVE-2024-45337 公告中提及的一個弱點影響。

  - 應用程式和程式庫誤用 connection.serverAuthenticate (透過回呼欄位 ServerConfig.PublicKeyCallback) 可能容易發生授權繞過問題。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 可使用多個金鑰呼叫且無法使用提供金鑰的順序來推斷用戶端使用哪個金鑰成功驗證 (若有)。某些應用程式若儲存了傳遞至 PublicKeyCallback (或衍生資訊) 的金鑰並在連線建立後根據該金鑰做出安全性相關判定則 可能會做出不正確的假設。例如攻擊者 可能傳送公開金鑰 A 和 B然後使用 A 進行驗證。PublicKeyCallback 只會被呼叫兩次第一次使用 A 然後使用 B。有弱點的應用程式接著會根據攻擊者所針對的金鑰 B 做出授權決策不會實際控制私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意如果之後使用其他方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 驗證連線用戶端可能仍無法控制傳遞給 PublicKeyCallback 的最後一個金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 誤用 connection.serverAuthenticate (透過回呼欄位 ServerConfig.PublicKeyCallback) 的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如攻擊者可能傳送公開金鑰 A 和 B然後使用 A 進行驗證。PublicKeyCallback 只會被呼叫兩次第一次是使用 A 然後是 B。有弱點的應用程式接著可能會根據攻擊者所針對的金鑰 B 做出授權決策不會實際控制私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

請注意，Nessus 依賴供應商報告的套件存在。

遠端主機上安裝的 containerd 版本為早於 1.7.25-1 的版本。因此，它會受到 ALAS2ECS-2025-046 公告中提及的一個弱點影響。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 containerd 版本為早於 1.7.25-1 的版本。因此，它會受到 ALAS2DOCKER-2025-049 公告中提及的一個弱點影響。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 runfinch-finch 版本早於 1.6.0-1。因此，會受到 ALAS2DOCKER-2025-050 公告中所提及的多個弱點影響。

    2025-02-12：已將 CVE-2024-51744 新增至此公告。

    2025-02-12：已將 CVE-2024-45338 新增至此公告。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

    攻擊者可特製 Parse 函式的輸入，而該輸入的長度會遭到非線形處理，進而導致剖析速度極慢。如此可能造成拒絕服務的狀況。(CVE-2024-45338)

    golang-jwt 是 JSON Web Token 的 Go 實作。`ParseWithClaims` 中錯誤行為的不清楚的文件記錄可導致使用者無法以應有的方式檢查錯誤的情況。尤其如果權杖已過期且無效，則 `ParseWithClaims` 傳回的錯誤會傳回兩個錯誤碼。如果使用者只使用 `error.Is` 檢查 `jwt.ErrTokenExpired `，他們將忽略內嵌的 `jwt.ErrTokenSignatureInvalid`，因此可能接受無效的 token。已使用錯誤處理邏輯將一個修正從 `v5` 分支反向移植到 `v4` 分支。在此邏輯中，`ParseWithClaims` 函式會在危險情況下 (例如，無效的簽章) 立即傳回，將合併的錯誤限制為僅在簽章有效但進一步驗證失敗的情況下 (例如，如果簽章有效，但已過期且具有錯誤的接受者)。此修正是 4.5.1 版本的一部分。我們知道這會變更已建立函式的行為，且並非 100 % 回溯相容，因此更新至 4.5.1 可能會損毀您的程式碼。如果您無法更新至 4.5.0，請確認您正在正確檢查所有錯誤 (先檢查危險錯誤)，以免發生上述情況。 (CVE-2024-51744)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 nerdctl 版本低於 2.0.3-1。因此，會受到 ALAS2-2025-2749 公告中所提及的多個弱點影響。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

    攻擊者可特製 Parse 函式的輸入，而該輸入的長度會遭到非線形處理，進而導致剖析速度極慢。如此可能造成拒絕服務的狀況。(CVE-2024-45338)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

因此，會受到 ALAS2023-2025-834 公告中所提及的多個弱點影響。

    2025-02-11：已將 CVE-2024-45338 新增至此公告。

    2025-02-11：已將 CVE-2024-51744 新增至此公告。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

    攻擊者可特製 Parse 函式的輸入，而該輸入的長度會遭到非線形處理，進而導致剖析速度極慢。如此可能造成拒絕服務的狀況。(CVE-2024-45338)

    golang-jwt 是 JSON Web Token 的 Go 實作。`ParseWithClaims` 中錯誤行為的不清楚的文件記錄可導致使用者無法以應有的方式檢查錯誤的情況。尤其如果權杖已過期且無效，則 `ParseWithClaims` 傳回的錯誤會傳回兩個錯誤碼。如果使用者只使用 `error.Is` 檢查 `jwt.ErrTokenExpired `，他們將忽略內嵌的 `jwt.ErrTokenSignatureInvalid`，因此可能接受無效的 token。已使用錯誤處理邏輯將一個修正從 `v5` 分支反向移植到 `v4` 分支。在此邏輯中，`ParseWithClaims` 函式會在危險情況下 (例如，無效的簽章) 立即傳回，將合併的錯誤限制為僅在簽章有效但進一步驗證失敗的情況下 (例如，如果簽章有效，但已過期且具有錯誤的接受者)。此修正是 4.5.1 版本的一部分。我們知道這會變更已建立函式的行為，且並非 100 % 回溯相容，因此更新至 4.5.1 可能會損毀您的程式碼。如果您無法更新至 4.5.0，請確認您正在正確檢查所有錯誤 (先檢查危險錯誤)，以免發生上述情況。 (CVE-2024-51744)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 amazon-cloudwatch-agent 版本低於 1.300052.1-1。因此，會受到 ALAS2-2025-2779 公告中所提及的多個弱點影響。

    針對包含深度巢狀常值的 Go 原始程式碼呼叫 Parse 函式會造成錯誤，因堆疊耗盡所致。(CVE-2024-34155)

    針對包含深度巢狀結構的訊息呼叫 Decoder.Decode 會造成錯誤，因堆疊耗盡所致。這是 CVE-2022-30635的後續項目。 (CVE-2024-34156)

    針對具有深度巢狀運算式的 // +build 構建標籤行呼叫 Parse 會造成錯誤，因堆疊耗盡所致。(CVE-2024-34158)

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

    攻擊者可特製 Parse 函式的輸入，而該輸入的長度會遭到非線形處理，進而導致剖析速度極慢。如此可能造成拒絕服務的狀況。(CVE-2024-45338)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
215032	Amazon Linux 2023：containerd、containerd-stress (ALAS2023-2025-835)	Nessus	Amazon Linux Local Security Checks	2025/2/5	2025/2/6	critical
215036	Amazon Linux 2023：nerdctl (ALAS2023-2025-833)	Nessus	Amazon Linux Local Security Checks	2025/2/5	2025/2/6	critical
214928	Amazon Linux 2 : containerd (ALASNITRO-ENCLAVES-2025-049)	Nessus	Amazon Linux Local Security Checks	2025/2/4	2025/2/5	critical
215502	Azure Linux 3.0 安全性更新cert-manager / cf-cli / docker-buildx / docker-compose / moby-compose / moby-engine / packer (CVE-2024-45337)	Nessus	Azure Linux Local Security Checks	2025/2/10	2025/3/13	critical
246552	Linux Distros 未修補的弱點：CVE-2024-45337	Nessus	Misc.	2025/8/9	2025/8/9	critical
214922	Amazon Linux 2 : containerd (ALASECS-2025-046)	Nessus	Amazon Linux Local Security Checks	2025/2/4	2025/2/5	critical
214923	Amazon Linux 2 : containerd (ALASDOCKER-2025-049)	Nessus	Amazon Linux Local Security Checks	2025/2/4	2025/2/5	critical
214926	Amazon Linux 2：runfinch-finch (ALASDOCKER-2025-050)	Nessus	Amazon Linux Local Security Checks	2025/2/4	2025/2/14	critical
214979	Amazon Linux 2：nerdctl (ALAS-2025-2749)	Nessus	Amazon Linux Local Security Checks	2025/2/4	2025/2/5	critical
215029	Amazon Linux 2023：runfinch-finch (ALAS2023-2025-834)	Nessus	Amazon Linux Local Security Checks	2025/2/5	2025/2/14	critical
232366	Amazon Linux 2：amazon-cloudwatch-agent (ALAS-2025-2779)	Nessus	Amazon Linux Local Security Checks	2025/3/10	2025/3/10	critical

偵測

搜尋 Plugin

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical