ProjectSend : les liens publics qu'un client n'aurait jamais dû voir

Beaucoup de cabinets, d'agences et de petites entreprises échangent des documents avec leurs clients via un portail : le client dépose ses fichiers, l'équipe les vérifie et les partage parfois avec des tiers au moyen d'un lien public. Qui peut créer ce lien, et qui peut le voir, relève d'une décision précise. Dans ProjectSend, un client qui n'a pas le droit de publier des fichiers ne devrait pas pouvoir diffuser de lien public. Pourtant, en ouvrant la page de modification de l'un de ses fichiers, il pouvait lire en entier les liens créés par l'équipe sur ce fichier, et même les supprimer.

C'est le défaut décrit dans l'avis de sécurité GHSA-g9g5-qxp7-f7v2, publié le 8 novembre 2026 et corrigé dans ProjectSend 2.8.0. C'est nous qui l'avons signalé : la découverte revient à Liam Giannini (Liam-G sur GitHub), hacker éthique et cofondateur de Webcracy. Nous remercions les mainteneurs de ProjectSend, qui ont intégré la correction dans la version suivant notre signalement.

Webcracy et la cybersécurité

En plus de développer des sites et des applications, Webcracy s'occupe de cybersécurité : tests d'intrusion, revue de code, analyse des configurations et recherche sur les logiciels open source que nous utilisons, nous et nos clients. Liam travaille comme hacker éthique : il cherche les failles avec les méthodes d'un attaquant, mais pour les faire corriger. Il les signale en privé aux mainteneurs et ne les rend publiques qu'une fois la correction disponible. C'est la même procédure de divulgation responsable que nous avons suivie pour exarch et pour FreeScout.

Ce que sont les liens publics dans ProjectSend

ProjectSend est l'une des applications open source les plus populaires et les plus répandues pour partager des fichiers avec ses clients depuis son propre serveur : elle existe depuis 2014, compte plus de 2'000 étoiles sur GitHub, et l'image Docker de LinuxServer.io à elle seule dépasse les 4,9 millions de téléchargements. Elle est écrite en PHP, avec Laravel. Pour un projet aussi répandu, une faille n'est jamais le problème de quelques-uns seulement. Chaque fichier peut avoir un ou plusieurs liens publics, des adresses du type /s/{token} que quiconque les possède peut ouvrir sans se connecter. Le jeton fonctionne comme une clé : qui a le lien entre, sans autre vérification. C'est pourquoi la possibilité d'en créer un est une autorisation à part, upload_public, que l'administrateur peut accorder ou refuser à chaque rôle.

ProjectSend avait déjà une règle claire sur qui voit quoi : dans le portail, un client ne voit que les liens publics qu'il a créés lui-même. Si l'équipe crée un lien sur un fichier déposé par le client, par exemple pour l'envoyer à un consultant externe, ce lien n'apparaît pas dans la liste des fichiers du client. Le code appliquait cette règle de manière explicite et il existait même un test automatisé qui la vérifiait.

Là où la règle n'était pas appliquée

Le problème se trouvait à deux endroits qui appliquaient une règle plus faible au même objet.

Le premier était l'éditeur de fichier. Un client disposant de l'autorisation edit_files peut modifier les fichiers qu'il a déposés. Lorsqu'il ouvrait la page de modification, le serveur vérifiait à juste titre qu'il pouvait modifier ce fichier, mais envoyait ensuite au navigateur tous les liens publics associés, sans filtrer par auteur. Pour chaque lien figuraient l'adresse complète avec le jeton, l'identifiant et l'adresse permettant de le révoquer. Il suffisait de regarder les données de la page pour obtenir le lien créé par l'équipe.

Le second était la révocation. La requête qui supprime un lien ne vérifiait, là encore, que le droit de modification sur le fichier, et non l'auteur du lien. Le client pouvait donc supprimer un lien de l'équipe, et la personne qui l'avait reçu se retrouvait soudain sans accès.

Dans les deux cas l'erreur est la même, et elle est très courante : confondre l'autorisation sur une ressource avec l'autorisation sur tout ce qui y est rattaché. Pouvoir modifier un fichier ne signifie pas pouvoir gérer chaque lien que d'autres ont créé sur ce fichier.

Quelle gravité

Pas d'accès aux fichiers des autres, pas de privilèges de l'équipe : le problème ne concerne que les fichiers déposés par le client lui-même, et il faut que l'équipe y ait créé un lien public. Mais dans ce périmètre, deux décisions de l'équipe sautaient. Un client à qui l'on avait refusé le droit de publier pouvait malgré tout diffuser à n'importe qui un lien public actif, qui ouvre le fichier sans connexion. Et il pouvait révoquer un lien que l'équipe avait donné à des tiers, interrompant un partage décidé par d'autres. L'avis classe le problème en gravité modérée, dans les catégories CWE-862, autorisation manquante, et CWE-200, exposition d'informations sensibles. Dans notre signalement, nous avions estimé un score CVSS 3.1 de 5.4.

Les versions concernées vont de la 2.5.0 à la 2.7.1.

Comment nous l'avons vérifié

Le problème est apparu en lisant le code de ProjectSend 2.7.1 et en comparant les différents chemins qui mènent aux mêmes liens : la liste du portail, l'éditeur de fichier et la révocation. La liste filtrait par auteur, les deux autres non.

Pour le confirmer, Liam a écrit quatre tests automatisés avec les outils de test déjà présents dans le projet, exécutés dans un conteneur Docker isolé, avec une base de données en mémoire et des comptes fictifs. Les tests vérifient que l'éditeur expose le lien de l'équipe, que le client peut le révoquer, que la liste du portail, elle, le masque correctement, et que le lien obtenu fonctionne même sans être connecté. Deux tests existants ont servi de contrôle : un client sans upload_public ne peut pas créer de liens publics, ni révoquer des liens sur des fichiers qui ne sont pas les siens. Le comportement a également été confirmé sur la branche principale de développement.

La correction dans la 2.8.0

Les notes de version de la 2.8.0, publiée le 29 octobre, le disent en une ligne : l'éditeur de fichier d'un client n'affiche et ne révoque plus que les liens publics créés par ce client. C'est la même règle que le portail appliquait déjà, étendue aux deux endroits où elle manquait. Les autorisations de l'équipe restent inchangées.

La même version corrige plusieurs autres problèmes d'autorisation : des jetons d'API qui pouvaient faire plus que ce qui leur était accordé, des archives zip préparées qui restaient téléchargeables après la perte de l'accès à un fichier, des envois qui atterrissaient dans des dossiers auxquels l'utilisateur n'avait plus droit, et d'autres encore. Cela suffit déjà pour ne pas repousser la mise à jour.

Que faire si vous utilisez ProjectSend

Si votre installation se situe entre la 2.5.0 et la 2.7.1, mettez-la à jour vers la 2.8.0 ou une version ultérieure. Lisez d'abord la section « do these yourself » des notes de version : certains jetons d'API doivent être recréés pour conserver les mêmes fonctions, et les modèles d'e-mail personnalisés en Markdown s'affichent désormais en texte brut.

Après la mise à jour, il vaut aussi la peine de passer en revue les liens publics créés par l'équipe sur les fichiers déposés par les clients. Si un lien a été partagé avec des personnes externes et que le client n'aurait pas dû le connaître, la mise à jour ne le rend pas secret a posteriori : la solution consiste à le révoquer et à en créer un nouveau. Et si un lien de l'équipe a disparu sans raison apparente, vous connaissez maintenant l'une des causes possibles.

Plus généralement, un portail client contient des contrats, des factures, des pièces d'identité. Il mérite des mises à jour régulières et une révision périodique des rôles : qui a edit_files, qui a upload_public, et si ces personnes en ont vraiment besoin.

Pourquoi nous faisons de la recherche sur les logiciels open source

Nous recommandons souvent des outils open source auto-hébergés comme ProjectSend : les données restent sur votre propre serveur, il n'y a pas de redevance par utilisateur, le code peut être lu. Mais encore faut-il que quelqu'un le lise vraiment, avec l'œil de celui qui cherche l'endroit où deux parties du programme appliquent des règles différentes à la même chose. Ce genre de problème n'apparaît pas en utilisant l'application normalement : il apparaît en comparant le code. Les signaler aux mainteneurs est notre façon de rendre quelque chose à ces projets, et de savoir précisément ce que nous installons chez nos clients.

Si vous utilisez un portail client, un logiciel de gestion ou une application sur mesure et voulez savoir si les autorisations font vraiment ce qu'elles promettent, nous en parlerons volontiers. Notre travail de test d'intrusion part justement de là : lire le code et la configuration, comprendre où un contrôle manque, et vous dire précisément ce que nous avons vérifié et ce que nous n'avons pas vérifié.

Parlons de la sécurité de vos applications↗