Le sous-système d'actifs V2 de Plane faisait confiance aux slugs d'espace de travail et aux UUIDs d'actifs sans appliquer les vérifications d'appartenance appropriées, ce qui permettait à un utilisateur authentifié de lire, copier, supprimer et écraser des actifs dans d'autres espaces de travail.
Le sous-système d'actifs V2 de Plane faisait confiance aux slugs d'espaces de travail et aux UUID d'actifs sans appliquer les vérifications d'appartenance appropriées, ce qui permettait à un utilisateur authentifié de lire, copier, supprimer et écraser des actifs dans d'autres espaces de travail.
J'ai découvert ce problème en examinant Plane, la plateforme de gestion de projet open source, avec une question très précise en tête :
Les points de terminaison d'actifs V2 appliquent-ils réellement les limites des espaces de travail, ou font-ils trop confiance aux slugs d'espaces de travail et aux IDs d'actifs fournis par l'attaquant ?
Dans ce cas, la réponse était non.
Le sous-système d'actifs V2 de Plane exposait deux failles d'autorisation liées qui brisaient l'isolation des espaces de travail pour tout utilisateur authentifié :
Cela rendait possible l'exploitation abusive des actifs entre espaces de travail.
Dans ma preuve de concept validée, un utilisateur normal dans l'espace de travail Bravo était capable de :
Ce problème a ensuite été attribué à CVE-2026-46558.
Plane : Plane sur GitHub
CVE : CVE-2026-46558
Cela affectait Plane, qui sur son site officiel est présenté comme étant utilisé par plus de 50 000 équipes dans le monde. Plane met également en avant une forte adoption open source, avec plus de 46 000 étoiles GitHub et plus d'1 000 000 de téléchargements Docker, et présente des organisations telles que Tencent, Accenture, Microsoft et Amazon.
attaquant authentifié dans l'espace de travail B → la route d'actifs V2 au niveau de l'espace de travail fait confiance au slug de l'espace de travail cible et à l'UUID de l'actif sans vérifications d'appartenance appropriées → lecture / patch / suppression pré-signée contre les actifs de l'espace A + la recherche de source de duplication d'actifs fait confiance à l'UUID source téléversé → divulgation, copie, suppression et écrasement de marque entre espaces de travail
Plane est une plateforme de gestion de projet open source utilisée pour gérer :
Cela signifie que son sous-système d'actifs se trouve sur une véritable frontière de confiance.
La question importante ici n'était pas de savoir si Plane prend en charge les téléversements.
La vraie question était :
Plane applique-t-il l'isolation des espaces de travail lorsqu'un utilisateur authentifié fait référence à des actifs appartenant à un autre espace de travail ?
Dans ce cas, ce n'était pas le cas.
Beaucoup de revues d'applications multi-locataires se concentrent d'abord sur les points de terminaison d'administration évidents ou les mises à jour directes des paramètres.
Cela passe à côté d'une classe de bugs très courante et très réelle :
l'accès secondaire aux objets via des sous-systèmes de fichiers ou d'actifs partagés
Les systèmes d'actifs sont faciles à mal faire car ils combinent souvent :
C'est exactement le genre d'endroit où les limites des locataires s'affaiblissent silencieusement.
Ce problème n'était pas lié à la corruption du stockage. Il ne s'agissait pas de S3 lui-même. Il ne s'agissait pas du traitement MIME des téléversements.
C'était une défaillance de la frontière d'autorisation :
C'est suffisant pour créer une véritable vulnérabilité.
Je n'ai pas abordé Plane en fuzzing aveuglément des points de terminaison aléatoires ou en devinant des UUID sans modèle.
L'approche la plus solide était d'identifier d'abord la frontière d'isolation la plus prometteuse.
Pour Plane, c'était le sous-système d'actifs V2.
Pourquoi ?
Parce qu'un système d'actifs partagé devient dangereux lorsque :
C'était la bonne frontière à inspecter.
Et c'était exactement là où vivait le bug.
Il s'agissait en réalité de deux défaillances d'autorisation liées dans le même sous-système.
Les routes d'actifs au niveau de l'espace de travail étaient exposées via :
apps/api/plane/app/urls/asset.py:50-56Les gestionnaires vulnérables se trouvaient dans :
apps/api/plane/app/views/asset/v2.py:314apps/api/plane/app/views/asset/v2.py:379apps/api/plane/app/views/asset/v2.py:400apps/api/plane/app/views/asset/v2.py:409Le problème était simple.
WorkspaceFileAssetEndpoint acceptait un slug d'espace de travail et un UUID d'actif, puis résolvait directement des objets comme :
workspace = Workspace.objects.get(slug=slug)
et :
asset = FileAsset.objects.get(id=asset_id, workspace__slug=slug)
sans d'abord appliquer que l'appelant était effectivement un membre autorisé de cet espace de travail cible.
Cela signifiait que le point de terminaison pouvait encore :
pour les objets d'un autre espace de travail.
La route de duplication d'actifs était mappée via :
apps/api/plane/app/urls/asset.py:100-101La logique vulnérable se trouvait dans :
apps/api/plane/app/views/asset/v2.py:736-780L'espace de travail de destination avait un décorateur d'autorisation. Mais la recherche de l'actif source n'en avait pas.
L'objet source était chargé avec :
original_asset = FileAsset.objects.filter(id=asset_id, is_uploaded=True).first()
Cela signifiait que l'appelant avait seulement besoin :
Il n'y avait aucune vérification que l'appelant appartenait à l'espace de travail source propriétaire de cet actif.
C'est tout le second bug.
La distinction importante est l'impact entre espaces de travail.
Beaucoup de bugs d'autorisation sont minimisés comme :
"il nécessite quand même une connexion"
Cela passe à côté du sujet.
La vraie question n'est pas :
"L'appelant est-il authentifié ?"
La vraie question est :
"L'appelant est-il autorisé pour l'espace de travail spécifique et l'actif spécifique sur lequel l'action est effectuée ?"
Dans Plane, la réponse était non.
Cela transforme ce qui pourrait ressembler à une gestion d'objet ordinaire en un véritable problème de sécurité multi-locataire.
Il y a une nette différence entre :
Ce problème était fermement le second cas.
J'ai validé le problème localement avec Plane Community Edition 1.2.3 en utilisant deux utilisateurs ordinaires dans deux espaces de travail indépendants :
alpha-20260323072017bravo-20260323072017J'ai utilisé Alpha pour créer un actif privé légitime téléversé dans un problème de projet.
L'ID de l'actif privé validé lors de mon exécution était :
6ed6ed62-d1b2-4399-8220-336c01b7d72c
En tant que Bravo, j'ai demandé :
GET /api/assets/v2/workspaces/alpha-20260323072017/6ed6ed62-d1b2-4399-8220-336c01b7d72c/
Plane a répondu :
HTTP/1.1 302 Found
avec une URL de téléchargement pré-signée pour l'actif d'Alpha.
Le hachage du fichier téléchargé correspondait exactement à celui de l'actif privé original d'Alpha :
original: 0d4d070f550ba59ba6b30bee62343cf68ea221af7034f131f72f6409cf5a598e
lecture non autorisée : 0d4d070f550ba59ba6b30bee62343cf68ea221af7034f131f72f6409cf5a598e
Cela a prouvé que le chemin de lecture franchissait avec succès les frontières des espaces de travail.
En tant que Bravo, j'ai ensuite demandé :
POST /api/assets/v2/workspaces/bravo-20260323072017/duplicate-assets/6ed6ed62-d1b2-4399-8220-336c01b7d72c/
Plane a répondu :
HTTP/1.1 200 OK
et a créé un actif dupliqué côté attaquant :
72d51497-ccc1-4546-ba14-28fae5d37dbb
Le SHA-256 du fichier dupliqué correspondait exactement à celui de l'actif original d'Alpha :
0d4d070f550ba59ba6b30bee62343cf68ea221af7034f131f72f6409cf5a598e
Cela a prouvé que le simple UUID de l'actif source suffisait à copier du contenu entre espaces de travail dans un espace de travail contrôlé par l'attaquant.
En tant que Bravo, j'ai ensuite envoyé :
DELETE /api/assets/v2/workspaces/alpha-20260323072017/6ed6ed62-d1b2-4399-8220-336c01b7d72c/
Plane a répondu :
HTTP/1.1 204 No Content
Quand Alpha a ensuite récupéré cet actif, le serveur a renvoyé :
HTTP/1.1 404 Not Found
Cela a prouvé un impact sur l'intégrité entre espaces de travail, pas seulement une divulgation.
En tant que Bravo, j'ai créé un actif WORKSPACE_LOGO contre l'espace de travail d'Alpha via la route d'actifs vulnérable au niveau de l'espace de travail, téléversé un contenu contrôlé par l'attaquant, et l'ai finalisé.
Après cela, les métadonnées de l'espace de travail d'Alpha pointaient vers un actif logo contrôlé par l'attaquant :
c1032f06-3cf5-4f7e-b139-e6976d8c567d
Le hachage du logo final téléchargé correspondait exactement à la charge utile de l'attaquant :
attendu : b9d1ef1de88d61bf55dd18055839bacacb832a752e17a7312547f641113d0e7b
observé : b9d1ef1de88d61bf55dd18055839bacacb832a752e17a7312547f641113d0e7b
Cela a prouvé un chemin d'écrasement visible entre espaces de travail, pas seulement un problème d'accès back-end caché.
N'importe lequel des résultats ci-dessus aurait déjà suffi à justifier un véritable rapport de bug.
Mais valider toute la chaîne était important pour deux raisons.
Cela a montré que le problème ne se limitait pas à une exposition en lecture seule.
La même frontière faible permettait :
Cela rend l'impact beaucoup plus fort qu'un simple IDOR "peut récupérer un fichier".
Cela a montré que les deux chemins de code étaient liés mais indépendamment importants.
Une faille expose les opérations sur les actifs au niveau de l'espace de travail directement. La seconde faille a transformé les UUID d'actifs téléversés en une primitive de fuite réutilisable via la duplication.
Cela rendait l'histoire de sécurité globale beaucoup plus difficile à rejeter.
L'impact d'écrasement le plus visible que j'ai validé était :
WORKSPACE_LOGOC'était délibéré car il est facile à vérifier et démontre une défaillance évidente de l'intégrité entre locataires.
Mais le point de terminaison n'était pas limité aux logos d'espace de travail.
Le flux d'actifs vulnérable au niveau de l'espace de travail acceptait également plusieurs contextes d'entités, notamment :
Cela importait car cela montrait que le bug était structurel, et non lié à un seul champ de marque.
J'ai validé le chemin du logo d'espace de travail directement. Le chemin de code plus large suggérait fortement que des contextes supplémentaires adossés à des actifs étaient exposés à la même erreur d'autorisation.
Ce problème a été raisonnablement classé comme Élevé.
La classification de l'avis était :
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
Cette classification est logique.
L'affirmation n'est pas qu'un attaquant non authentifié peut compromettre Plane à partir de rien. L'affirmation est que tout utilisateur normal authentifié peut franchir les frontières des locataires dans le sous-système d'actifs V2 et effectuer des opérations à fort impact sur les actifs d'autres espaces de travail.
C'est une vulnérabilité d'autorisation multi-locataire réelle et défendable.
Certaines personnes sous-estiment les bugs authentifiés entre locataires parce qu'elles entendent :
"l'attaquant avait déjà besoin d'un compte"
Ce n'est pas une défense sérieuse.
Dans un logiciel multi-espaces de travail, les utilisateurs authentifiés normaux sont censés être contenus dans leur propre périmètre d'autorisation.
Si un utilisateur à faibles privilèges dans l'espace de travail Bravo peut lire, copier, supprimer ou écraser des objets dans l'espace de travail Alpha, alors l'isolation des espaces de travail est brisée.
C'est exactement la propriété de sécurité que l'application est censée protéger.
Surtout dans une plateforme de gestion de projet qui stocke du contenu de travail interne et des actifs de marque, c'est un problème significatif avec un réel impact sur la confidentialité et l'intégrité.
Le problème a été corrigé dans Plane v1.3.1.
Les notes de version de v1.3.1 décrivaient clairement le correctif :
@allow_permission à toutes les méthodes de WorkspaceFileAssetEndpointDuplicateAssetEndpoint aux espaces de travail dont l'appelant est un membre actifC'est la bonne direction de correction car elle aborde les deux propriétés de sécurité défaillantes :
C'est exactement ce dont ce bug avait besoin.
Un bon correctif ici ne consiste pas à mieux cacher les UUID. Il ne s'agit pas de changer la génération d'URL pré-signées.
Il s'agit de rétablir la règle correcte :
le slug d'espace de travail plus l'UUID d'actif ne doivent jamais suffire sans une autorisation liée à l'utilisateur actuel
C'est la partie que le correctif a rétablie.
Ce problème a été signalé privément via GitHub Security Advisories.
Le rapport comprenait :
Le problème a ensuite été publié sous :
L'avis a été publié le 15 mai 2026. Le correctif est sorti dans Plane v1.3.1.
La leçon clé ici est simple :
les sous-systèmes d'actifs partagés sont des frontières d'autorisation, pas seulement des aides au stockage
Beaucoup de développeurs pensent en termes de :
Ces choses sont des détails d'implémentation.
La véritable question de sécurité est :
qui est autorisé à résoudre, muter, copier ou relier cet actif à travers les frontières des locataires ?
Dans Plane, cette frontière n'était pas appliquée de manière cohérente.
C'est le vrai enseignement.
Ce bug renforce également quelque chose d'important dans la révision des applications multi-locataires :
Cette vulnérabilité ne concernait pas un comportement de stockage exotique.
Il s'agissait de se poser la bonne question sur la frontière de confiance.
Dans Plane, un utilisateur authentifié pouvait fournir le slug d'un autre espace de travail et des UUID d'actifs, et le sous-système d'actifs V2 faisait trop confiance à ces identifiants.
C'est pourquoi cela est devenu CVE-2026-46558.
Corrigé dans Plane v1.3.1.