CVE-2026-104355 in Server
Résumé
par VulDB • 12/10/2026
Un cluster de pairs connecté peut modifier les espaces de noms locaux d’un cluster Temporal Server, qui ne sont jamais répliqués vers ce pair, car le cluster destinataire applique à ces derniers des mises à jour entrantes de réplication d’espaces de noms. Dans un déploiement multi-clusters, chaque cluster extrait les tâches de réplication depuis les clusters distants qu’un administrateur a enregistrés avec la connexion activée ; le côté émetteur exclut les espaces de noms locaux, mais le côté récepteur n’applique pas la même règle. Lorsqu’une tâche entrante fait référence à un espace de noms existant, le serveur vérifie au maximum que les identifiants d’espace de noms correspondent, puis écrase son état, sa description, son propriétaire, ses paramètres de rétention, ses configurations d’archivage et sa liste de clusters, ainsi que son cluster actif lorsque la tâche porte une version de basculement (failover) supérieure, sans vérifier si l’espace de noms est global. Une partie qui contrôle les réponses d’un pair enregistré, en le faisant fonctionner ou en le compromettant, peut donc modifier n’importe quel espace de nom local dont elle peut fournir le nom et l’identifiant, sans aucun identifiant sur le cluster récepteur : par exemple, en le marquant comme « Deprecated », en faisant du pair son cluster actif, et en réduisant sa période de rétention, après quoi les nouveaux démarrages de Workflow dans cet espace de noms échouent. Les espaces de noms locaux incluent l’espace de noms intégré temporal-system. Les métadonnées d’espaces de noms que le service History actualise à partir du pair lors du traitement des tâches de réplication d’historique passent par la même logique. Un cluster sans aucun cluster distant enregistré avec connexion activée n’est pas exposé.
If you want to get best quality of vulnerability data, you may have to visit VulDB.