File Browser est archivé et ne recevra plus aucun correctif de sécurité

1er septembre 2026. Le dépôt filebrowser/filebrowser passe en lecture seule, et File Browser — l’un des gestionnaires de fichiers web auto-hébergés les plus installés, 36 000 étoiles et 4 100 forks sur GitHub — ne recevra plus jamais de correctif de sécurité. Le 27 juillet 2026, la v2.63.23, dernière version planifiée, était publiée ; le lendemain, son mainteneur Henrique Dias en annonçait la fin. Pourquoi c’est important : un gestionnaire de fichiers exposé sur le web est une cible de choix, et il n’y aura plus personne pour corriger la prochaine faille.

Un pilier des homelabs et des NAS

File Browser est un binaire Go unique qui expose une interface web complète de gestion de fichiers : upload, téléchargement, renommage, partage par lien, comptes multi-utilisateurs et permissions par dossier. Sa simplicité — un seul exécutable, un fichier de configuration, pas de dépendance d’exécution — en a fait le choix par défaut des homelabs, des NAS artisanaux et des images d’applications qui ont besoin d’une vue fichiers embarquée. C’est précisément cette ubiquité qui rend son archivage notable : beaucoup d’installations ne savent même pas qu’elles en dépendent.

Le projet n’est pas un fork récent ni un concurrent de niche. Il est la référence de sa catégorie depuis des années, maintenu presque seul par Henrique Dias, et distribué pour une vingtaine de cibles — Linux, macOS, Windows, FreeBSD, ARM — ainsi que sous forme d’image Docker officielle. Son dépôt affiche plus de 36 000 étoiles, un chiffre qui place le projet parmi les outils self-hosted les plus suivis de GitHub.

La chronologie : annonce en juillet, archive en septembre

La fin a été progressive et annoncée. Le 27 juillet 2026, Henrique Dias publie la v2.63.23, en la qualifiant explicitement de dernière version planifiée. Le 28 juillet 2026, il poste sur son blog un billet intitulé « Goodbye File Browser, For Real This Time » — un adieu définitif, après plusieurs années d’entretien à effectif réduit. Le 31 août 2026, l’organisation GitHub est marquée comme archivée ; le 1er septembre 2026, le dépôt passe en lecture seule.

Cette chronologie compte, parce qu’elle laisse un délai d’un mois entre l’annonce et l’archivage effectif. Les équipes qui ont vu l’annonce en juillet ont eu le temps d’agir ; celles qui découvrent l’archivage aujourd’hui n’ont, elles, plus de fenêtre — la situation est déjà figée.

Ce que « archivé » signifie concrètement

Le mot « archivé » est trompeur, car il n’évoque pas l’arrêt complet qu’il désigne ici. Concrètement :

• Plus aucune version, plus aucun correctif de bug, plus aucun correctif de sécurité. La v2.63.23 est le point final.
• Les versions existantes et les images Docker restent en ligne et ne seront pas retirées. Tout continue de fonctionner — c’est le problème autant que la bonne nouvelle.
• Le code reste téléchargeable et forkable, mais le projet central est mort.

La nuance qui doit guider votre décision est la deuxième : votre instance ne va pas cesser de fonctionner, elle va vieillir sans filet. Le jour où une faille exploitable — path traversal, contournement d’authentification, injection — sera publiée contre File Browser, il n’y aura ni correctif officiel ni avis de sécurité. Vous serez seul.

Le risque réel : une surface exposée qui ne sera plus patchée

Un gestionnaire de fichiers est, par nature, une surface d’attaque de premier rang. Il gère des uploads, des chemins de fichiers, des permissions et des comptes, et il est très souvent exposé derrière un reverse proxy pour permettre l’accès à distance. La classe de vulnérabilités qui l’a historiquement concerné — traversée de répertoire, contournement de la sandbox des liens symboliques, exécution de code — ne va pas disparaître avec l’archivage ; elle va au contraire rester ouverte à jamais dès la prochaine découverte.

Le pire scénario n’est pas théorique. Une instance File Browser connectée à internet, sans correctifs à venir, devient une porte dérobée persistante le jour où une CVE tombe : l’attaquant sait que la cible ne sera jamais patchée, ce qui prolonge indéfiniment la fenêtre d’exploitation. C’est exactement le profil que les botnets et les opérateurs de ransomware recherchent dans leurs scans automatisés.

Migrer : les alternatives maintenues

Le chemin de migration le moins douloureux est Filebrowser Quantum, un fork qui conserve la compatibilité avec le format de base de données de File Browser tout en patchant les vulnérabilités connues — autrement dit, une transition quasi transparente pour qui veut rester sur la même interface et le même modèle de configuration. Pour les équipes prêtes à changer d’outil, les alternatives recensées incluent copyparty, FileRise et Filestash, trois gestionnaires de fichiers web actifs et maintenus ; SFTPGo couvre le même besoin par le protocole, si l’interface web n’est qu’un plus.

Quelle que soit la cible, la migration ne se résume pas à remplacer le binaire. Le vrai travail est l’inventaire : repérer chaque instance en service, chaque image qui l’embarque, chaque reverse proxy qui l’expose, puis figer la version actuelle le temps de planifier. Une instance oubliée derrière un sous-domaine est une instance qui restera vulnérable.

Une migration en trois temps

Le déroulé concret tient en trois étapes. D’abord, l’inventaire : listez vos conteneurs et vos fichiers de composition pour repérer tout ce qui embarque File Browser. Une commande suffit la plupart du temps :

# Repérer les conteneurs File Browser en service sur un hôte
docker ps --format '{{.Image}} {{.Names}}' | grep -i filebrowser

Ensuite, le choix : Filebrowser Quantum pour rester sur la même interface et la même base de données, ou une alternative maintenue — SFTPGo, copyparty, Filestash — si vous êtes prêt à changer d’outil. Enfin, le basculement : testez la nouvelle instance en parallèle sur le même volume, validez les permissions, puis coupez l’ancien conteneur.

La dernière étape est la plus souvent négligée : retirer l’ancienne image du parc. Une image archivée qui traîne dans un docker-compose.yml inutilisé reste un point d’entrée potentiel — et personne ne se souviendra de la patcher, puisqu’il n’y a plus de patch.

Verdict

Si vous exposez File Browser sur internet, même derrière une authentification, migrez sans attendre : il n’y aura plus de correctif, et chaque jour supplémentaire augmente le risque qu’une faille publique vous trouve avant votre migration. Si l’instance est strictement en LAN, sans exposition ni compte d’accès à distance, l’urgence est moindre — mais planifiez quand même : la fin des correctifs signifie que vous porterez seul la responsabilité de la prochaine faille, y compris interne. Si vous démarrez un nouveau projet, ne partez pas sur un dépôt archivé : choisissez directement un fork maintenu comme Filebrowser Quantum ou une alternative active.

La décision se résume à une question de calendrier et d’exposition. Un outil archivé peut encore rendre service des années sur un réseau de confiance ; exposé, il devient un passif qui se dégrade chaque jour. Le signal à retenir de File Browser n’est pas qu’un outil meurt — c’est que, dans le self-hosting, la maintenance d’un projet est une donnée de sécurité à part entière, au même titre que son code.

Références

• GitHub — filebrowser/filebrowser, dépôt archivé le 31 août 2026
• GitHub — filebrowser/filebrowser v2.63.23, dernière version planifiée, 27 juillet 2026
• Henrique Dias — « Goodbye File Browser, For Real This Time », 28 juillet 2026
• Smart Stacking — File Browser is Being Archived: Top Alternatives & Migration Guide, 28 juillet 2026