Swell pausa depósitos y retiros de swETH y rswETH tras alertas de compromiso de hot keys
Puntos clave
- •Swell pausó los depósitos y retiros de swETH y rswETH el 23 de octubre mientras trabaja con socios de seguridad, incluido Seal911, para asegurar su infraestructura.
- •El investigador de seguridad Spreek reportó el 22 de octubre que las claves de administrador de swETH y rswETH parecían comprometidas, con atacantes elevando el NAV de los tokens hasta un 1% por hora sin respaldo correspondiente en ETH.
- •Cuatro contratos de actualización maliciosos capaces de robar unos 2.500 ETH fueron desplegados en cadena, pero nunca fueron encolados a través del multisig, por lo que no pudieron entrar en vigor.
- •El gas fue barrido desde decenas de hot keys de Swell en Ethereum, Arbitrum, HyperEVM y Base hacia una única wallet del atacante, con la primera actividad anómala rastreada aproximadamente las 14:25 UTC del 21 de octubre.
- •Swell afirmó que ningún ETH había salido de sus contratos de depósito o retiro e identificó el restablecimiento del NAV al valor correcto como el paso necesario antes de reabrir depósitos y retiros.

Swell ha pausado los depósitos y retiros de sus tokens swETH y rswETH después de que investigadores advirtieran que las claves administrativas y operativas (hot keys) parecían comprometidas y que las tasas de cambio de los tokens estaban siendo incrementadas sin el respaldo correspondiente en Ether.
El protocolo de staking líquido anunció la pausa el 23 de octubre y dijo que trabaja con socios de seguridad, incluido Seal911, para asegurar su infraestructura y devolver el valor patrimonial neto (NAV) al nivel correcto, según la actualización oficial del protocolo.
La congelación siguió a un día de advertencias de investigadores en cadena indicando que los incrementos de tasa sin respaldo habían alcanzado el máximo permitido en cadena y que contratos de actualización capaces de drenar unos 2.500 ETH habían sido preparados, aunque no encolados.
Investigadores señalan hot keys comprometidas y actualizaciones preparadas
El 22 de octubre, el investigador de seguridad Spreek informó que las claves de administrador del swETH y el rswETH de Swell DAO parecían comprometidas, y que atacantes estaban elevando el NAV hasta un 1% por hora sin respaldo. Según Spreek, cuatro contratos de actualización maliciosos habían sido desplegados, pero aún no habían sido encolados a través del multisig, y esos contratos podrían robar cerca de 2.500 ETH. Spreek publicó un informe del incidente de compromiso de hot keys y advirtió que Claude había redactado partes del documento, por lo que algunos detalles permanecían sin verificar, aunque las afirmaciones principales en cadena seguían pareciendo sólidas.
La cronología del informe sitúa la primera actividad anómala aproximadamente a las 14:25 UTC del 21 de octubre, cuando el bot del oráculo comprometido financió una wallet de despliegue. Más tarde ese día, el gas fue barrido desde decenas de hot keys de Swell —claves operativas conectadas a internet, a diferencia del almacenamiento en frío— en Ethereum, Arbitrum, HyperEVM y Base hacia una wallet central del atacante.
Desde las 23:02 UTC, las tasas de cambio de swETH y rswETH comenzaron a subir un 1% por hora —el máximo del contrato— sin que llegara ETH correspondiente junto con los incrementos. Ejemplos de transacciones de incremento incluyen swETH a las 23:02 y rswETH a las 23:35. El informe también indicó que el bot redirigió a los reclamantes de recompensas de EigenLayer de decenas de StakerPro de rswETH hacia esa misma wallet.
Cuatro payloads de actualización dirigidos a swEXIT, rswEXIT y los gestores de depósitos habrían añadido una ruta de barrido si llegaran a instalarse. Payloads como estos solo surten efecto una vez que se encolan a través del multisig y transcurre un retraso de timelock, razón por la cual importaba el estado de preparados pero no encolados: los contratos existían en cadena pero aún no podían actuar. Un enlace a la plataforma Railway fue mencionado en el informe solo como especulación; Spreek dijo que no había pruebas contundentes y que parecía una coincidencia temporal.
Primera respuesta de Swell y luego la congelación
Horas después de las publicaciones de los investigadores, Swell dijo que estaba al tanto de actividad sospechosa en los contratos de swETH y rswETH y que investigaba con socios de seguridad. El equipo subrayó que ningún ETH había salido de los contratos de retiro o depósito de swETH o rswETH, y que los tenedores no necesitaban tomar ninguna acción en ese momento.
El seguimiento del 23 de octubre estrechó el perímetro. Los depósitos y retiros de ambos tokens fueron pausados, y Swell nombró a Seal911 entre sus socios, afirmando que todos los fondos estaban a salvo. El protocolo indicó que restablecer el NAV al valor correcto era el siguiente paso antes de reabrir los depósitos y retiros. Swell también advirtió a los usuarios que trataran el riesgo de phishing como elevado y que confiaran solo en canales oficiales. Los hitos concretos de aquí en adelante son los que ya están en el registro: el restablecimiento del NAV, la reapertura de depósitos y retiros y —verificable en cadena— si los cuatro payloads de actualización preparados son eliminados y las claves afectadas son rotadas.
Por qué importa la pausa
El episodio pone de relieve que el riesgo de los tokens de staking líquido (LST) no se limita a exploits de contratos inteligentes: también depende de quién sostiene las claves que mueven la tasa.
swETH y rswETH son recibos de staking líquido y restaking. Cuando un bot del oráculo puede marcar la tasa de cambio más alta sin nuevo ETH detrás, los mercados secundarios y las plataformas de préstamos que leen getRate() heredan un precio distorsionado. Y cuando los payloads de actualización están listos para un timelock, el siguiente modo de fallo es una instalación privilegiada, no un señuelo de phishing minorista.
La congelación de Swell detiene nuevos depósitos y retiros mientras los socios trabajan para revertir el incremento sin respaldo y rotar las claves comprometidas. Rotar las claves es la remediación estándar ante un compromiso de hot keys, ya que reemplazar las credenciales es la forma en que el protocolo revoca el acceso de escritura a la tasa. Es un lenguaje de contención, y no es lo mismo que decir que la superficie de ataque nunca se abrió.
La secuencia —primero un hilo de investigador, luego una declaración de que "los fondos están a salvo", y después la pausa— es una conocida en los incidentes de seguridad de protocolos. La tecnología de staking líquido sigue cambiando, pero las hot keys comprometidas siguen siendo capaces de escribir su próximo capítulo.
Fuente: Live Bitcoin News