CVE-2025-64504 : Énumération trans-organisationnelle des membres Langfuse

Executive Summary

La CVE-2025-64504 identifie une faille critique dans la logique d’autorisation des API de membre de projet de Langfuse. Cette vulnérabilité permet à tout utilisateur authentifié de contourner les frontières organisationnelles et d’extraire des données utilisateur sensibles (noms et adresses email) d’autres organisations hébergées sur la même instance Langfuse.

Le problème provient d’une divergence entre la manière dont le serveur valide l’organisation demandée et la manière dont il authentifie l’utilisateur. En manipulant le paramètre orgId dans certains endpoints TRPC, un attaquant peut pivoter de sa propre organisation vers toute autre organisation cible, à condition que l’identifiant unique de la cible soit connu ou puisse être deviné.

Analyse Technique

La vulnérabilité se situe au sein de l’implémentation TRPC (TypeScript Remote Procedure Call) des API de membres de projet. Plus précisément, le backend ne parvenait pas à appliquer strictement l’ orgId associé à la session de l’utilisateur authentifié, s’appuyant à la place sur l’ orgId fourni dans le corps de la requête pour les contrôles d’autorisation.

Logique Vulnérable

Dans les versions affectées, les endpoints d’API acceptaient un orgId comme paramètre d’entrée. Le middleware d’autorisation vérifiait que l’utilisateur était authentifié, mais ne validait pas suffisamment que l’utilisateur appartenait réellement à l’organisation identifiée par l’ orgId fourni.

Le serveur exécutait essentiellement la logique suivante :

Vérifier si l’utilisateur possède une session valide $\rightarrow$ Oui.
Récupérer les membres pour l’ orgId fourni $\rightarrow$ Succès.
Retourner les données à l’utilisateur.

L’étape manquante était la vérification : “L’utilisateur authentifié dans ctx.session possède-t-il les permissions pour l’ orgId demandé ?”

Endpoints Vulnérables

Les endpoints TRPC suivants ont été identifiés comme les vecteurs principaux de cette énumération :

/api/trpc/members.allFromProject
/api/trpc/members.allInvitesFromProject

Flux d’Exploitation

Un attaquant peut exploiter cette vulnérabilité en suivant ces étapes :

Authentification : l’attaquant crée ou utilise un compte existant sur l’instance Langfuse cible pour obtenir un jeton de session valide.
Identification de la Cible : l’attaquant identifie l’ orgId de l’organisation cible. Comme les orgId sont souvent des UUID, cela peut nécessiter des fuites provenant d’autres sources ou de la reconnaissance.
Envoi du Payload : l’attaquant envoie une requête POST formatée vers les endpoints TRPC vulnérables, en remplaçant son propre orgId par celui de la cible.
Extraction des Données : le serveur retourne la liste de tous les membres ou des invitations en attente, incluant les noms complets et les adresses email.

Investigation Forensique

D’un point de vue forensique, cette exploitation laisse des traces distinctes dans les logs du serveur web et de l’application.

Analyse des Logs

Les analystes doivent pivoter sur les endpoints TRPC identifiés. Une attaque réussie se caractérise par :

Méthode HTTP : POST
Endpoints : /api/trpc/members.allFromProject ou /api/trpc/members.allInvitesFromProject
Comportement Anomal : Un seul utilisateur authentifié accédant à plusieurs orgId différents dans un court intervalle de temps, ou accédant à un orgId qui ne correspond pas à son affectation organisationnelle principale.

IOCs Comportementaux

Puisqu’il n’y a pas d’IP statiques associées à cette vulnérabilité, la détection doit reposer sur l’analyse comportementale :

Fréquence élevée de requêtes vers les API de membre.
Discrépances entre les métadonnées de session de l’utilisateur et l’ID de la ressource demandée.

Détection

Règle Sigma

La règle Sigma suivante peut être utilisée pour détecter les tentatives d’énumération de membres entre organisations.

title: Langfuse Cross-Organization Member Enumeration
description: Detects potential enumeration of members in Langfuse via project membership APIs by monitoring for mismatched orgIds in TRPC requests.
logsource:
    product: webserver
    service: apache/nginx/etc
detection:
    selection:
        url|contains:
            - '/api/trpc/members.allFromProject'
            - '/api/trpc/members.allInvitesFromProject'
    condition: selection
falsepositives:
    - Legitimate administrative actions (if any)
level: medium

Requête de Hunting (Splunk/ELK)

Pour rechercher des preuves historiques de cette exploitation dans les logs web :

index=web_logs url="*members.allFromProject*" OR url="*members.allInvitesFromProject*" | stats count by client_ip, user_agent, url

Atténuation

Patching

Une mise à jour immédiate vers les versions suivantes est requise :

Branche v2 : mettre à jour vers v2.95.11 ou ultérieur.
Branche v3 : mettre à jour vers v3.124.1 ou ultérieur.

Analyse du Correctif

Les développeurs ont résolu le problème en supprimant la confiance accordée à l’ orgId fourni par l’utilisateur. Les versions corrigées ignorent désormais l’ orgId présent dans l’entrée de la requête et forcent l’utilisation de ctx.session.orgId pour l’autorisation et la requête en base de données. Cela garantit que les utilisateurs ne peuvent accéder qu’aux données appartenant à leur propre contexte organisationnel authentifié.