安全性公告

以下說明與 Apigee 相關的安全性公告。

如要接收最新的安全公告,請執行下列任一操作:

  • 將本頁面的網址加入動態消息閱讀器
  • 直接將動態消息網址新增至動態消息閱讀器:https://cloud.google.com/feeds/apigee-security-bulletins.xml

GCP-2026-010

發布日期:2026-02-13

說明

說明 嚴重性 附註

我們在 Apigee 平台中發現一項安全漏洞,如果惡意行為人在自己的 Apigee 環境中擁有管理員或開發人員層級的權限,就可能藉此提升權限,並存取跨租戶資料。

具體來說,Apigee X 的沙箱技術存在漏洞,導致使用者可透過本機連結端點,存取客戶租戶專案中的服務帳戶權杖 (P4SA)。理論上,攻擊者可以利用這個身分,讀取其他 Apigee 機構 (租戶) 的分析中繼資料,或竄改內部監控記錄。

我該怎麼做?

顧客無須採取任何行動。Google 已實施多層級的緩解策略,以解決這個問題:

  • 權杖遭濫用問題的解決方法:我們已解決執行階段 Pod 中 Apigee 服務帳戶權杖的濫用問題。
  • 最小權限原則:Apigee 服務帳戶權限受到限制,可防止未經授權的修改。
  • 資料隔離:已移除資料夾層級服務帳戶對多租戶 Google Cloud Storage 值區的存取權。

Google 已確認,雖然理論上可以存取內部監控記錄,但這些記錄僅供 Google 內部使用,不會影響 Apigee 中客戶資料的安全性或完整性。

CVE-2025-13292

GCP-2025-023

發布日期:2025-05-05

說明 嚴重性 附註

本公告說明已發現並解決的 JavaCallout 和 PythonScript 政策問題,這些問題可能導致安全性漏洞,因此請務必修正。這些政策可能會導致未經授權的遠端程式碼執行 (RCE) 和權限提升。這些可能的攻擊需要內部授權使用者存取權 (有權部署 Proxy 的使用者) 才能發動。這些潛在安全漏洞源自於沙箱不足,無法因應存取反射和模擬權限物件等情況,導致安全管理員遭到規避。

受影響的產品

影響範圍僅限於 JavaCallout 和 PythonScript 政策。這包括下列 Apigee 平台上的部署作業:

  • Apigee
  • Apigee Edge Public Cloud
  • Apigee Hybrid
  • Apigee Edge for Private Cloud

我該怎麼做?

請針對每個受影響的產品採取下列行動:

Apigee

使用 Google Cloud 版 Apigee 的客戶無須採取任何行動。 Apigee 版本 1-14-0-apigee-8 已套用安全漏洞修正程式。

如果發布團隊無法為貴機構推出版本,客戶技術管理團隊或支援代表會與您聯絡,修正任何受影響的 JavaCallout 代理套件。

Apigee Hybrid

您必須升級至下列其中一個安全性修補程式版本:

Hybrid 主要版本 針對受影響的子版本發布安全性修補程式
1.12 1.12.4
1.13 1.13.3
1.14 1.14.1
1.11 1.11.2 hotfix3

Apigee Edge Public Cloud

Apigee Edge 客戶無須採取任何行動。修正檔已套用至最新版 Edge 執行階段。如果您是客戶,且因已知待處理事項而無法更新至最新版 Edge,客戶支援代表會與您聯絡。

Apigee Edge for Private Cloud

如果您是 Edge for Private Cloud 使用者,請檢查 JavaCallout 和 PythonScript 政策,確保您使用的程式碼和程式庫來自可信來源。如要修改這類政策,必須具備內部授權存取權 (有權部署 Proxy 的使用者),因此建議您稽核權限,確保只有信任的使用者保留這類存取權。 Edge Private Cloud 版本 4.52.024.53.00 已套用安全性弱點修正程式。

GCP-2024-040

發布日期:2024-07-02

本公告包含下列各項 Apigee 產品的詳細資訊:

Edge Public Cloud

說明 嚴重性 附註

最近在 OpenSSH 中發現遠端程式碼執行安全漏洞 CVE-2024-6387。這項安全漏洞會利用競爭條件,取得遠端殼層的存取權,讓攻擊者取得 GKE 節點的根存取權。發布時,Apigee Edge for Public Cloud 不會遭到利用,且已採取防範措施。

雖然這個 CVE 無法遭到利用,但 Apigee 仍會升級工作負載,以解決上述 CVE。

我該怎麼做?

Apigee 使用者無須採取任何行動。

我們將在近期為工作負載套用修補程式,並在完成後更新安全公告。

重大

Edge Private Cloud

說明 嚴重性

最近在 OpenSSH 中發現遠端程式碼執行安全漏洞 CVE-2024-6387。這項安全漏洞會利用競爭情況,取得遠端殼層的存取權,讓攻擊者取得 VM 節點的根存取權。Edge Private Cloud 客戶擁有並管理部署 Edge Private Cloud 的 VM/實體主機。

版本 影響
OpenSSH < 4.4p1 易受攻擊
4.4p1 <= OpenSSH < 8.5p1 不易受攻擊
8.5p1 <= OpenSSH < 9.8p1 易受攻擊

我該怎麼做?

發出 ssh -V 指令,查看 OpenSSH 版本並驗證。如果您使用任何受影響的 OpenSSH 版本,請更新至不受此 CVE 影響的版本。OpenSSH 已於 2024 年 7 月 1 日發布 9.8p1

重大

Edge Microgateway

說明 嚴重性 附註

最近在 OpenSSH 中發現遠端程式碼執行安全漏洞 CVE-2024-6387。這項安全漏洞會利用競爭情況,取得遠端殼層的存取權,讓攻擊者取得 VM 節點的根存取權。Edge Microgateway 客戶擁有並管理部署 Edge Microgateway 的 VM/實體主機。

版本 影響
OpenSSH < 4.4p1 易受攻擊
4.4p1 <= OpenSSH < 8.5p1 不易受攻擊
8.5p1 <= OpenSSH < 9.8p1 易受攻擊

我該怎麼做?

請發出 ssh -V 指令查看 OpenSSH 版本,並驗證 OpenSSH 版本。如果您目前使用的 OpenSSH 版本受到影響,請更新至不受此 CVE 影響的版本。OpenSSH 已於 2024 年 7 月 1 日發布 9.8p1

重大

Apigee

說明 嚴重性 附註

最近在 OpenSSH 中發現遠端程式碼執行安全漏洞 CVE-2024-6387。這項安全漏洞會利用競爭條件,取得遠端殼層的存取權,讓攻擊者取得 GKE 節點的根存取權。發布時,Apigee 不會遭到利用,且已採取緩解措施。

雖然這個 CVE 無法遭到利用,但 Apigee 仍會升級工作負載,以解決 CVE-2024-6387。

我該怎麼做?

Apigee 使用者無須採取任何行動。我們將在近期為工作負載套用修補程式,並在完成後更新安全公告。

注意:如果 Managed Instance Groups 部署在客戶專案中,用於北向負載平衡,特別是 InternalRouting (VPC)ExternalRouting (MIG),請確認安裝在這些執行個體上的 OpenSSH 版本。如果該版本容易受到 CVE 影響,請自行更新至 2024 年 7 月 1 日發布的 OpenSSH 9.8p1 版,因為 Apigee 不會管理這些 MIG。

重大

Apigee Hybrid

說明 嚴重性 附註

最近在 OpenSSH 中發現遠端程式碼執行安全漏洞 CVE-2024-6387。這項安全漏洞會利用競爭條件取得遠端殼層的存取權,讓攻擊者取得 GKE 節點的根存取權。發布時,混合式映像檔並無安全漏洞,因為 OpenSSH 並未封裝至任何混合式容器映像檔。不過,如果主機/GKE 節點 OS 執行的是下列有安全漏洞的 OpenSSH 版本,混合式叢集就會遭到攻擊。

版本 影響
OpenSSH < 4.4p1 易受攻擊
4.4p1 <= OpenSSH < 8.5p1 不易受攻擊
8.5p1 <= OpenSSH < 9.8p1 易受攻擊

我該怎麼做?

Google Cloud Customer Care 安全性公告 GCP-2024-040 已解決這個問題。

如需操作說明和更多詳細資訊,請參閱下列公告:

重大

GCP-2024-006

發布日期:2024-2-5

說明 嚴重性 附註

當 Apigee API 管理 Proxy 連線至目標端點 目標伺服器時,Proxy 預設不會對目標端點或目標伺服器提供的憑證執行主機名稱驗證。如果未使用下列任一選項啟用主機名稱驗證,連線至目標端點或目標伺服器的 Apigee Proxy 可能會遭到授權使用者發動的攔截式攻擊。詳情請參閱「從 Edge 到後端 (Cloud 和 Private Cloud) 設定 TLS」。

受影響的產品

下列 Apigee 平台上的 Apigee Proxy 部署作業會受到影響:

  • Apigee Edge Public Cloud
  • Apigee Edge for Private Cloud

我該怎麼做?

顧客可以透過下列任一選項啟用這項驗證:

方法 1 - 在 Proxy 中新增設定

如要啟用目標端點或目標伺服器的驗證功能,請在Proxy 設定<HTTPTargetConnection> 元素中,將 <CommonName> 設定新增至 SSLInfo 區段,如下所示:

<HTTPTargetConnection>
  <SSLInfo>
    <Enabled>true</Enabled>
    <TrustStore>ref://mytruststoreref</TrustStore>
    <CommonName>*.example.com</CommonName>
  </SSLInfo>
  <URL>https://my.example.com/</URL>
</HTTPTargetConnection>

如果這個設定位於 Proxy 設定的 <HTTPTargetConnection> 元素中,Apigee 會使用 <CommonName> 中指定的值進行主機名稱驗證。這個欄位可以使用萬用字元。

Apigee 建議採用這種做法。您可以個別測試 Proxy,確認驗證作業是否正常運作,並將流量中斷的可能性降至最低。如要進一步瞭解如何在 Proxy 中測試主機名稱驗證及查看錯誤,請參閱「使用追蹤工具」。

方法 2 - 設定機構層級的旗標

您可以設定 Apigee 機構層級的旗標,為機構中所有已部署的 Proxy 和目標啟用主機名稱驗證。如果 features.strictSSLEnforcement 標記在機構屬性中設為 true,每次 Proxy 連線至目標端點或目標伺服器時,系統都會強制執行主機名稱驗證。

注意:這個選項有助於在整個機構啟用這項功能,但如果目標未提供預期憑證,可能會發生主機名稱驗證失敗的情況。

  • 如果是 Apigee Edge for Public Cloud 部署作業

    請與Google Cloud 支援團隊聯絡,將機構屬性中的 features.strictSSLEnforcement 旗標設為 true

    注意:啟用這個標記後,系統會對機構中的所有環境,以及部署在這些環境中的所有 Proxy 強制執行 SSL 檢查。

  • 如果是 Apigee Edge Private Cloud 部署作業:

    機構或系統管理員可以將 features.strictSSLEnforcement 旗標設為 true。如要進一步瞭解如何設定標記,請參閱更新機構屬性

    注意:使用 Organizations API 更新機構層級的標記時,請務必在 POST 要求中加入所有現有標記,以免覆寫先前的設定。

    設定標記後,必須個別重新啟動每個訊息處理器,變更才會生效。使用下列指令:

    apigee-service edge-message-processor restart

    如要還原這項變更,請使用相同的 Organizations API 將標記設為 false,然後重新啟動每個訊息處理器。

    注意:啟用這個標記後,系統會對機構中的所有環境,以及部署在這些環境中的所有 Proxy 強制執行 SSL 檢查。不過,如果 <IgnoreValidationErrors> 設為 true,系統就會忽略偵測到的任何驗證錯誤。

Apigee 建議您先在非正式環境中實作這項變更,確保驗證作業正常運作,且不會導致正式環境中斷。如果任何目標的主機名稱驗證失敗,系統會傳回下列錯誤訊息:

{"fault":{"faultstring":"SSL Handshake failed java.security.cert.CertificateException: No subject alternative DNS name matching example.com found.","detail":{"errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"}}}

GCP-2023-032

發布日期:2023-10-13

更新日期:2023 年 11 月 3 日

說明 嚴重性 附註

2023 年 11 月 3 日更新:新增 Apigee Edge Private Cloud 的 已知問題

最近在 HTTP/2 通訊協定的多項實作中發現阻斷服務 (DoS) 安全漏洞 (CVE-2023-44487),包括 Apigee X 和 Apigee Hybrid 使用的 Apigee Ingress (Cloud Service Mesh) 服務。這項安全漏洞可能會導致 Apigee API 管理功能發生 DoS 攻擊。

受影響的產品

  • Apigee X

    透過 Google Cloud 網路負載平衡器 (第 4 層) 或自訂第 4 層負載平衡器存取的 Apigee X 部署作業會受到影響。所有 Apigee X 執行個體都已套用 Hotfix。

  • Apigee Hybrid

    允許 HTTP/2 要求連至 Apigee Ingress 的 Apigee Hybrid 執行個體會受到影響。客戶應確認 Apigee Hybrid Ingress 前端的負載平衡器,是否允許 HTTP/2 要求傳送至 Apigee Ingress 服務。

  • Apigee Edge 私有雲

    Edge for Private Cloud 路由器和管理伺服器元件會公開至網際網路,因此可能存在安全漏洞。雖然 HTTP/2 已在 Edge for Private Cloud 的其他 Edge 專屬元件管理連接埠上啟用,但這些元件都不會公開至網際網路。在 Cassandra、Zookeeper 等非 Edge 元件上,HTTP/2 不會啟用。建議您按照「 Edge for Private Cloud 的已知問題」一文中的步驟,解決 Edge for Private Cloud 的安全漏洞。

不受影響的產品

  • Apigee X

    如果 Apigee X 執行個體僅透過 Google Cloud應用程式負載平衡器 (第 7 層) 存取,則不受影響。包括為 gRPC Proxy 啟用 HTTP/2 的部署作業。

  • Google Cloud API Gateway

    Google Cloud API Gateway 不受影響。

  • Apigee Edge Cloud

    Apigee Edge Cloud 不受這個安全漏洞影響。

我該怎麼做?

  • Apigee X

    2023 年 11 月 3 日更新:我們已透過 2023 年 10 月 13 日發布的 Apigee X 執行個體更新,解決這項安全漏洞。詳情請參閱 版本資訊

  • Apigee Hybrid

    Apigee Hybrid 客戶必須升級至下列任一修補程式版本:

  • Apigee Edge 私有雲

    Apigee Edge for Private Cloud 使用者可以按照「 Edge for Private Cloud 已知問題」一文中的操作說明,明確停用公開元件的 HTTP/2。

這些修補程式修正了哪些安全漏洞?

這個漏洞 (CVE-2023-44487) 可能會導致 Apigee API 管理功能發生 DoS 攻擊。

CVE-2023-44487