Cinq événements Timeout::Error venant d'un même client en trente minutes, tous issus du moteur de rendu OtherMarkup pendant qu'il mâchonne des fichiers .org. C'est le seuil que l'équipe sécurité de GitLab propose pour repérer les tentatives contre CVE-2026-110264, et je n'arrive pas à me le sortir de la tête. La plupart des instances GitLab que j'ai administrées au fil des ans n'ont jamais affiché volontairement le moindre document Org-mode. Toutes en auraient pourtant affiché un pour un inconnu anonyme, et c'est justement là tout le problème.

Voici les faits, rapidement, parce qu'il te les faut avant tout le reste. Le 21 octobre 2026, GitLab a publié en urgence un correctif critique pour CE et EE : 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13. Le bug est un dépassement d'entier (CWE-190) dans la façon dont Onigmo, le moteur de regex de Ruby, traite des motifs qu'un contenu Org contrôlé par l'attaquant peut façonner via org-ruby. Un calcul de taille déborde, de la mémoire est touchée là où elle ne devrait pas l'être et, dans les bonnes conditions, un utilisateur non authentifié obtient l'exécution de code sur le serveur. Le vecteur est CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, ce qui donne un 10.0 tout rond. Les versions touchées remontent jusqu'à la branche 7.0. GitLab.com et les versions Dedicated listées sont déjà corrigés. Si tu auto-héberges, arrête de lire, mets à jour, puis reviens. Et vérifie que Puma et Sidekiq ont bien redémarré sur la nouvelle build, parce qu'un paquet installé mais pas lancé ne corrige rien.

Ce qui me dérange, c'est moins le dépassement lui-même que l'endroit où se trouvait le trou. Les bugs mémoire dans les moteurs de regex en C, c'est un ennui ancien et bien connu, et je laisse les adeptes de Go savourer leurs vérifications de bornes le temps d'une phrase ou deux. Ce qui ne me lâche pas, c'est qu'une forge de code, un outil dont le boulot est de garder notre code source et nos clés de déploiement, faisait tourner un moteur de rendu de niche pour des visiteurs non authentifiés, et que ce chemin menait tout droit à du code natif. Personne dans une équipe plateforme classique ne s'est jamais assis pour décider que des utilisateurs anonymes devaient pouvoir faire compiler au serveur des regex à partir de notes Emacs. C'est arrivé dans le même paquet que « on affiche joliment ton README », ça semblait inoffensif, et pendant des années ça l'a été.

L'objection la plus solide mérite d'être entendue honnêtement, parce que je suis à moitié d'accord avec elle. Tu ne peux pas prédire quel parseur aura le prochain bug. Vire Org-mode et le trimestre prochain ce sera AsciiDoc, ou le sanitizer Markdown, ou le générateur de miniatures. Les gens qui vivent dans des fichiers Org sont de vrais utilisateurs avec de vrais besoins, et un éditeur qui livre le strict minimum finit par livrer un produit moins bon. Patcher est la seule solution qui passe à l'échelle, et GitLab a patché sept branches dans la même release. D'accord. Si ce que tu retiens de tout ça, c'est qu'il faut réduire chaque fonctionnalité à une simple zone de texte, tu perdras ce débat face à tes utilisateurs, et tu l'auras mérité.

Ma réponse, c'est que ce n'est pas forcément tout ou rien. Tout se joue sur qui peut atteindre le moteur de rendu. Un moteur que seuls les membres authentifiés d'un projet peuvent déclencher, c'est un bug qui attend un initié. Un moteur que n'importe quel client réseau peut déclencher sans se connecter, c'est un bug qui attend Internet tout entier, et c'est exactement ce que te disent AV:N et PR:N dans la chaîne du vecteur. Les formats de niche sur des chemins publics et non authentifiés devraient s'activer volontairement, instance par instance, et apparaître sous forme d'une ligne dans le panneau d'admin que tu peux désactiver. Aujourd'hui, ils sont une propriété émergente de l'arbre de dépendances. Les consignes de détection rendent le coût concret : un plantage natif [BUG] avec des frames comme onig_compile ou match_at, c'est l'issue bruyante, et GitLab dit clairement qu'une exploitation réussie peut passer inaperçue. Aucun monitoring ne te sauvera sur un chemin dont tu ignorais l'existence.

Maintenant, retourne ça et pointe-le vers notre propre code, parce que les applis PHP regorgent du même schéma. On construit des motifs PCRE à partir des saisies utilisateur dans des filtres de recherche, des helpers de surlignage et des tables de routage. On livre des parseurs BBCode et Markdown, des extensions de syntaxe wiki et des prévisualiseurs « colle n'importe quoi », souvent sur des pages qui ne demandent pas de connexion. Côté PHP, tu as des garde-fous corrects : preg_quote existe, pcre.backtrack_limit existe, et le moteur a eu des années de durcissement. Mais les garde-fous ne servent que sur les chemins de code dont quelqu'un se souvient. Je parierais un bon café que la plupart des bases de code Laravel ou Symfony matures ont au moins un endpoint public dont personne dans l'équipe actuelle n'a lu le pipeline de rendu.

Donc oui, patche d'abord, conserve tes logs Workhorse et Sidekiq avant de t'emballer sur les redémarrages, et fais tourner tes tokens si l'instance est restée exposée et que quelque chose cloche dans le journal d'audit. Ensuite, consacre un après-midi à la tâche moins glamour : liste chaque format et chaque regex influencée par l'utilisateur que tes systèmes vont traiter pour quelqu'un qui ne s'est pas authentifié, et demande-toi si chacun mérite sa place. La liste est vite écrite. C'est quand on commence à en rayer des lignes que le vrai débat s'ouvre.

Ce qui m'amène à ce que j'aimerais entendre de ta part. La dernière fois que tu as audité un outil auto-hébergé ou ta propre appli, as-tu trouvé un moteur de rendu ou un parseur exposé au trafic anonyme dont personne ne savait expliquer l'utilité ? Et quand tu as proposé de le désactiver, qui s'y est opposé, et avait-il raison ?