Problèmes connus concernant Apigee

Lorsque la variable de flux cachehit est utilisée après la règle LookupCache, en raison de la manière dont les points de débogage sont distribués pour le comportement asynchrone, LookupPolicy renseigne l'objet DebugInfo avant l'exécution du rappel, ce qui entraîne une erreur.

Solution:répétez la procédure (passez un deuxième appel) juste après le premier appel.

Définir PurgeChildEntries dans la règle InvalidateCache devrait supprimer définitivement les valeurs de l'élément KeyFragment uniquement, mais vide l'intégralité du cache.

Solution de contournement:utilisez la règle KeyValueMapOperations pour itérer la gestion des versions du cache et éviter d'avoir à invalider le cache.

Cela peut se produire, par exemple, en cas d'exécutions simultanées d'un pipeline de déploiement CI/CD qui exploitent des révisions différentes. Pour éviter ce problème, évitez de déployer des proxys d'API ou des flux SharedFlow avant la fin du déploiement actuel.

Solution:Évitez les déploiements simultanés de proxys d'API ou de flux SharedFlow.

L'API Analytics Edge peut parfois contenir des données en double pour les appels d'API. Dans ce cas, les totaux affichés pour les appels d'API dans Edge API Analytics sont supérieurs aux valeurs comparables affichées dans les outils d'analyse tiers.

Solution:Exportez les données d'analyse et utilisez le champ gateway_flow_id pour dédupliquer les données.

When you connect an organization to an identity zone, you can no longer access the Edge SSO Zone Administration page from the left navigation bar by selecting Admin > SSO.

Workaround: Navigate to the page directly using the following URL: https://apigee.com/sso

The options TLS_DISABLED_ALGO and TLS_ENABLED_CIPHERS do not function correctly.

Workaround: Follow the steps below to enable specific ciphers for the Edge UI:

1. Open the /opt/apigee/etc/edge-ui.d/SSL.sh config file.
2. Add the property -Djdk.tls.server.cipherSuites with a comma-separated list of cipher suites in IANA notation inside the UI_OPTIONS. For example:

   UI_OPTIONS=" -Dhttp.port=disabled -Dhttps.port=9433 -Dhttps.keyStoreType=JKS -Dhttps.keyStore=/opt/apigee/customer/conf/keystore.jks -Dplay.http.sslengineprovider=services.CustomSSLEngineProvider -Dhttps.keyStorePasswordEncrypted=mypass -Djdk.tls.server.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384"

3. Save your changes to the config file.
4. Restart the Edge UI:

   /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

• Apigee Edge supports OpenAPI Specification 3.0 when you create specifications using the spec editor and publish APIs using SmartDocs on your portal, though a subset of features are not yet supported.

  For example, the following features from the OpenAPI Specification 3.0 are not yet supported:

  • allOf properties for combining and extending schemas
  • Remote references

  If an unsupported feature is referenced in your OpenAPI Specification, in some cases the tools will ignore the feature but still render the API reference documentation. In other cases, an unsupported feature will cause errors that prevent the successful rendering of the API reference documentation. In either case, you will need to modify your OpenAPI Specification to avoid use of the unsupported feature until it is supported in a future release.

  Note: Because the spec editor is less restrictive than SmartDocs when rendering API reference documentation, you may experience different results between the tools.

• When using Try this API in the portal, the Accept header is set to application/json regardless of the value set for consumes in the OpenAPI Specification.
• 138438484: Multiple servers are not supported.

• Simultaneous portal updates (such as page, theme, CSS, or script edits) by multiple users is not supported at this time.
• If you delete an API reference documentation page from the portal, there is no way to recreate it; you'll need to delete and re-add the API product, and regenerate the API reference documentation.
• When configuring the content security policy, it may take up to 15 minutes for changes to fully apply.
• When customizing your portal theme, it may take up to 5 minutes for changes to fully apply.

• Search will be integrated into the integrated portal in a future release.

Une vulnérabilité (CVE-2026-42945) a été divulguée et affecte le ngx_http_rewrite_module dans NGINX. Les outils d'analyse de sécurité peuvent signaler les binaires NGINX inclus dans Apigee Edge pour le cloud privé, car ce module est compilé de manière statique dans NGINX.

Impact sur Apigee Edge pour le cloud privé :

Apigee Edge pour le cloud privé n'est pas affecté par cette vulnérabilité dans sa configuration par défaut. L'exploitabilité de CVE-2026-42945 dépend de modèles de configuration NGINX spécifiques, notamment de l'utilisation de la directive rewrite dans une séquence particulière. Ces modèles ne sont présents dans aucune configuration NGINX standard d'Apigee Edge pour le cloud privé.

Action requise :

• Pour les configurations par défaut d'Apigee Edge pour le cloud privé : aucun correctif, mise à niveau ni modification opérationnelle n'est requis. Les résultats de l'analyse concernant CVE-2026-42945 peuvent être traités comme des faux positifs pour les installations par défaut. Vous pouvez utiliser le texte suivant pour documenter cette exception dans votre système de gestion des failles :

  CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

• Pour les configurations NGINX personnalisées : si vous avez modifié manuellement les fichiers de configuration NGINX dans votre installation Apigee Edge pour le cloud privé (par exemple, sous /opt/nginx), vous devez effectuer l'autocontrôle suivant pour vous assurer que vos personnalisations n'ont pas introduit par inadvertance le modèle vulnérable :
  1. Recherchez la directive de réécriture : sur chaque nœud NGINX, exécutez la commande :

     sudo grep -rnI '^\s*rewrite\b' /opt/nginx

  2. Analysez les résultats :
     • Si la commande ne renvoie aucun résultat, votre système n'est pas affecté.
     • Si des correspondances sont trouvées, examinez chaque instance. La vulnérabilité est présente uniquement si toutes les conditions suivantes sont remplies pour un bloc donné :
       • La directive rewrite est utilisée.
       • Elle est immédiatement suivie d'une autre directive rewrite, if ou set dans le même bloc de configuration.
       • Un groupe de capture PCRE sans nom (par exemple, $1, $2, etc.) est utilisé dans les directives.
       • La chaîne de remplacement dans la directive contient un point d'interrogation (?).
  3. Atténuation (si vulnérable) : si toutes les conditions ci-dessus sont remplies pour une partie de votre configuration personnalisée, atténuez le problème en procédant comme suit :
     • Supprimez le point d'interrogation (?) de la chaîne de remplacement.
     • Utilisez des groupes de capture PCRE nommés au lieu de groupes sans nom.
     • Réévaluez la nécessité des directives enchaînées.

Dans Edge pour le cloud privé 4.53.00 et versions ultérieures, l'interface utilisateur affiche un "pop-up d'avertissement de fin de vie" (EOL). Cet avertissement s'affiche
à plusieurs reprises et ne peut pas être empêché ni réduit en fréquence.

Aucune méthode n'est actuellement disponible pour que les utilisateurs désactivent ou réduisent la fréquence de cet avertissement de fin de vie.

Les appels Java client qui tentent de charger le fournisseur de chiffrement Bouncy Castle à l'aide du nom "BC" peuvent échouer, car le fournisseur par défaut a été remplacé par Bouncy Castle FIPS pour prendre en charge FIPS. Le nouveau nom de fournisseur à utiliser est "BCFIPS".

Les appels Java client qui tentent de charger le fournisseur de chiffrement Bouncy Castle à l'aide du nom "BC" peuvent échouer, car le fournisseur par défaut a été remplacé par Bouncy Castle FIPS pour prendre en charge FIPS. Le nouveau nom de fournisseur à utiliser est "BCFIPS".

Ce problème ne concerne que les utilisateurs de MINT ou ceux qui ont activé MINT dans les installations Edge pour le cloud privé.

Composant concerné : edge-message-processor

Problème : si vous avez activé la monétisation et que vous installez la version 4.52.01 en tant que nouvelle installation ou que vous effectuez une mise à niveau à partir de versions antérieures du cloud privé, vous rencontrerez un problème avec les processeurs de messages. Le nombre de threads ouverts augmentera progressivement, ce qui entraînera une saturation des ressources. L'exception suivante s'affiche dans edge-message-processor system.log :

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Une vulnérabilité par déni de service (DoS) a récemment été détectée dans plusieurs implémentations du protocole HTTP/2 (CVE-2023-44487), y compris dans Apigee Edge pour le cloud privé. La vulnérabilité pourrait entraîner un déni de service de la fonctionnalité de gestion d'API Apigee. Pour en savoir plus, consultez le bulletin de sécurité Apigee GCP-2023-032.

Les composants du routeur et du serveur de gestion Edge for Private Cloud sont exposés sur Internet et peuvent être vulnérables. Bien que HTTP/2 soit activé sur le port de gestion d'autres composants propres à Edge de Edge pour Private Cloud, aucun de ces composants n'est exposé à Internet. Sur les composants autres que Edge, tels que Cassandra, Zookeeper et d'autres, HTTP/2 n'est pas activé. Nous vous recommandons de suivre les étapes ci-dessous pour résoudre la faille Edge pour le cloud privé :

• Étapes pour les versions 4.51.00.11 ou ultérieures d'Edge pour le cloud privé
• Étapes pour les versions d'Edge pour le cloud privé antérieures à la version 4.51.00.11

Suivez ces étapes si vous utilisez les versions 4.51.00.11 ou ultérieures d'Edge pour le cloud privé :

1. Mettez à jour le serveur de gestion :

   1. Sur chaque nœud du serveur de gestion, ouvrez /opt/apigee/customer/application/management-server.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés :

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant du serveur de gestion :

      apigee-service edge-management-server restart

2. Mettez à jour le processeur de messages :

   1. Sur chaque nœud du processeur de messages, ouvrez /opt/apigee/customer/application/message-processor.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés :

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant du processeur de messages :

      apigee-service edge-message-processor restart

3. Mettez à jour le routeur :

   1. Sur chaque nœud du routeur, ouvrez /opt/apigee/customer/application/router.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés :

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant du processeur de messages :

      apigee-service edge-router restart

4. Mettez à jour QPID :

   1. Sur chaque nœud QPID, ouvrez /opt/apigee/customer/application/qpid-server.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés :

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant du processeur de messages :

      apigee-service edge-qpid-server restart

5. Mettez à jour Postgres :

   1. Sur chaque nœud Postgres, ouvrez /opt/apigee/customer/application/postgres-server.properties.
   2. Ajoutez la ligne suivante au fichier de propriétés :

      conf_webserver_http2.enabled=false

   3. Redémarrez le composant du processeur de messages :

      apigee-service edge-postgres-server restart

Suivez ces étapes si vous utilisez des versions d'Edge pour le cloud privé antérieures à la version 4.51.00.11 :

1. Mettez à jour le serveur de gestion :

   1. Sur chaque nœud du serveur de gestion, ouvrez /opt/apigee/customer/application/management-server.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés :

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant du serveur de gestion :

      apigee-service edge-management-server restart

2. Mettez à jour le processeur de messages :

   1. Sur chaque nœud du processeur de messages, ouvrez /opt/apigee/customer/application/message-processor.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés :

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant du processeur de messages :

      apigee-service edge-message-processor restart

3. Mettez à jour le routeur :

   1. Sur chaque nœud du routeur, ouvrez /opt/apigee/customer/application/router.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés :

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant du processeur de messages :

      apigee-service edge-router restart

4. Mettez à jour QPID :

   1. Sur chaque nœud QPID, ouvrez /opt/apigee/customer/application/qpid-server.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés :

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant du processeur de messages :

      apigee-service edge-qpid-server restart

5. Mettez à jour Postgres :

   1. Sur chaque nœud Postgres, ouvrez /opt/apigee/customer/application/postgres-server.properties.
   2. Ajoutez les deux lignes suivantes au fichier de propriétés :

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Redémarrez le composant du processeur de messages :

      apigee-service edge-postgres-server restart

Apigee-postgresql rencontre des problèmes lors de la mise à niveau d'Edge pour le cloud privé version 4.50 ou 4.51 vers la version 4.52. Les problèmes se produisent principalement lorsque le nombre de tables est supérieur à 500.

Vous pouvez vérifier le nombre total de tables dans Postgres en exécutant la requête SQL ci-dessous :

select count(*) from information_schema.tables

Solution : lorsque vous mettez à jour Apigee Edge 4.50.00 ou 4.51.00 vers la version 4.52.00, veillez à effectuer l'étape préliminaire avant de mettre à niveau Apigee-postgresql.

149245401 : les paramètres du pool de connexions LDAP pour JNDI configurés via la ressource LDAP ne sont pas reflétés, et les valeurs par défaut de JNDI entraînent des connexions à usage unique à chaque fois. Par conséquent, les connexions sont ouvertes et fermées à chaque fois pour un usage unique, ce qui crée un grand nombre de connexions par heure au serveur LDAP.

Solution :

Pour modifier les propriétés du pool de connexions LDAP, procédez comme suit pour définir une modification globale dans toutes les règles LDAP.

1. Créez un fichier de propriétés de configuration s'il n'existe pas déjà :

   /opt/apigee/customer/application/message-processor.properties

2. Ajoutez les éléments suivants au fichier (remplacez les valeurs des propriétés Java Naming and Directory Interface (JNDI) en fonction de vos exigences de configuration de ressources LDAP).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. Assurez-vous que le fichier /opt/apigee/customer/application/message-processor.properties appartient à apigee:apigee.
4. Redémarrez chaque processeur de messages.

Pour vérifier que les propriétés JNDI de votre pool de connexions prennent effet, vous pouvez effectuer un tcpdump pour observer le comportement du pool de connexions LDAP au fil du temps.

139051927 : les latences élevées du traitement des proxys détectées dans le processeur de messages affectent tous les proxys d'API. Les symptômes incluent des délais de 200 à 300 ms dans les temps de traitement par rapport aux temps de réponse normaux de l'API et peuvent se produire de manière aléatoire, même avec un faible nombre de TPS. Cela peut se produire lorsque le nombre de serveurs cibles auxquels un processeur de messages se connecte est supérieur à 50.

Cause principale les processeurs de messages conservent un cache qui mappe l'URL du serveur cible à l'objet HTTPClient pour les connexions sortantes aux serveurs cibles. Par défaut, ce paramètre est défini sur 50, ce qui peut être trop faible pour la plupart des déploiements. Lorsqu'un déploiement comporte plusieurs combinaisons d'organisations/d'environnements dans une configuration, et qu'il comporte un grand nombre de serveurs cibles qui dépassent 50 au total, les URL des serveurs cibles sont constamment supprimées du cache, ce qui entraîne des latences.

Validation : pour déterminer si la suppression de l'URL du serveur cible est à l'origine du problème de latence, recherchez le mot clé "onEvict" ou "Eviction" dans les journaux système du processeur de messages. Leur présence dans les journaux indique que les URL des serveurs cibles sont supprimées du cache HTTPClient, car la taille du cache est trop petite.

Solution : pour les versions 19.01 et 19.06 d'Edge pour le cloud privé, vous pouvez modifier et configurer le cache HTTPClient : /opt/apigee/customer/application/message-processor.properties

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Redémarrez ensuite le processeur de messages. Effectuez les mêmes modifications pour tous les processeurs de messages.

La valeur 500 est un exemple. La valeur optimale pour votre configuration doit être supérieure à le nombre de serveurs cibles auxquels le processeur de messages se connecte. La définition d'une valeur plus élevée pour cette propriété n'a aucun effet secondaire, et le seul effet serait une amélioration des temps de traitement des requêtes de proxy du processeur de messages.

Remarque : La version 50.00 d'Edge pour le cloud privé a le paramètre par défaut de 500.

157933959 : les insertions et mises à jour simultanées dans le même mappage de clés-valeurs (KVM) limité au niveau de l'organisation ou de l'environnement entraînent des données incohérentes et des mises à jour perdues.

Remarque : Cette limitation ne s'applique qu'à Edge pour le cloud privé. Edge pour le cloud public et Hybrid ne présentent pas cette limitation.

Pour contourner ce problème dans Edge pour le cloud privé, créez le KVM au niveau du champ d'application apiproxy scope.