La mejora de Ethereum que convirtió cuentas convencionales en monederos programables llegó acompañada de un problema de confianza inesperado. Una investigación académica presentada para USENIX Security ’26 ha documentado que contratos vinculados a atacantes concentraron 2.322.548 de las 3.664.166 autorizaciones EIP-7702 registradas en siete cadenas hasta el 15 de julio de 2025. Eso supone el 63% del volumen histórico de transacciones en el conjunto de datos analizado.
Los autores del estudio identificaron un conjunto relativamente reducido de contratos maliciosos reutilizados de forma repetida, lo que multiplicó el recuento de autorizaciones. Parte de esa actividad procedía de pruebas de concepto o prácticas de ataque durante la fase inicial de exploración de Ethereum tras la actualización Pectra del 7 de mayo de 2025. El análisis mide transacciones, no monederos únicos afectados ni la tasa de ataques en 2026.
Por qué los atacantes dominaron el recuento temprano de autorizaciones
La propuesta EIP-7702 introdujo un nuevo tipo de transacción (tipo 4) que permite a una cuenta de propiedad externa (EOA) delegar la ejecución de código en un contrato desplegado. La dirección permanece invariable, la clave privada original conserva el control y las llamadas al monedero pueden ejecutar el código delegado en el contexto de la cuenta.
Ese diseño otorga a un monedero convencional capacidades propias de cuentas inteligentes, como llamadas agrupadas y transacciones patrocinadas, sin obligar al usuario a migrar a una nueva dirección. Pero también convierte el destino de la delegación en infraestructura crítica del monedero. Un código defectuoso u hostil puede ejecutar aprobaciones, transferencias e interacciones con aplicaciones en nombre del titular.
Los atacantes podían preparar campos de autorización fuera de la cadena y solicitar al usuario que firmara. Un monedero mal diseñado podía reducir la decisión a una simple actualización de cuenta, ocultando la dirección del contrato o el código que recibiría plena autoridad. El protocolo verifica la firma del propietario, pero el monedero debe establecer si el código seleccionado merece el control.
Riesgo de 2,36 millones en pérdidas detectadas y 10,14 millones en exposición potencial
Los investigadores analizaron más de 22.800 millones de transacciones históricas en Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base y Gnosis. Dentro de ese volumen, examinaron 3.664.166 autorizaciones EIP-7702 hasta la fecha límite y utilizaron filtros de transacciones, análisis de bytecode y revisión manual para identificar 924 contratos maliciosos. De ellos, 793 apuntaban a cuentas EOA, 124 a cuentas contractuales y siete empleaban ataques mixtos.
El estudio cuantificó pérdidas detectadas de 2.362.848,76 dólares en tres categorías de ataque. Una estimación separada abordó contratos más antiguos cuyas defensas asumían que las EOAs programables no podían existir. EIP-7702 rompió el supuesto de que msg.sender == tx.origin identifica de forma fiable una EOA simple o bloquea comportamiento mediado por contratos.
Los investigadores identificaron 967 contratos activos en Ethereum que utilizaban esa comprobación como defensa contra préstamos relámpago (flash loans) y estimaron que aproximadamente 10,1 millones de dólares en activos presentaban alto riesgo potencial. Los robos detectados sumaron unos 2,36 millones, mientras que la cifra de 10,14 millones representa activos expuestos por un supuesto defensivo que dejó de ser válido.
El control delegado puede cambiar sin dejar rastro visible
El estudio documentó casos en los que atacantes reasignaban cuentas a código benigno después de un robo, lo que hace poco fiable la monitorización basada solo en el estado actual. También hallaron 500 destinos de delegación especiales distintos de cero sin código desplegado. Una dirección precalculada mediante CREATE2 podría recibir código más adelante, cambiando lo que ejecuta la cuenta sin que el destino registrado se modifique.
Esos patrones convierten el historial de autorizaciones en parte del perímetro de seguridad. Los monederos y herramientas de monitorización deben recordar dónde apuntaba previamente una cuenta, evaluar cambios en el código delegado y tratar un destino sin desplegar como no resuelto, no inofensivo.
Las reglas de clasificación del equipo pueden pasar por alto contratos maliciosos antes de que las transacciones preparatorias sean visibles o ataques que usan interfaces novedosas fuera del alcance del método. Los 924 contratos son el conjunto detectado y verificado manualmente; el universo total de abusos sigue siendo desconocido.
Recomendaciones para un comportamiento seguro por defecto
La orientación actual de ethereum.org pide a los monederos que mantengan listas blancas de contratos de delegación, muestren de forma prominente el destino, eviten delegación arbitraria en hardware wallets y dependan de implementaciones auditadas. Una propuesta de capacidad de monedero de abstracción de cuenta sigue la misma línea, solicitando una lista estricta de implementaciones bien conocidas y públicamente auditadas.
Las aplicaciones deben solicitar la funcionalidad que necesitan y dejar la implementación de cuenta al monedero. Para una aprobación y swap en un solo flujo, la guía de Ethereum Foundation señala a los desarrolladores una interfaz de monedero como ERC-5792. El monedero puede entonces elegir EIP-7702, ERC-4337 u otro sistema de cuenta sin pedir al usuario que apruebe código de delegación de bajo nivel seleccionado por la aplicación.
Un puntero benigno actual no puede borrar un historial malicioso, y un destino sin código puede adquirir comportamiento más tarde. Los monederos necesitan registros de autorización duraderos, alertas claras cuando cambia la delegación y una ruta de eliminación comprensible. Hacer segura la programabilidad de monederos EIP-7702 por defecto exige tratar la delegación como instalación del plano de control de la cuenta: restringir quién puede solicitarla, exponer exactamente qué controlará la cuenta, verificar cómo se inicializa y seguir vigilando después de que el puntero cambie.
Fuente: CryptoSlate · Esta información ha sido elaborada por la redacción de Criptonews con apoyo de herramientas editoriales automatizadas.