MetaMask confirmó que un atacante redirigió brevemente las recompensas de la capa de ejecución de ciertos validadores de Ethereum que utilizan su servicio de staking, desviando aproximadamente 0.385 ETH antes de que el cambio fuera detectado y revertido el mismo día. Los detalles aparecieron en una actualización del incidente del 5 de noviembre, la entrada más reciente sobre un incidente de seguridad que la empresa identificó por primera vez el 28 de septiembre. Aunque el monto desviado fue pequeño, el episodio destaca un aspecto del diseño de Ethereum que se pasa por alto con frecuencia: la distinción entre a dónde va finalmente el ETH en staking de un validador y a dónde se envían sus ingresos recurrentes por recompensas.

Lo que MetaMask ha revelado hasta ahora

Según la actualización, el atacante obtuvo acceso no autorizado a parte de la infraestructura detrás de MetaMask Staking, donde las direcciones que recogen las recompensas de la capa de ejecución de los validadores estaban almacenadas de forma centralizada. El intruso cambió esas direcciones para varios validadores. MetaMask dice que detectó y corrigió la modificación el mismo día, después de que se desviaran alrededor de 0.385 ETH en recompensas. La empresa no ha revelado cuántos validadores fueron afectados ni cómo obtuvo acceso el atacante.

El lado de los retiros se mantuvo intacto. MetaMask Staking no custodia las claves de retiro del ETH en staking de los clientes, y la empresa dice que no encontró evidencia de que el principal en staking, las claves de retiro ni las wallets de MetaMask hubieran sido comprometidas. Los usuarios comunes de la wallet de MetaMask no necesitan tomar ninguna acción.

Los 0.385 ETH no representan el costo total del incidente. MetaMask retiró cada validador afectado como precaución, y todos esos retiros ya se han completado. Algunos clientes experimentaron demoras temporales en los retiros, y la empresa reconoce que es posible que se hayan perdido recompensas mientras los validadores salían o esperaban volver a hacer staking. MetaMask no ha cuantificado esas pérdidas ni dicho si las recompensas desviadas serán reembolsadas; solo declaró que está trabajando directamente con los clientes y socios afectados.

El desvío de recompensas en sí aparece solo en la entrada del 5 de noviembre. Los avisos de MetaMask del 30 de septiembre y del 1 de octubre describieron el incidente y los retiros preventivos, y dijeron que en esa etapa no había indicios de que las wallets o los fondos de los clientes hubieran sido afectados. La cantidad de validadores involucrados, el punto de entrada del atacante y la cuestión del reembolso son los puntos pendientes a observar en futuras actualizaciones de MetaMask.

Por qué el staking se mantuvo pero los ingresos no

Cada validador de Ethereum responde a dos direcciones que se configuran en lugares distintos. La guía de retiros de Ethereum trata las credenciales de retiro y el fee recipient como configuraciones distintas, aunque ambas pueden apuntar a la misma wallet.

Las credenciales de retiro se registran en la beacon chain. Una vez que apuntan a una dirección de la capa de ejecución, esa dirección no se puede cambiar, y es ahí donde va el ETH del validador cuando sale. Ningún servidor de operador puede redirigirla.

El fee recipient funciona de manera diferente. Es una configuración de software proporcionada por quien opera el validador. En un servicio no custodial, ese es el operador, que también custodia las claves con las que firma el validador. La configuración indica a la red dónde enviar los ingresos de la capa de ejecución cada vez que el validador propone un bloque: las comisiones de prioridad de las transacciones y los pagos de los constructores de bloques. La base fee, en cambio, se quema y nunca llega al validador. El operador puede actualizar el fee recipient en cualquier momento sin la clave de retiro del staker. Esta es la configuración que MetaMask dice haber almacenado de forma centralizada —y la que cambió el atacante.

La misma separación explica por qué la pérdida se mantuvo pequeña. Las recompensas de la capa de consenso permanecen en el saldo del validador o se transfiere automáticamente a la dirección de retiro, por lo que la configuración alterada nunca las tocó. Los ingresos de la capa de ejecución llegan solo cuando un validador propone un bloque, algo que cualquier validador individual hace con poca frecuencia, y MetaMask corrigió el cambio en menos de un día. Solo las propuestas realizadas dentro de esa ventana pagaron a la dirección equivocada.

La misma exposición atraviesa el staking en pool

Nada de esta exposición es exclusiva de MetaMask. Dondequiera que un tercero opera el validador, el fee recipient se encuentra en la configuración de ese tercero, lo que hace de la exposición una característica estructural del staking a través de terceros y no una falla limitada a un solo proveedor. Lido, cuyos validadores son operados por operadores de nodos independientes, gestiona el riesgo mediante reglas: su política de MEV vigente exige que cada validador de Lido designe el Execution Layer Rewards Vault del protocolo como fee recipient, y las violaciones ya cuentan con su propio proceso de manejo.

El vault es un contrato. Según la documentación de Lido, recoge los ingresos de la capa de ejecución, incluidos el MEV y las comisiones de prioridad, y solo el contrato principal de Lido puede retirar de él, moviendo el ETH a la contabilidad del protocolo para los poseedores de stETH. Un pago enviado a cualquier otro lugar nunca entra en esa contabilidad.

Los poseedores de stETH están un paso más alejados de estas configuraciones que los clientes de MetaMask Staking. Poseen un token transferible en lugar de credenciales de retiro de algún validador específico, por lo que su protección descansa por completo en los contratos de Lido y las reglas para operadores.

ePBS garantizaría el pago, no la dirección

El 4 de noviembre, Lido publicó una propuesta para actualizar esa política de MEV para la separación de proponente-constructor integrada en el protocolo, o ePBS, el diseño especificado en EIP-7732. Los validadores que hoy subcontratan la construcción de bloques dependen de relays, intermediarios de confianza que se encargan de asegurar que el constructor ganador realmente pague. Lido describe ePBS como una forma de reducir esa necesidad de confianza al hacer que el propio protocolo garantice los pagos de los constructores.

La garantía tiene límites. Bajo el diseño que Lido describe, una sola oferta puede combinar un valor trustless, que se adeuda en cuanto el proponente incluye la oferta incluso si el constructor nunca revela su bloque, con un pago de confianza opcional liquidado fuera del protocolo, que conlleva el mismo riesgo de contraparte que el mercado actual. Lido permitiría que cualquier constructor registrado gane sus slots con ofertas totalmente trustless, pero solo los constructores de su Allowed List aprobada podrían añadir pagos de confianza.

Más relevante para los stakers, la garantía cubre cuánto se paga, no dónde llega. Bajo el diseño, los validadores difunden preferencias firmadas que designan su fee recipient para los próximos slots, y el valor trustless va al fee recipient designado en la oferta. Esa dirección sigue originándose en el operador. Un fee recipient alterado de la manera descrita por MetaMask recibiría pagos garantizados con la misma certeza que el correcto.

El borrador de Lido mantiene la regla del fee recipient en su núcleo. Ambos tipos de pago deben llegar al EL Rewards Vault, y la política obligaría a cada nodo capaz de proponer para Lido, incluidas las máquinas de respaldo y failover. Lido dice que la propuesta irá a votación en noviembre y solo entraría en vigencia después de que la actualización Glamsterdam llegue a la mainnet de Ethereum. Hasta que llegue esa actualización, la política de MEV vigente —con su regla del vault— sigue siendo el estándar al que se sujetan los validadores de Lido.

Qué detectarían los controles de Lido

Debido a que ePBS abre rutas adicionales para entregar un bloque, la propuesta amplía la monitoreo de Lido. Un validador sería marcado por designar cualquier dirección distinta al vault, o por aceptar un pago de confianza de un constructor fuera de la Allowed List. Las alertas también cubrirían pagos de confianza que no lleguen completos dentro del período de liquidación, y bloques construidos localmente propuestos mientras había ofertas externas elegibles por encima del umbral mínimo disponibles.

El control del valor de la oferta compara cada oferta seleccionada con la oferta elegible más alta que el monitoreo de Lido observó, y marca todo lo que esté por debajo de un 90–95 % inicial de esta. El umbral es un motivo para hacer preguntas, no una participación de ingresos prometida. El borrador permite que los operadores pasen por alto la oferta principal por razones legítimas operativas y de confiabilidad, y la comparación solo cubre las ofertas que observó el propio sistema de Lido.

Una alerta no devuelve el dinero. Las violaciones del fee recipient permanecen bajo el proceso actual de Lido, mientras que otras alertas seguirían el camino de contacto y escalamiento de la Sección E de su Standard Node Operator Protocol. Lido también planea actualizar su Fees Monitoring Dashboard público para mostrar por qué vía pasó cada bloque de Lido.

Cómo revisar tu propia configuración de staking

Los pagos de la capa de ejecución se registran en la blockchain, y así fue como las direcciones alteradas en MetaMask se hicieron visibles. Un staker que conoce los índices de sus validadores puede abrir cada bloque propuesto por esos validadores en un explorador de la beacon chain y verificar qué dirección recibió el pago del proponente. Para Lido, el panel de comisiones es la vista pública del monitoreo del pool.

Los retiros merecen el mismo escrutinio. Como señala la actualización de MetaMask, retirar un validador y retirar su ETH son procesos separados: un validador retirado aún debe pasar por el procesamiento de retiros de Ethereum antes de que el ETH sea gastable, según se describe en la documentación de staking de Ethereum. Desde la actualización Pectra, EIP-7002 permite que el titular de la dirección de retiro de la capa de ejecución de un validador active directamente su salida, sin pasar por el operador.

Cuatro preguntas para hacer a cualquier proveedor de staking cubren las brechas que este incidente expuso:

¿Quién puede cambiar mi fee recipient? Busca roles designados, aprobación previa a cualquier cambio y un registro de cada edición, en lugar de una sola configuración almacenada de forma centralizada.

¿Qué tan rápido detectarían una dirección incorrecta? Busca verificaciones automatizadas en cada bloque propuesto, con alertas en lugar de revisiones manuales periódicas.

¿Qué pagos de constructores están garantizados? Bajo ePBS, espera un desglose del valor exigible por el protocolo frente a los pagos de confianza, y una explicación de cómo se persiguen los montos no pagados.

¿Puedo retirarme sin ti? Confirma que tus credenciales de retiro admitan salidos activadas por ti mismo, y pregunta quién cubre las recompensas perdidas durante una salida preventiva.