Nous avons réorganisé notre structure de navigation pour l'aligner directement sur vos workflows opérationnels. Pour en savoir plus, consultez les notes de version de Google SecOps.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Bulletins de sécurité

Cette page fournit tous les bulletins de sécurité liés à Google Security Operations.

GCP-2025-075

Date de publication : 07-12-2025

Description

Description Gravité Remarques

Description	Gravité	Remarques
Une faille dans la fonctionnalité d'intégrations personnalisées de Google Security Operations SOAR pouvait permettre à un utilisateur authentifié disposant d'un rôle IDE d'exécuter du code à distance sur le serveur. Cette faille était due à une validation insuffisante du code du package Python, ce qui permettait à un attaquant d'importer un package avec un fichier `setup.py` malveillant. Ce fichier pouvait ensuite être exécuté lors de l'installation, compromettant ainsi le serveur. Que dois-je faire ? Aucune action n'est requise de la part du client. Tous les clients ont été automatiquement mis à niveau vers la version corrigée : 6.3.64 ou ultérieure.	Élevée	CVE-2025-13428

Une faille dans la fonctionnalité d'intégrations personnalisées de Google Security Operations SOAR pouvait permettre à un utilisateur authentifié disposant d'un rôle IDE d'exécuter du code à distance sur le serveur. Cette faille était due à une validation insuffisante du code du package Python, ce qui permettait à un attaquant d'importer un package avec un fichier setup.py malveillant. Ce fichier pouvait ensuite être exécuté lors de l'installation, compromettant ainsi le serveur.

Que dois-je faire ?

Aucune action n'est requise de la part du client. Tous les clients ont été automatiquement mis à niveau vers la version corrigée : 6.3.64 ou ultérieure.

Élevée

CVE-2025-13428

GCP-2025-049

Date de publication : 04-09-2025

Description

Description	Gravité	Remarques
Une faille critique a été détectée dans les versions 6.3.54.0 et 6.3.53.2 de Google Security Operations SOAR. Un utilisateur authentifié disposant des autorisations nécessaires pour importer des fichiers ZIP (par exemple, lors de l'importation de cas d'utilisation) pouvait importer une archive ZIP capable d'écrire des fichiers dans des emplacements arbitraires du système de fichiers du serveur. Le système d'extraction des fichiers des archives ZIP ne pouvait pas empêcher l'écriture des fichiers de l'archive en dehors de leur dossier de destination prévu. Il s'agit également d'une faille de traversée de répertoire ou de Zip Slip vulnérabilité. Que dois-je faire ? Aucune action n'est requise de la part du client. Tous les clients ont été automatiquement mis à niveau vers la version corrigée ou ultérieure : 6.3.54.1 ou 6.3.53.3. Quelles failles sont corrigées ? Un attaquant pouvait exploiter cette faille pour écraser des fichiers d'application fichiers. En écrasant un fichier JavaScript utilisé par la fonctionnalité de génération de rapports, un attaquant pouvait exécuter du code à distance sur l'instance Google SecOps SOAR. L'attaquant pouvait exécuter son propre code sur le serveur.	Élevée	CVE-2025-9918

Gravité

Remarques

Une faille critique a été détectée dans les versions 6.3.54.0 et 6.3.53.2 de Google Security Operations SOAR. Un utilisateur authentifié disposant des autorisations nécessaires pour importer des fichiers ZIP (par exemple, lors de l'importation de cas d'utilisation) pouvait importer une archive ZIP capable d'écrire des fichiers dans des emplacements arbitraires du système de fichiers du serveur.

Le système d'extraction des fichiers des archives ZIP ne pouvait pas empêcher l'écriture des fichiers de l'archive en dehors de leur dossier de destination prévu. Il s'agit également d'une faille de traversée de répertoire ou de Zip Slip vulnérabilité.

Que dois-je faire ?

Aucune action n'est requise de la part du client. Tous les clients ont été automatiquement mis à niveau vers la version corrigée ou ultérieure : 6.3.54.1 ou 6.3.53.3.

Quelles failles sont corrigées ?

Un attaquant pouvait exploiter cette faille pour écraser des fichiers d'application fichiers. En écrasant un fichier JavaScript utilisé par la fonctionnalité de génération de rapports, un attaquant pouvait exécuter du code à distance sur l'instance Google SecOps SOAR. L'attaquant pouvait exécuter son propre code sur le serveur.

Élevée

CVE-2025-9918

GCP-2023-028

Date de publication : 19-09-2023

Mise à jour : 29-05-2024

Description

Description	Gravité	Remarques
Mise à jour du 29-05-2024 : les nouveaux flux n'utilisent plus le compte de service partagé, mais il reste actif pour les flux existants afin d'éviter les interruptions de service. Les modifications apportées à la source dans les anciens flux sont bloquées pour éviter toute utilisation abusive du compte de service partagé. Les clients peuvent continuer à utiliser leurs anciens flux normalement, à condition de ne pas modifier la source. Les clients peuvent configurer Google SecOps pour ingérer des données à partir de buckets Cloud Storage appartenant à des clients à l'aide d'un flux d'ingestion. Jusqu'à récemment, Google SecOps fournissait un compte de service partagé que les clients utilisaient pour accorder des autorisations au bucket. Il était possible de configurer l'instance Google SecOps d'un client pour ingérer des données à partir du bucket Cloud Storage d'un autre client. Après avoir effectué une analyse d'impact, nous n'avons détecté aucune exploitation actuelle ou antérieure de cette faille. La faille était présente dans toutes les versions de Google SecOps antérieures au 19 septembre 2023. Que dois-je faire ? Depuis le 19 septembre 2023, Google SecOps a été mis à jour pour corriger cette faille. Aucune action n'est requise de la part du client. Quelles failles sont corrigées ? Auparavant, Google SecOps fournissait un compte de service partagé que les clients utilisaient pour accorder des autorisations à un bucket. Étant donné que différents clients ont accordé la même autorisation de compte de service Google SecOps à leur bucket, il existait un vecteur d'exploitation qui permettait au flux d'un client d'accéder au bucket d'un autre client lors de la création ou de la modification d'un flux. Ce vecteur d'exploitation nécessitait la connaissance de l'URI du bucket. Désormais, lors de la création ou de la modification d'un flux, Google SecOps utilise des comptes de service uniques pour chaque client.	Élevée

Gravité

Remarques

Mise à jour du 29-05-2024 : les nouveaux flux n'utilisent plus le compte de service partagé, mais il reste actif pour les flux existants afin d'éviter les interruptions de service. Les modifications apportées à la source dans les anciens flux sont bloquées pour éviter toute utilisation abusive du compte de service partagé. Les clients peuvent continuer à utiliser leurs anciens flux normalement, à condition de ne pas modifier la source.

Les clients peuvent configurer Google SecOps pour ingérer des données à partir de buckets Cloud Storage appartenant à des clients à l'aide d'un flux d'ingestion. Jusqu'à récemment, Google SecOps fournissait un compte de service partagé que les clients utilisaient pour accorder des autorisations au bucket. Il était possible de configurer l'instance Google SecOps d'un client pour ingérer des données à partir du bucket Cloud Storage d'un autre client. Après avoir effectué une analyse d'impact, nous n'avons détecté aucune exploitation actuelle ou antérieure de cette faille. La faille était présente dans toutes les versions de Google SecOps antérieures au 19 septembre 2023.

Que dois-je faire ?

Depuis le 19 septembre 2023, Google SecOps a été mis à jour pour corriger cette faille. Aucune action n'est requise de la part du client.

Quelles failles sont corrigées ?

Auparavant, Google SecOps fournissait un compte de service partagé que les clients utilisaient pour accorder des autorisations à un bucket. Étant donné que différents clients ont accordé la même autorisation de compte de service Google SecOps à leur bucket, il existait un vecteur d'exploitation qui permettait au flux d'un client d'accéder au bucket d'un autre client lors de la création ou de la modification d'un flux. Ce vecteur d'exploitation nécessitait la connaissance de l'URI du bucket. Désormais, lors de la création ou de la modification d'un flux, Google SecOps utilise des comptes de service uniques pour chaque client.

Élevée