Security bulletins

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:

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

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 <CommonName> configuration to the SSLInfo section of the <HTTPTargetConnection> element in your proxy configuration as shown:

<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 <HTTPTargetConnection> element of your proxy configuration, Apigee will use the value specified in <CommonName>for hostname validation. Wildcards may be used in this field.

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 features.strictSSLEnforcement flag is set to true in org properties, hostname validation will be enforced each time the proxy connects to a target endpoint or target server.

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.

  • For Apigee Edge for Public Cloud deployments:

    Contact Google Cloud Support to have the features.strictSSLEnforcement flag set to true in org properties.

    Note: Enabling this flag will enforce the SSL check for all environments in an organization and all proxies deployed within those environments.

  • For Apigee Edge for Private Cloud deployments:

    The features.strictSSLEnforcement flag can be set to true by the organization or system administrator. For more information on setting the flag, see Updating organization properties.

    Note: When updating organization level flags using the Organizations API, make sure to include all existing flags in your POST request to avoid overwriting earlier configuration settings.

    Once the flag is set, each message processor must be individually restarted for the change to take effect. Use the following command:

    apigee-service edge-message-processor restart

    To roll back this change, use the same Organizations API to set the flag to false and then restart each message processor.

    Note: Enabling this flag will enforce the SSL check for all environments in an organization and all proxies deployed within those environments. However, if <IgnoreValidationErrors> is set to true, any validation errors detected will be ignored.

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

  • Apigee X

    Deployments of Apigee X that are accessible through a Google Cloud Network Load Balancer (Layer 4), or a custom layer 4 load balancer, are affected. A hotfix has been applied to all Apigee X instances.

  • Apigee hybrid

    Apigee hybrid instances that allow HTTP/2 requests to reach the Apigee Ingress are affected. Customers should verify if the load balancers fronting their Apigee hybrid ingresses allow for HTTP/2 requests to reach the Apigee Ingress service.

  • Apigee Edge for Private Cloud

    The Edge for Private Cloud router and management server components are exposed to the internet and can potentially be vulnerable. Although HTTP/2 is enabled on the management port of other Edge-specific components of Edge for Private Cloud, none of those components are exposed to the internet. On non-Edge components, like Cassandra, Zookeeper and others, HTTP/2 is not enabled. We recommend that you take the steps in Known issues with Edge for Private Cloud to address the Edge for Private Cloud vulnerability.

Unaffected products

  • Apigee X

    Apigee X instances which are accessed only via Google Cloud Application Load Balancers (Layer 7) are not affected. This includes deployments that have HTTP/2 enabled for gRPC proxies.

  • Google Cloud API Gateway

    Google Cloud API Gateway is not affected.

  • Apigee Edge Cloud

    Apigee Edge Cloud is not impacted by this vulnerability.

What Should I Do?

  • Apigee X

    November 3, 2023 Update: the vulnerability has been addressed via the update to Apigee X instances that was released on October 13, 2023. See the Release notes for details.

  • Apigee hybrid

    Apigee hybrid customers will need to upgrade to one of the following patch versions:

  • Apigee Edge for Private Cloud

    Apigee Edge for Private Cloud users can follow the instructions published in Known issues with Edge for Private Cloud for explicit disablement of HTTP/2 for exposed components.

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