The following describes all security bulletins related to Apigee.
To get the latest security bulletins delivered to you, do one of the following:
- Add the URL of this page to your feed reader.
- Add the feed URL directly to your feed reader:
https://cloud.google.com/feeds/apigee-security-bulletins.xml
GCP-2024-040
Published: 2024-07-02
Edge Public Cloud
| Description | Severity | Notes |
|---|---|---|
|
A remote code execution vulnerability, CVE-2024-6387, was recently discovered in OpenSSH. The vulnerability exploits a race condition that could be used to obtain access to a remote shell, enabling attackers to gain root access to GKE nodes. At the time of publication, Apigee Edge for Public Cloud is not exploitable and mitigations are in place. Even though this CVE is not exploitable, Apigee will upgrade the workloads to address the above CVE. What should I do? No action item is required from Apigee users. Patching for workloads will be done in the upcoming days and the security bulletin will be updated once the patching is completed. |
Critical |
Edge Private Cloud
| Description | Severity | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
A remote code execution vulnerability, CVE-2024-6387, was recently discovered in OpenSSH. The vulnerability exploits a race condition that could be used to obtain access to a remote shell, enabling attackers to gain root access to VM nodes. Edge Private Cloud customers own and manage the VMs/Physical hosts where Edge Private Cloud is deployed.
What should I do? Review the OpenSSH version by issuing the command |
Critical |
Edge Microgateway
| Description | Severity | Notes | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
A remote code execution vulnerability, CVE-2024-6387, was recently discovered in OpenSSH. The vulnerability exploits a race condition that could be used to obtain access to a remote shell, enabling attackers to gain root access to VM nodes. Edge Microgateway customers own and manage the VMs/Physical hosts where Edge Microgateway is deployed.
What should I do? Please review the OpenSSH version by issuing commands |
Critical |
Apigee
| Description | Severity | Notes |
|---|---|---|
|
A remote code execution vulnerability, CVE-2024-6387, was recently discovered in OpenSSH. The vulnerability exploits a race condition that could be used to obtain access to a remote shell, enabling attackers to gain root access to GKE nodes. At the time of publication, Apigee is not exploitable and mitigations are in place. Even though this CVE is not exploitable, Apigee will upgrade the workloads to address CVE-2024-6387. What should I do? No action item is required from Apigee users. Patching for workloads will be done in the upcoming days and the security bulletin will be updated once the patching is completed. Note: If Managed Instance Groups are deployed in a customer project for northbound load balancing, specifically InternalRouting (VPC) and ExternalRouting (MIG), verify the OpenSSH version installed on them. If the version is vulnerable to the CVE, then update to OpenSSH version 9.8p1 released on July 1, 2024 by yourself, as Apigee does not manage these MIGs. |
Critical |
Apigee hybrid
| Description | Severity | Notes | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
A remote code execution vulnerability, CVE-2024-6387, was recently discovered in OpenSSH. The vulnerability exploits a race condition that could be used to obtain access to a remote shell, enabling attackers to gain root access to GKE nodes. At the time of publication, hybrid images are not vulnerable because OpenSSH is not packaged into any of the hybrid container images. However if your host/GKE-node OS is running with the below vulnerable versions of OpenSSH, your hybrid clusters will be exploitable.
What should I do? This issue has been addressed in Google Cloud Customer Care Security Bulletin GCP-2024-040. For instructions and more details, see the following bulletins:
|
Critical |
GCP-2024-006
Published: 2024-2-5
| Description | Severity | Notes |
|---|---|---|
|
When an Apigee API Management proxy connects to a target endpoint or target server, the proxy does not perform hostname validation for the certificate presented by the target endpoint or target server by default. If hostname validation is not enabled using one of the following options, Apigee proxies connecting to a target endpoint or target server may be at risk for a man-in-the-middle attack by an authorized user. For more information, see Configuring TLS from Edge to the backend (Cloud and Private Cloud). Affected Products Apigee proxy deployments on the following Apigee platforms are affected:
What Should I Do? Customers can utilize either of the following options to enable this validation: Option 1 - Add a configuration to your proxy You can enable validation of your target endpoint or target server by adding a <HTTPTargetConnection>
<SSLInfo>
<Enabled>true</Enabled>
<TrustStore>ref://mytruststoreref</TrustStore>
<CommonName>*.example.com</CommonName>
</SSLInfo>
<URL>https://my.example.com/</URL>
</HTTPTargetConnection>If this configuration is present in the Apigee recommends this approach. You can test proxies individually to confirm that validation is performing as intended, with minimal potential disruption to traffic. For more information on testing hostname validation in your proxies and viewing faults, see Using the Trace Tool. Option 2 - Set an organization-level flag You can set an Apigee organization-level flag to enable hostname validation for all deployed proxies and targets in your organization. If the Note: While this option can help you enable the feature across the organization, hostname validation failures can occur if your targets do not present the expected certificates.
Apigee recommends implementing this change in non-production environments first, to ensure that the validation works as intended and does not result in production outages. In the event that hostname validation fails for any targets, the following fault message is returned: {"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"}}} |
High |
GCP-2023-032
Published: 2023-10-13
Updated: 2023-11-03
| Description | Severity | Notes |
|---|---|---|
|
2023-11-03 Update: Added known issue for Apigee Edge for Private Cloud. A Denial-of-Service (DoS) vulnerability was recently discovered in multiple implementations of the HTTP/2 protocol (CVE-2023-44487), including the Apigee Ingress (Cloud Service Mesh) service used by Apigee X and Apigee hybrid. The vulnerability could lead to a DoS of Apigee API management functionality. Affected Products
Unaffected products
What Should I Do?
What Vulnerabilities Are Addressed By These Patches? The vulnerability, CVE-2023-44487, could lead to a DoS of Apigee API management functionality. |
High | CVE-2023-44487 |