Je sais que beaucoup d'entre vous font tourner un DokuWiki quelque part, alors c'est pour ça que je vous en parle... Le 2 septembre dernier, Andreas Gohr, qui écrit ce moteur de wiki depuis plus de 20 ans, a confirmé publiquement une faille critique dans son propre bug tracker.

Le signalement vient d'un chercheur, sebastianosrt, qui avait envoyé le détail de la faille par mail mais comme il n'a jamais reçu de réponse, il a fini par ouvrir un ticket public pour dire qu'il n'arrivait pas à joindre le mainteneur.

Le mail était dans les spams...

Gohr l'a repêché huit minutes après l'ouverture du ticket, et un peu plus d'une heure après, il qualifié lui-même ce bug de critique, car il permet une exécution de code à distance (RCE) voire même une suppression de fichiers arbitraire.

Alors comme d'hab avec ce genre d'actu, il y a une bonne et une mauvaise nouvelle. La bonne, c'est qu'il faut un accès en écriture sur DokuWiki pour exploiter le truc. Cela veut dire que si votre wiki est en lecture seule, il ne pourra pas tomber. Mais la mauvaise, c'est que si votre wiki a des comptes rédacteurs, ou pire, l'inscription ouverte, alors n'importe lequel de ces comptes peut passer de "je corrige une typo" à "j'exécute ce que je veux sur ton serveur, nananananère". Et à peu près toutes les versions de DokuWiki publiées depuis dix ans sont concernées.

Rassurez-vous, le correctif est sorti le soir même , dans la version 2026-07-14c mais faudra forcement mettre à jour si vous êtes sur une ancienne version, parce que les précédentes releases majeures n'ont pas eu de patch. Et si vous l'avez installé avec apt, pour le moment, le correctif n'a pas été déployé sur les dépôts. Donc pour ceux qui ne peuvent pas mettre à jour tout de suite, Gohr conseille de désactiver l'option usedraft, qui est active par défaut.

Dernier point, et il est important, ce correctif interdit désormais aux plugins de ranger des objets PHP dans le cache d'instructions. Ceux qui le faisaient vont donc casser. Par exemple, les formulaires du plugin bureaucracy finiront en erreur sur toutes les pages. De son côté, le plugin gallery a quand a lui été mis à jour pour supporter cette update... On verra si les autres plugins arrivent à suivre...

Pour le reste, il n'y a ni CVE ni annonce ailleurs. Tout se passe dans ce ticket , et il est toujours ouvert si vous voulez y ajouter votre grain de sel ^^.

En ce magnifique mardi matin, moi et mon mal de crâne, nous avons découvert un truc assez cool qui est un genre de wiki personnel en markdown, comme Obsidian ou Notion, mais avec un super pouvoir qui est que vous pouvez y écrire du code qui s’exécute directement dans vos notes !! Hé oui, du vrai code ! Pas des plugins, pas des extensions, mais du code Lua intégré dans votre texte comme si vos notes étaient devenues un environnement de dev à part entière.

Ça s’appelle SilverBullet , c’est open source (licence MIT), et franchement, si vous avez déjà bidouillé des configs Neovim ou des scripts Redis, vous allez kiffer car c’est beaucoup plus simple ^^.

Ça ressemble à n’importe quel wiki markdown moderne. Vous écrivez vos notes en local, elles sont stockées en fichiers statiques .md, vous avez des liens bidirectionnels pour connecter vos idées, et l’interface est optimisée avec des raccourcis clavier. C’est évidemment une Progressive Web App qui fonctionne 100% hors ligne ( comme expliqué sur leur site ), et vous gardez le contrôle total sur vos données, puisque tout est auto-hébergé sur votre machine ou votre serveur.

Ainsi, avec le scripting Lua intégré, vous pouvez littéralement taper ${10 + 2} dans une note et le résultat s’affichera en temps réel : 12 (vous l’aviez les matheux ?? ^^). Et si vous voulez une liste de vos 5 dernières pages modifiées qui se met à jour automatiquement, suffit d’écrire un petit bout de Lua, et hop, votre wiki devient “vivant”.

Alors oui, je sais ce que vous allez me dire, Obsidian a Dataview, Logseq a ses requêtes en Datalog…etc donc c’est pareil non ?

Et bien pas vraiment parce que Dataview ça vous demande quand même d’apprendre un DSL (Domain Specific Language) avec une syntaxe bizarroïde et de vous palucher les 50 pages de doc. Logseq quand à lui vous balance du Datalog sans trop d’explications. Alors que SilverBullet, lui, vous laisse écrire du Lua. Et le Lua, c’est simple, c’est dispo partout (Neovim, Redis, les addons World of Warcraft, OSB, etc.), c’est documenté, et c’est fait pour être embarqué dans des applications.

Si vous êtes data scientist, vous connaissez sûrement les Jupyter Notebooks qui sont markdown avec du code Python exécutable dedans. Hé bien SilverBullet fait exactement la même chose, mais pour vos notes personnelles. Vos notes ne sont plus des fichiers inertes, mais deviennent des mini-programmes qui peuvent calculer, générer du contenu, réagir à des événements…etc

Tenez par exemple, vous pouvez définir une fonction custom directement dans une page :

-- Additionner deux nombres
function adder(a, b)
 return a + b
end

command.define {
 name = "Insérer signature",
 run = function()
 local date = os.date("%Y-%m-%d")
 editor.insertAtCursor("---\nÉcrit le " .. date, false, true)
 end
}

slashCommand.define {
 name = "todo",
 run = function()
 editor.insertAtCursor("- [ ] |^|", false, true)
 end
}

event.listen {
 name = "page:save",
 run = function(e)
 local content = editor.getText()
 local word_count = select(2, content:gsub("%S+", ""))
 editor.flashNotification("Nombre de mots : " .. word_count)
 end
}

chmod +x silverbullet
mkdir mes-notes
./silverbullet mes-notes

.\silverbullet.exe mes-notes

docker run -p 3000:3000 -v ~/mes-notes:/space ghcr.io/silverbulletmd/silverbullet