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-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 (Anthos 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 |