AppFlowy laisse son édition self-hosted exposée à une injection SQL authentifiée
CVE-2026-16007 est une injection SQL authentifiée dans AppFlowy Cloud, l’alternative open source à Notion : tout utilisateur connecté peut lire, modifier ou supprimer la base. Le correctif n’existe que pour l’offre commerciale — l’édition auto-hébergée n’a reçu aucune réponse de l’éditeur.
24 juin 2026. Project Black signale une injection SQL dans AppFlowy Cloud, l’alternative open source à Notion. 20 juillet 2026. L’éditeur répond que le problème « ne s’applique plus » à son offre commerciale. 28 août 2026. Faute de correctif pour l’édition open source, le chercheur prévient publiquement les auto-hébergeurs sur Reddit — et l’éditeur finit par confirmer la faille. Entre les deux, la communauté self-hosted est restée exposée sans réponse.
L’enjeu n’est pas seulement la faille. C’est ce qu’elle révèle du traitement réservé à l’édition que vous hébergez vous-même.
Une injection SQL classique, au mauvais endroit
CVE-2026-16007 est une injection SQL authentifiée. N’importe quel utilisateur connecté peut injecter du SQL arbitraire via le paramètre search_term de l’endpoint suivant :
# L'endpoint vulnérable : search_term est concaténé brut dans la requête SQL
curl -G 'https://appflowy.example/api/workspace/<workspace-id>/quick-note' \
--data-urlencode 'search_term=test'Le code fautif se situe dans libs/database/src/quick_note.rs, aux lignes 53 à 56 : le paramètre contrôlé par l’utilisateur est inséré dans une requête de type JSON path sans assainissement, puis poussé tel quel dans le query builder SQL. La charge de preuve utilisée par les chercheurs suffit à confirmer l’exécution arbitraire :
1" )' OR (SELECT CAST(version() AS numeric)) IS NOT NULL--Les conséquences sont à la hauteur de la classe de la faille : un utilisateur authentifié peut exfiltrer, modifier ou supprimer les bases sensibles de l’instance. Et si l’auto-inscription est ouverte — le réglage par défaut de nombreuses installations — l’attaquant n’a même pas besoin d’un compte existant : il crée le sien, puis exploite.
Le même code, deux traitements
Le point le plus instructif du rapport tient dans la réponse de l’éditeur. Project Black note que l’offre AppFlowy Managed Cloud et l’édition self-hosted partagent de larges portions du même code source — l’offre commerciale étant un fork fermé du dépôt open source AppFlowy-Cloud, combiné à du code propriétaire.
Or la réponse reçue le 20 juillet 2026 est un modèle du genre :
After investigating, we confirmed that this issue no longer applies to our commercial AppFlowy Cloud codebase.
Traduction : la faille a été traitée — ou n’existe plus — côté commercial, sans un mot sur l’édition open source. Les relances du 28 juillet (« comptez-vous corriger la version open source ? ») et la notification de divulgation du 11 août sont restées sans réponse.
Ce silence n’est pas anodin. Il réactive une question que la communauté self-hosted se pose depuis que AppFlowy a déplacé certaines fonctions — notamment le SSO — vers ses offres payantes : l’édition communautaire est-elle encore maintenue, ou est-elle devenue un produit d’appel ?
Le déroulé de la divulgation, ou comment ne pas gérer un signalement
La chronologie complète mérite d’être lue comme un cas d’école — à rebours.
- 24 juin 2026 — signalement initial à l’éditeur.
- 8 juillet — relance, aucune réponse reçue.
- 9 juillet — « nous investiguons ».
- 20 juillet — « ne s’applique plus à notre codebase commercial ».
- 28 juillet — demande de clarification sur l’édition open source, sans réponse.
- 11 août — notification d’intention de divulgation publique, sans réponse.
- 28 août — Project Black alerte les auto-hébergeurs sur Reddit ; l’éditeur conteste, puis met à jour son message pour confirmer l’existence de la vulnérabilité.
Le chercheur résume l’expérience comme l’une des pires qu’il ait vécues en matière de divulgation responsable. La leçon ne porte pas sur la difficulté technique — corriger une concaténation de chaîne est trivial — mais sur la gouvernance : quand un éditeur ne répond plus, la seule échéance qui fait bouger les choses est la publicité de la faille.
Ce que ça change pour qui self-hoste
Pour l’auto-hébergeur, l’équation est simple et désagréable. Si vous faites tourner AppFlowy Cloud en communauté, trois faits s’enchaînent : la faille est authentifiée, donc peu visible des scanners externes ; l’auto-inscription la rend exploitable par n’importe qui ; et aucun correctif n’est annoncé pour votre édition au moment de la divulgation.
La riposte tient en trois gestes, dans l’ordre d’urgence :
- Couper l’exposition réseau. Tant qu’aucun correctif n’est publié pour l’édition open source, l’instance ne doit plus être joignable depuis un réseau non maîtrisé. C’est la mesure qui neutralise l’exploitation, quel que soit l’état du code.
- Désactiver l’auto-inscription. La faille exige un compte authentifié. Supprimer la création de compte publique réduit le bassin d’attaquants à ceux qui détiennent déjà un compte légitime.
- Surveiller la sortie d’un correctif. Le risque n’est pas théorique : tant que la version que vous exécutez contient la concaténation fautive, tout compte — même compromis a posteriori — redevient une clé d’accès à la base.
# Restreindre l'accès à l'instance auto-hébergée (exemple avec ufw)
ufw default deny incoming
ufw allow from <sous-reseau-admin> to any port 443 proto tcp
ufw enableVerdict
Si vous auto-hébergez AppFlowy Cloud, traitez cette instance comme ce qu’elle est aujourd’hui : un logiciel dont la filière de correctifs n’est pas garantie. Coupez son exposition réseau maintenant, désactivez l’auto-inscription, et intégrez la sortie d’un correctif à votre veille de sécurité — pas à votre plan de maintenance trimestriel.
Si vous évaluez encore AppFlowy, la question n’est plus « open source contre Notion », mais « édition dont les correctifs de sécurité dépendent d’un contrat commercial, ou non ? ». La réponse à cette question doit précéder le déploiement, parce qu’une fois les données dedans, la migration coûte plus cher qu’un changement d’avis.