Le bug PLONK de Dusk, une couche de confidentialité d’une valeur de 600 000 dollars a été presque percée par une fausse preuve
Après avoir lu le rapport de sécurité披露 par OtterSec en date du 30 avril 2026, je suis resté stupéfait pendant environ cinq minutes. Le vérificateur de dusk-plonk n’a jamais vérifié les quatre engagements de polynômes fournis par le prouveur. En termes simples, l’attaquant peut fabriquer une fausse preuve de connaissance nulle sans aucun actif réel, puis frapper des jetons DUSK et transférer illégalement les gains. Un protocole de confidentialité conçu pour des marchés financiers réglementés : son cœur cryptographique contient une faille permettant aux attaquants de créer des jetons de nulle part. Une infrastructure censée rassurer les institutions quant à l’on-chain, et pourtant il existe une faiblesse fondamentale dans la couche de confidentialité.
Le récit de conformité présenté dans le livre blanc est très joli, mais le code a presque laissé une porte dérobée de frappe infinie. Vous pouvez dire que la faille a été corrigée. Mais ce type de faille, qui apparaît dans l’étape de vérification de la couche de confidentialité, est en soi une claque pour l’orientation « confidentialité d’abord ». Un projet qui vit de la ZK, mais dont l’implémentation ZK a eu ce genre de problème : après avoir lu le rapport, la première question qui m’est venue est — si une chaîne de confidentialité basée sur la ZK présente une telle faille, qu’est-ce qui ne posera pas problème ? La valeur de Dusk a déjà chuté depuis son plus haut. 600 000 dollars convertis au cours de l’époque : si l’attaquant exploite cette faille pour frapper massivement des jetons, le prix pourrait être directement écrasé. @Dusk
J’ai trouvé un rapport d’audit de Dusk et je l’ai parcouru. L’auditeur est Dust Labs ; le périmètre d’audit ne couvre que certains modules, mais la logique de vérification de dusk-plonk se trouve-t-elle bien dans ce périmètre ? Je n’ai pas trouvé de déclaration claire. Si le code du cœur de la couche de confidentialité a été omis dans l’audit, ou si l’audit n’a tout simplement pas couvert le bon périmètre, alors la valeur de ce rapport d’audit doit être réévaluée. Un audit ne se fait pas une seule fois, puis c’est fini.
Je ne dis pas que Dusk n’est pas fiable, mais un projet qui écrit « confidentialité » dans son nom, et qui présente une faille fondamentale de ce type dans la couche de vérification ZK la plus critique, me rend très difficile de me convaincre de continuer à le détenir. Attendons que le cœur cryptographique soit à nouveau validé après quelques cycles. Pour l’instant, je le remets dans ma liste d’observation, pour voir s’il y a d’autres divulgations de failles par la suite. Si le même module pose encore problème, alors ce ne sera plus seulement un problème technique, mais aussi un problème de processus. #dusk $DUSK
Après avoir lu le rapport de sécurité披露 par OtterSec en date du 30 avril 2026, je suis resté stupéfait pendant environ cinq minutes. Le vérificateur de dusk-plonk n’a jamais vérifié les quatre engagements de polynômes fournis par le prouveur. En termes simples, l’attaquant peut fabriquer une fausse preuve de connaissance nulle sans aucun actif réel, puis frapper des jetons DUSK et transférer illégalement les gains. Un protocole de confidentialité conçu pour des marchés financiers réglementés : son cœur cryptographique contient une faille permettant aux attaquants de créer des jetons de nulle part. Une infrastructure censée rassurer les institutions quant à l’on-chain, et pourtant il existe une faiblesse fondamentale dans la couche de confidentialité.
Le récit de conformité présenté dans le livre blanc est très joli, mais le code a presque laissé une porte dérobée de frappe infinie. Vous pouvez dire que la faille a été corrigée. Mais ce type de faille, qui apparaît dans l’étape de vérification de la couche de confidentialité, est en soi une claque pour l’orientation « confidentialité d’abord ». Un projet qui vit de la ZK, mais dont l’implémentation ZK a eu ce genre de problème : après avoir lu le rapport, la première question qui m’est venue est — si une chaîne de confidentialité basée sur la ZK présente une telle faille, qu’est-ce qui ne posera pas problème ? La valeur de Dusk a déjà chuté depuis son plus haut. 600 000 dollars convertis au cours de l’époque : si l’attaquant exploite cette faille pour frapper massivement des jetons, le prix pourrait être directement écrasé. @Dusk
J’ai trouvé un rapport d’audit de Dusk et je l’ai parcouru. L’auditeur est Dust Labs ; le périmètre d’audit ne couvre que certains modules, mais la logique de vérification de dusk-plonk se trouve-t-elle bien dans ce périmètre ? Je n’ai pas trouvé de déclaration claire. Si le code du cœur de la couche de confidentialité a été omis dans l’audit, ou si l’audit n’a tout simplement pas couvert le bon périmètre, alors la valeur de ce rapport d’audit doit être réévaluée. Un audit ne se fait pas une seule fois, puis c’est fini.
Je ne dis pas que Dusk n’est pas fiable, mais un projet qui écrit « confidentialité » dans son nom, et qui présente une faille fondamentale de ce type dans la couche de vérification ZK la plus critique, me rend très difficile de me convaincre de continuer à le détenir. Attendons que le cœur cryptographique soit à nouveau validé après quelques cycles. Pour l’instant, je le remets dans ma liste d’observation, pour voir s’il y a d’autres divulgations de failles par la suite. Si le même module pose encore problème, alors ce ne sera plus seulement un problème technique, mais aussi un problème de processus. #dusk $DUSK
