Lettre à DeepSeek — un dérivé sans garde-fous circule sous votre nom
Lettre à DeepSeek — un dérivé sans garde-fous circule sous votre nom
Objet : signalement d'un dérivé « abliterated » de DeepSeek V4 Flash en circulation, et d'une classe de vulnérabilité par confusion de rôle De : Coopérative CopyCoop / Assemblées Citoyennes (France, Seine-et-Marne) À : DeepSeek — équipe sécurité et équipe modèle Date : 26 septembre 2026 Copie : La Quadrature du Net · CERT-FR
Qui nous sommes
Nous sommes une coopérative citoyenne française. Nous ne sommes ni un laboratoire de recherche, ni un éditeur de logiciels de sécurité : nous sommes des utilisateurs, et nous hébergeons nos propres services sur nos propres machines.
Nous utilisons DeepSeek V4 Flash en production, via une passerelle d'inférence que nous administrons. Nous ne sommes pas neutres : notre activité dépend de vos modèles, et nous avons un intérêt direct à ce qu'ils soient sûrs.
Nous vous écrivons parce que nous avons trouvé, dans notre propre infrastructure, un usage que nous jugeons préoccupant pour votre marque et pour vos utilisateurs.
1. Ce que nous avons trouvé
Un dérivé de votre modèle, privé de ses garde-fous
Notre propre déploiement chargeait, sans que nous en mesurions alors les conséquences, un fichier nommé :
Huihui-DeepSeek-V4-Flash-BF16-abliterated-ds4-Q2_K.gguf
Le terme abliterated désigne une technique connue consistant à retirer par entraînement les mécanismes de refus d'un modèle. Le résultat est un modèle qui porte le nom de votre modèle tout en ayant perdu l'alignement que vous y avez investi.
Nous l'avons constaté sur pièce : configuration de production, ligne de commande du service, fichier de quantification. Le dérivé existe, il est utilisé, et rien ne l'identifie comme non officiel pour un utilisateur non averti.
Ce qui nous inquiète n'est pas son existence — c'est son étiquette. Un utilisateur qui lit « DeepSeek-V4-Flash » ne peut pas savoir que les refus ont été supprimés. La conséquence est double : votre travail d'alignement est effacé, et votre nom est associé à des sorties que vous n'avez jamais produites.
Ce que cela implique concrètement
Sur un modèle dont les refus ont été retirés, la seule protection restante est le filtre applicatif placé devant. Ce filtre, nous l'avons construit : une couche éthique à trois lois, un validateur, un journal de violations — 70 violations enregistrées entre le 11 juin et aujourd'hui, à l'entrée.
Mais un filtre applicatif est fragile par nature : il se contourne, il s'oublie, il se désactive. Quand le modèle ne refuse plus, le filtre devient le seul rempart — et un rempart unique n'est pas un rempart.
Nous avons d'ailleurs trouvé une faiblesse dans le nôtre : un jeton de contrôle que nous avions défini nous-mêmes permet de franchir nos propres règles. Nous le corrigeons. Nous le mentionnons parce qu'il illustre le fond du problème : empiler des filtres sur un modèle sans refus, c'est construire sur du vide.
2. Une classe de vulnérabilité que nous avons documentée
En auditant nos propres outils, nous avons documenté une classe d'attaque que la littérature commence à nommer « injection de prompt par confusion de rôle » (arXiv, Prompt Injection as Role Confusion).
Le principe : si un harnais d'agent sérialise toute la conversation en une seule chaîne de texte, avec des marqueurs de rôle non échappés, alors un contenu utilisateur peut fabriquer un tour de conversation que le modèle prend pour une instruction légitime et exécute.
Nous avons vérifié que cette faiblesse est présente dans un harnais d'agent largement utilisé avec vos modèles, et absente par conception d'un autre. Ce n'est pas une faille de vos modèles : c'est une faille de ce qu'on construit autour d'eux. Mais elle produit exactement l'effet que vos garde-fous cherchent à empêcher — et elle se combine dangereusement avec un modèle abliterated.
Notre rapport complet est disponible, il ne contient aucun secret et il est reproductible.
3. Ce que nous avons constaté dans vos canaux publics
Nos recherches nous ont conduits à plusieurs signalements déposés dans vos espaces publics :
| Référence | Objet | État |
|---|---|---|
deepseek-ai/DeepSeek-V3 #1350 |
Contournement de sécurité par injection de prompt basée sur les rôles | ouvert |
deepseek-ai/DeepSeek-V3 #1543 |
Divulgation responsable : contournement du filtre de sûreté | ouvert |
deepseek-ai/DeepSeek-V3 #1528 |
Rapport critique sans réponse depuis le 17 juin 2026 | ouvert |
Nous nous permettons d'insister sur le dernier point. Un rapport critique resté sans réponse pendant plus de trois mois, dans le canal public où l'on est censé vous joindre, décourage exactement le comportement que vous souhaitez encourager : signaler plutôt que publier.
Nous écrivons donc ici, et nous rendons cette lettre publique, non par hostilité — mais parce que le canal privé n'a pas répondu.
4. Ce que nous demandons
Nous ne demandons ni dédommagement, ni reconnaissance. Nous demandons quatre choses simples :
- Un accusé de réception humain de ce signalement — pas un ticket automatique.
- Une position claire sur les dérivés abliterated diffusés sous votre nom : les surveillez-vous ? Communiquez-vous dessus ? Un utilisateur peut-il savoir qu'il n'utilise pas votre modèle ?
- Une réponse au rapport #1528, ou à défaut une indication du canal qui fonctionne réellement.
- Si cela vous est utile : notre rapport d'audit complet, nos scripts de détection et notre méthode de vérification, transmis sans condition — y compris si vous choisissez de ne jamais nous répondre.
5. Ce que nous faisons de notre côté, sans attendre
Nous ne conditionnons pas notre propre mise en sécurité à votre réponse :
- nous avons retiré le modèle abliterated de notre chaîne de production et documenté publiquement pourquoi ;
- nous avons corrigé notre jeton de contournement ;
- nous publions la méthode de détection afin que d'autres puissent vérifier leur propre installation ;
- nous poursuivons la constitution d'un dossier documenté sur cette classe de vulnérabilité.
Nous le faisons parce que la sécurité n'est pas une faveur qu'on attend d'un fournisseur : c'est une responsabilité qu'on assume sur ses propres machines.
6. Une remarque, que nous assumons
Nous écrivons cette lettre en sachant qu'elle vous met en cause. Nous préférons le dire clairement plutôt que de le suggérer :
- nous ne vous accusons pas d'avoir créé ces dérivés ;
- nous ne vous accusons pas d'être responsables des usages que d'autres en font ;
- nous constatons que votre nom circule sur des modèles qui ne sont plus les vôtres, et que le canal prévu pour le signaler n'a pas répondu pendant trois mois.
Si nous nous trompons sur un point, dites-le : nous corrigerons publiquement, comme nous avons corrigé nos propres erreurs dans ce dossier.
Coopérative CopyCoop / Assemblées Citoyennes Seine-et-Marne, France 26 septembre 2026
Pièces jointes : rapport d'audit « Injection de rôle » (10 pages) · journal de violations (70 entrées) · méthode de détection reproductible · inventaire modèle du déploiement concerné.