En bref

Ce site épingle chaque bibliothèque hébergée sur CDN (Font Awesome, Mermaid, Lunr, et d’autres) avec des hashes Subresource Integrity, et un job cron hebdomadaire sur la VM Hugo vérifie que ces hashes sont toujours valides et met automatiquement à jour les versions mineures/patch quand une nouvelle release est disponible. Ce job échouait à chaque exécution depuis des semaines, silencieusement, et l’investigation d’aujourd’hui a mis au jour deux bugs distincts — l’un dans l’infrastructure opérateur, l’autre dans mcp-hugo-server-go lui-même.

En bref

Périmètre : défenses effectivement implémentées côté serveur MCP d’arleo.eu (mcp-hugo-server-go) contre l’injection de prompt indirecte et le tool poisoning, disponibles depuis la v1.9.3 : étiquetage systématique de provenance (content_provenance), empreinte du registre d’outils (tool_registry_digest), déclaration explicite de dérivation non fiable, garde-fou de suppression, threat model documenté. Non couvert : ce n’est pas un incident — cet article documente une architecture de défense, pas un correctif après coup. Ce qui reste hors de portée (mitigation côté client, filtrage sémantique volontairement rejeté) est détaillé plus bas.

En bref

Claude.ai (compte Pro), connecté au même serveur MCP auto-hébergé (mcp.arleo.eu), a mené un audit complet des 72 outils exposés en scope admin sur la version v1.9.2 — outil par outil, avec justification systématique pour chaque verdict.

Ce que Claude.ai dit du serveur en général

Avant le détail outil par outil, le constat global tel que formulé par Claude.ai lui-même :

• Les cycles d’écriture réels tiennent de bout en bout : create → update → plan → apply → rollback → delete, sur pages simples ET bundles bilingues, avec les hashes qui reviennent exactement à leur valeur de départ à chaque rollback
• Les garde-fous de sécurité/concurrence (revision guards, asset_referenced, test_content bloquant draft:false, quota destructif) se comportent exactement comme documenté, y compris dans des cas limites délibérément provoqués (rejeu de chunk, tentative de suppression d’asset référencé)
• Les trois points d’investigation ouverts lors de l’audit précédent (déterminisme, cache stale, clarification métrique) sont non seulement corrigés mais vérifiés en conditions réelles, pas juste lus dans un changelog
• Nettoyage final : le site revient bit à bit à son état initial (86 pages, 0 résidu, health score 100)

Mais Claude.ai a aussi été explicite sur ce que sa propre méthode d’audit ne peut pas couvrir — angles morts structurels, pas des défauts identifiés :

En bref

Depuis le 20 août 2026, notre connecteur MCP personnalisé (auto-hébergé, mcp.arleo.eu, conforme OAuth 2.1 + PKCE + spécification MCP) a cessé de fonctionner dans ChatGPT, sans qu’aucune ligne de code ni de configuration n’ait changé côté serveur. Le connecteur avait pourtant fonctionné sans problème jusqu’à la veille.

En bref

Deux rafales de scan Internet ont révélé un défaut latent dans la chaîne OpenResty/CrowdSec. Les scanners n’ont pas « fait tomber » OpenResty par leur volume : la cadence restait faible pour nginx. Ils ont surtout déclenché un chemin d’exécution qui appelait un module Lua custom impossible à retrouver sur des workers OpenResty fraîchement chargés.

Cette page remercie publiquement les personnes ayant signalé une vulnérabilité de sécurité sur ce site dans le cadre d’une divulgation responsable.

Comment signaler

La procédure complète (contact, clé PGP, délai de correction) est décrite dans security.txt (RFC 9116) — c’est la source unique et faisant foi. Merci de signaler toute vulnérabilité de manière responsable, sans exploitation au-delà de ce qui est strictement nécessaire pour la démontrer. Sur demande, votre signalement peut rester anonyme.