La section suivante décrit les bulletins de sécurité liés à Apigee.
Pour recevoir les derniers bulletins de sécurité, effectuez l'une des opérations suivantes :
- Ajoutez l'URL de cette page à votre lecteur de flux.
- Ajoutez directement l'URL du flux à votre lecteur de flux :
https://cloud.google.com/feeds/apigee-security-bulletins.xml.
GCP-2026-010
Publié : 2026-02-13
Description
| Description | Gravité | Remarques |
|---|---|---|
|
Une faille a été identifiée dans la plate-forme Apigee. Elle aurait pu permettre à une personne malveillante disposant d'autorisations d'administrateur ou de développeur dans son propre environnement Apigee d'élever ses privilèges et d'accéder à des données multi-locataires. Plus précisément, une faille dans la technologie de bac à sable d'Apigee X permettait d'utiliser un point de terminaison link-local pour accéder aux jetons de compte de service (P4SA) dans un projet de locataire client. En exploitant cette identité, un pirate informatique pourrait théoriquement lire les métadonnées d'analyse ou falsifier les enregistrements de surveillance internes dans d'autres organisations (locataires) Apigee. Que dois-je faire ? Aucune action n'est requise de la part du client. Google a mis en place une stratégie d'atténuation à plusieurs niveaux pour résoudre ce problème :
Google a confirmé que, bien que les journaux de surveillance internes soient théoriquement accessibles, ils ne sont utilisés qu'en interne par Google et leur exposition n'a pas d'incidence sur la sécurité ni l'intégrité des données client dans Apigee. |
Élevée | CVE-2025-13292 |
GCP-2025-023
Date de publication : 05-05-2025
| Description | Gravité | Remarques | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Ce bulletin traite des failles de sécurité potentielles qui pourraient être exploitées si elles n'étaient pas corrigées dans les règles JavaCallout et PythonScript qui ont été découvertes et traitées. Ces règles peuvent entraîner une exécution de code à distance (RCE) et une élévation des privilèges non autorisées dans l'environnement d'exécution Apigee. Ces failles potentielles nécessitent un accès interne autorisé (utilisateurs ayant le privilège de déployer des proxys) pour être exploitées. Ces failles potentielles proviennent d'un sandboxing insuffisant pour des scénarios tels que l'accès par réflexion et l'usurpation d'objets d'autorisation pour contourner le gestionnaire de sécurité. Produits concernés L'impact est limité aux règles JavaCallout et PythonScript. Cela inclut les déploiements sur les plates-formes Apigee suivantes :
Que dois-je faire ? Pour chaque produit concerné, procédez comme suit : ApigeeAucune action n'est requise de la part des clients qui utilisent la version Google Cloud d'Apigee. Des correctifs de failles ont été appliqués à la version 1-14-0-apigee-8 d'Apigee. Si l'équipe chargée des versions n'est pas en mesure de déployer la version pour vos organisations, un TAM ou un représentant de l'assistance vous contactera pour corriger les bundles de proxy JavaCallout concernés. Apigee hybridVous devez passer à l'une des versions de correctif de sécurité suivantes :
|
Élevée |
Apigee Edge for Public Cloud
Aucune action n'est requise de la part des clients Apigee Edge. Des correctifs ont été appliqués à la dernière version d'exécution Edge. Si vous êtes un client qui ne peut pas être mis à jour vers la dernière version d'Edge en raison d'actions en attente connues, un représentant du service client vous contactera.
Apigee Edge pour le cloud privé
Si vous utilisez Edge pour Private Cloud, vous devez examiner vos règles JavaCallout et PythonScript pour vous assurer d'utiliser du code et des bibliothèques provenant de sources fiables. Les modifications apportées à ces règles nécessitent un accès interne autorisé (utilisateurs autorisés à déployer des proxys). Nous vous recommandons donc d'auditer vos autorisations pour vous assurer que seuls les utilisateurs de confiance conservent cet accès. Des correctifs de failles ont été appliqués aux versions 4.52.02 et 4.53.00 d'Edge pour le cloud privé.
GCP-2024-040
Publié : 2024-07-02
Ce bulletin inclut des informations spécifiques à chacun de ces produits Apigee :
Cloud public Edge
| Description | Gravité | Remarques |
|---|---|---|
|
Une faille d'exécution de code à distance, CVE-2024-6387, a été récemment découverte dans OpenSSH. La faille exploite une condition de concurrence permettant d'accéder à une interface système distante, qui permet ainsi aux pirates informatiques d'obtenir un accès racine aux nœuds GKE. Au moment de la publication, Apigee Edge pour le cloud public n'est pas exploitable et des mesures d'atténuation sont en place. Même si cette CVE n'est pas exploitable, Apigee mettra à niveau les charges de travail pour résoudre la CVE ci-dessus. Que dois-je faire ? Aucune action n'est requise de la part des utilisateurs Apigee. Les charges de travail seront corrigées dans les prochains jours. Le bulletin de sécurité sera mis à jour une fois la correction terminée. |
Critique |
Cloud privé Edge
| Description | Gravité | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Une faille d'exécution de code à distance, CVE-2024-6387, a été récemment découverte dans OpenSSH. La faille exploite une condition de concurrence permettant d'accéder à une interface système distante, qui permet ainsi aux pirates informatiques d'obtenir un accès racine aux nœuds de VM. Les clients Edge Private Cloud possèdent et gèrent les VM/hôtes physiques sur lesquels Edge Private Cloud est déployé.
Que dois-je faire ? Examinez la version d'OpenSSH en exécutant la commande |
Critique |
Edge Microgateway
| Description | Gravité | Remarques | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Une faille d'exécution de code à distance, CVE-2024-6387, a été récemment découverte dans OpenSSH. La faille exploite une condition de concurrence permettant d'accéder à une interface système distante, qui permet ainsi aux pirates informatiques d'obtenir un accès racine aux nœuds de VM. Les clients Edge Microgateway possèdent et gèrent les VM/hôtes physiques sur lesquels Edge Microgateway est déployé.
Que dois-je faire ? Veuillez vérifier la version d'OpenSSH en exécutant les commandes |
Critique |
Apigee
| Description | Gravité | Remarques |
|---|---|---|
|
Une faille d'exécution de code à distance, CVE-2024-6387, a été récemment découverte dans OpenSSH. La faille exploite une condition de concurrence permettant d'accéder à une interface système distante, qui permet ainsi aux pirates informatiques d'obtenir un accès racine aux nœuds GKE. Au moment de la publication, Apigee n'est pas exploitable et des mesures d'atténuation sont en place. Même si cette CVE n'est pas exploitable, Apigee mettra à niveau les charges de travail pour résoudre le problème CVE-2024-6387. Que dois-je faire ? Aucune action n'est requise de la part des utilisateurs Apigee. Les charges de travail seront corrigées dans les prochains jours. Le bulletin de sécurité sera mis à jour une fois la correction terminée. Remarque : Si des groupes d'instance gérés sont déployés dans un projet client pour l'équilibrage de charge Northbound, en particulier InternalRouting (VPC) et ExternalRouting (MIG), vérifiez la version OpenSSH installée dessus. Si la version est vulnérable au CVE, mettez à jour vous-même OpenSSH vers la version 9.8p1 publiée le 1er juillet 2024, car Apigee ne gère pas ces MIG. |
Critique |
Apigee hybrid
| Description | Gravité | Remarques | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Une faille d'exécution de code à distance, CVE-2024-6387, a été récemment découverte dans OpenSSH. La faille exploite une condition de concurrence permettant d'accéder à une interface système distante, qui permet ainsi aux pirates informatiques d'obtenir un accès racine aux nœuds GKE. Au moment de la publication, les images hybrides ne sont pas vulnérables, car OpenSSH n'est inclus dans aucune des images de conteneur hybrides. Toutefois, si l'OS de votre hôte/nœud GKE exécute les versions vulnérables d'OpenSSH ci-dessous, vos clusters hybrides seront exploitables.
Que dois-je faire ? Ce problème a été résolu dans le bulletin de sécurité GCP-2024-040 de Google Cloud Customer Care. Pour en savoir plus et obtenir des instructions, consultez les bulletins suivants :
|
Critique |
GCP-2024-006
Publié : 2024-2-5
| Description | Gravité | Notes |
|---|---|---|
|
Lorsqu'un proxy de gestion d'API Apigee se connecte à un point de terminaison cible ou à un serveur cible, le proxy n'effectue pas de validation du nom d'hôte pour le certificat présenté par défaut par le point de terminaison cible ou le serveur cible. Si la validation du nom d'hôte n'est pas activée à l'aide de l'une des options suivantes, les proxys Apigee se connectant à un point de terminaison cible ou à un serveur cible peuvent courir le risque d'une attaque MITM ("man in the middle") par un utilisateur autorisé. Pour en savoir plus, consultez la page Configurer TLS de la périphérie au backend (cloud et cloud privé). Produits concernés Les déploiements de proxy Apigee sur les plates-formes Apigee suivantes sont concernés :
Que dois-je faire ? Les clients peuvent utiliser l'une des options suivantes pour activer cette validation : Option 1 : Ajouter une configuration à votre proxy Vous pouvez activer la validation de votre point de terminaison cible ou de votre serveur cible en ajoutant une configuration <HTTPTargetConnection>
<SSLInfo>
<Enabled>true</Enabled>
<TrustStore>ref://mytruststoreref</TrustStore>
<CommonName>*.example.com</CommonName>
</SSLInfo>
<URL>https://my.example.com/</URL>
</HTTPTargetConnection>Si cette configuration est présente dans l'élément Apigee recommande cette approche. Vous pouvez tester les proxys individuellement pour vérifier que la validation fonctionne comme prévu, en minimisant la perturbation potentielle du trafic. Pour en savoir plus sur la manière de tester la validation du nom d'hôte dans vos proxys et l'affichage des erreurs, consultez la page Utiliser l'outil Trace. Option 2 : Définir une option au niveau de l'organisation Vous pouvez définir une option au niveau de l'organisation Apigee pour activer la validation du nom d'hôte pour tous les proxys et cibles déployés dans votre organisation. Si l'option Remarque : Bien que cette option puisse vous aider à activer la fonctionnalité dans l'ensemble de l'organisation, des échecs de validation du nom d'hôte peuvent se produire si vos cibles ne présentent pas les certificats attendus.
Apigee recommande d'implémenter cette modification en premier lieu dans des environnements hors production, pour s'assurer que la validation fonctionne comme prévu et n'entraîne pas d'interruptions en production. Si la validation du nom d'hôte échoue pour une cible, le message d'erreur suivant est renvoyé : {"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"}}} |
Élevé |
GCP-2023-032
Publié : 2023-10-13
Mise à jour : 03-11-2023
| Description | Gravité | Remarques |
|---|---|---|
|
Mise à jour du 03/11/2023 : ajout du problème connu pour Apigee Edge pour le cloud privé. Une faille 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 le service Apigee Ingress (Cloud Service Mesh) utilisé par Apigee X et Apigee hybrid. La faille pourrait entraîner un déni de service de la fonctionnalité de gestion d'API Apigee. Produits concernés
Produits non concernés
Que dois-je faire ?
Quelles failles ces correctifs permettent-ils de résoudre ? La faille, CVE-2023-44487, peut entraîner une attaque DoS de la fonctionnalité de gestion des API Apigee. |
Élevé | CVE-2023-44487 |