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.