La vulnerabilidad de PLONK de Dusk, una capa de privacidad valorada en 600.000 dólares que estuvo a punto de ser atravesada por una falsificación de prueba
Después de leer el informe de seguridad que OtterSec divulgó el 30 de abril de 2026, me quedé atónito durante unos cinco minutos. El verificador de dusk-plonk nunca verificó las cuatro comitments de polinomios que el probador proporcionaba. En simple: un atacante puede falsificar una prueba de conocimiento cero falsa, acuñar tokens DUSK y transferir las ganancias ilícitas sin necesidad de ningún activo real. Un protocolo de privacidad diseñado para un mercado financiero regulado tiene un defecto en su núcleo criptográfico que permite a un atacante acuñar tokens “de la nada”. Una infraestructura que dice dar tranquilidad a las instituciones en la cadena… presenta una falla básica en la capa de privacidad.
La narrativa de cumplimiento del whitepaper es preciosa, pero en el código casi se abre una puerta trasera de acuñación infinita. Puedes decir que el fallo ya fue corregido. Pero que este tipo de vulnerabilidad aparezca en el componente de verificación dentro de la capa de privacidad es un bofetón para la postura de “privacidad primero”. Un proyecto que vive de ZK, con problemas en su implementación de ZK. Tras terminar el informe, la primera pregunta que me vino a la mente fue: si un blockchain de privacidad que depende de ZK tiene un fallo así en la implementación de ZK… ¿qué es lo que no va a fallar?
El valor de mercado de Dusk, que ya cayó desde sus máximos, ha disminuido bastante; 600.000 dólares, al tipo de cambio de entonces. Si el atacante usa masivamente esta vulnerabilidad para acuñar tokens, el precio podría romperse directamente. @Dusk
Encontré un informe de auditoría de Dusk y lo revisé: el auditor es Dust Labs. El alcance de la auditoría solo cubre algunos módulos. ¿La lógica de verificación de dusk-plonk está dentro del alcance auditado? No encontré una indicación clara. Si el código central de la capa de privacidad quedó fuera en la auditoría, o si la auditoría en sí no cubría lo necesario, entonces el valor de ese informe debe reevaluarse. La auditoría no se hace una vez y se acaba.
No digo que Dusk no sea confiable, pero es difícil para mí seguir manteniéndolo si un proyecto que tiene “privacidad” en el nombre presenta este tipo de vulnerabilidad básica en la capa central de verificación de ZK. Verifiquémoslo en unas cuantas rondas más de validación criptográfica. Por ahora lo devolveré a la lista de observación para ver si se divulgan nuevas vulnerabilidades más adelante. Si el mismo módulo vuelve a fallar, ya no sería solo un problema técnico, sino un problema de proceso. #dusk $DUSK
Después de leer el informe de seguridad que OtterSec divulgó el 30 de abril de 2026, me quedé atónito durante unos cinco minutos. El verificador de dusk-plonk nunca verificó las cuatro comitments de polinomios que el probador proporcionaba. En simple: un atacante puede falsificar una prueba de conocimiento cero falsa, acuñar tokens DUSK y transferir las ganancias ilícitas sin necesidad de ningún activo real. Un protocolo de privacidad diseñado para un mercado financiero regulado tiene un defecto en su núcleo criptográfico que permite a un atacante acuñar tokens “de la nada”. Una infraestructura que dice dar tranquilidad a las instituciones en la cadena… presenta una falla básica en la capa de privacidad.
La narrativa de cumplimiento del whitepaper es preciosa, pero en el código casi se abre una puerta trasera de acuñación infinita. Puedes decir que el fallo ya fue corregido. Pero que este tipo de vulnerabilidad aparezca en el componente de verificación dentro de la capa de privacidad es un bofetón para la postura de “privacidad primero”. Un proyecto que vive de ZK, con problemas en su implementación de ZK. Tras terminar el informe, la primera pregunta que me vino a la mente fue: si un blockchain de privacidad que depende de ZK tiene un fallo así en la implementación de ZK… ¿qué es lo que no va a fallar?
El valor de mercado de Dusk, que ya cayó desde sus máximos, ha disminuido bastante; 600.000 dólares, al tipo de cambio de entonces. Si el atacante usa masivamente esta vulnerabilidad para acuñar tokens, el precio podría romperse directamente. @Dusk
Encontré un informe de auditoría de Dusk y lo revisé: el auditor es Dust Labs. El alcance de la auditoría solo cubre algunos módulos. ¿La lógica de verificación de dusk-plonk está dentro del alcance auditado? No encontré una indicación clara. Si el código central de la capa de privacidad quedó fuera en la auditoría, o si la auditoría en sí no cubría lo necesario, entonces el valor de ese informe debe reevaluarse. La auditoría no se hace una vez y se acaba.
No digo que Dusk no sea confiable, pero es difícil para mí seguir manteniéndolo si un proyecto que tiene “privacidad” en el nombre presenta este tipo de vulnerabilidad básica en la capa central de verificación de ZK. Verifiquémoslo en unas cuantas rondas más de validación criptográfica. Por ahora lo devolveré a la lista de observación para ver si se divulgan nuevas vulnerabilidades más adelante. Si el mismo módulo vuelve a fallar, ya no sería solo un problema técnico, sino un problema de proceso. #dusk $DUSK
