De Binance a PHP2Shell: En la era de la IA, la línea de defensa de la seguridad web necesita ser redefinida

Los atacantes están penetrando toda la cadena de confianza, el d/acc de Vitalik también intenta redirigir la dirección acelerada de la tecnología hacia la defensa.

El 30 de octubre por la mañana, el mercado de criptomonedas volvió a ser escenario de un evento histórico de robo, esta vez le tocó a Binance.

Según investigaciones preliminares, los atacantes podrían haber accedido a un contenedor de servicio al hackear la computadora portátil de un ingeniero de DevOps, y enviar transacciones de retiro no autorizadas. Binance estima que el impacto total del evento asciende a 6.3 mil millones de dólares, y ya ha congelado aproximadamente 3 mil millones de dólares en activos relacionados.

Hablando de esto, en el último año, los eventos de seguridad en los principales intercambios se han vuelto tan frecuentes que resulta frustrante:

El año pasado, Bybit sufrió el robo de aproximadamente 1.46 mil millones de dólares en activos, y en septiembre de este año, Bitget tuvo aproximadamente 387.5 millones de dólares en activos transferidos sin autorización, y ahora Binance también se ve envuelto en una nueva controversia.

Si observamos los recientes eventos de seguridad en conjunto, se puede notar una tendencia clara: los atacantes están dejando de lado el ataque directo a la criptografía y las claves privadas, y en su lugar, están comenzando a enfocarse en toda la "cadena de confianza"------desde los terminales de los empleados, productos de seguridad de terceros, hasta la cadena de suministro de software, contenedores de servicio e incluso el proceso de autorización de transacciones; cualquier fisura en un eslabón puede comprometer toda la línea de defensa.

El rápido desarrollo de la IA también está amplificando aún más este riesgo.

El 22 de octubre, Vitalik Buterin, cofundador de Ethereum, presentó un nuevo juicio: en la era de la IA, el desenlace de la ciberseguridad podría favorecer a la defensa, pero el período de transición hacia este desenlace será extremadamente difícil.

I. De Bybit a PHP2Shell: los atacantes están penetrando toda la cadena de confianza

Primero, revisemos estos eventos.

Sus caminos de ataque no son los mismos, pero hay un punto en común: los atacantes no se han limitado a romper claves privadas o a vulnerar protocolos de blockchain, sino que simplemente han encontrado un eslabón de confianza en el sistema que se considera por defecto seguro.

• En el caso de Bybit, los atacantes infiltraron el dispositivo de un desarrollador de Safe mediante ingeniería social, obteniendo sus credenciales de acceso relacionadas, y luego controlaron los recursos frontales en la infraestructura de la billetera Safe;
• En el caso de Bitget, los atacantes aprovecharon una vulnerabilidad en un producto de seguridad de terceros, obteniendo credenciales internas de alto nivel, y luego eludieron el mecanismo de control de riesgos existente mediante instrucciones de retiro falsificadas;
• En el más reciente evento de Binance, el camino de ataque probablemente comenzó con la invasión de la computadora portátil de un ingeniero de DevOps;

Los tres eventos involucran infraestructuras de billeteras de terceros, productos de seguridad de terceros y entornos de desarrollo y operaciones internos.

Esto también explica por qué los tradicionales wallets fríos y mecanismos de múltiples firmas no pueden resolver todos los problemas, ya que lo que realmente utilizan los atacantes son esos eslabones de confianza que pueden afectar la ejecución final de las transacciones, pero que no han sido suficientemente verificados de manera independiente.

Y esta crisis de la cadena de confianza no solo existe en los intercambios de criptomonedas.

Justo una semana antes del ataque a Binance, el fundador de Binance, CZ, había tuiteado específicamente, advirtiendo a todos que debían ser extremadamente cautelosos al acceder a cualquier sitio web en los próximos días------en ese momento, dos vulnerabilidades de alto riesgo en el núcleo de PHP de PHP2Shell (CVE-2026-109618 y CVE-2026-109619, con una puntuación CVSS v4.0 de 9.2) estaban causando pánico en toda la red.

Como el lenguaje de servidor de código abierto que sostiene aproximadamente el 70% de los sitios web globales, plataformas principales como WordPress, Magento y Drupal se construyen sobre PHP.

Y estas dos vulnerabilidades de gestión de memoria y restablecimiento de estado global que han estado latentes durante más de diez años, permiten a los atacantes ejecutar código de forma remota (RCE) sin necesidad de autenticación, simplemente con una solicitud web específica, tomando el control del servidor e implantando puertas traseras o robando credenciales de usuario.

Los datos de escaneo de las agencias de ciberseguridad Palo Alto Networks y Censys muestran que hay más de 22.6 millones a 36.7 millones de instancias expuestas en la red pública que están en riesgo.

Aún más sorprendente es que, según las agencias de seguridad, estas dos vulnerabilidades de estado de memoria de bajo nivel, que han estado latentes durante más de diez años y son extremadamente difíciles de detectar por auditores humanos, han sido descubiertas gracias a la tecnología de IA; en otras palabras, la IA ha reducido drásticamente la barrera para convertir defectos lógicos ocultos en cargas de ataque utilizables.

Hemos discutido anteriormente las tres transformaciones cualitativas en los métodos de ataque cibernético en la era de la IA (lectura adicional "¿Cómo se actualiza la carrera armamentista entre el 'arma' y el 'escudo' de Web3 cuando los hackers son 'más eficientes' con la IA?"):

• La "industrialización" de la explotación de vulnerabilidades de día cero (0-day): en el pasado, encontrar vulnerabilidades profundas de memoria en el núcleo de PHP o en el firmware requería que los mejores expertos en seguridad dedicaran meses a auditorías de código manuales y pruebas de fuzzing, ahora la IA puede escanear globalmente repositorios de código abierto las 24 horas del día a un costo muy bajo, convirtiendo errores antiguos de más de diez años en armas mortales en masa;
• La compresión extrema de la "ventana de tiempo de parches" (N-day): una vez que la información sobre una vulnerabilidad se filtra o se envía código de parche, los atacantes maliciosos pueden utilizar IA para revertir el parche en minutos, generar automáticamente variantes de explotación y completar escaneos e inyecciones automatizadas en toda la red, haciendo que los cronogramas de actualización que los equipos de operaciones tradicionales calculan en días o semanas sean irrelevantes frente a scripts de ataque de IA que responden en milisegundos;
• La cadena de suministro de software y DevOps se convierten en el principal punto de ruptura: los modernos sistemas Web3 y financieros no se construyen en un vacío, la interacción del frontend, los contenedores de backend, los paquetes de dependencia de terceros NPM/PyPI y el entorno de desarrollo local de los ingenieros, constituyen una cadena de suministro de código abierto extremadamente grande y frágil;

Tal como se infiltró el contenedor de DevOps de Binance y el ataque de alteración de la cadena de suministro que sufrió Bybit, dado que los ataques en la cadena son los más fáciles de monetizar, la industria de las criptomonedas está experimentando primero una "ola global de ataques de hackers de IA de nivel pandémico".

Por supuesto, no todos los ataques mencionados son iniciados o ejecutados directamente por IA, pero la IA está amplificando simultáneamente las capacidades de los atacantes y de los defensores, y en el actual sistema de ingeniería de software, este efecto de amplificación en realidad agrava la asimetría estructural que ya existe entre ambas partes.

II. Vitalik: El desenlace puede favorecer a la defensa, pero el "período de transición" será extremadamente difícil

Frente a la discusión de la industria provocada por la detección de vulnerabilidades de bajo nivel como PHP2Shell por parte de la IA, Vitalik Buterin ofreció un juicio muy calmado el 22 de octubre: el desenlace a largo plazo de la ciberseguridad podría formar un patrón favorable para la defensa, pero el período de transición será extremadamente difícil.

¿Por qué?

Porque en el actual paradigma de ingeniería de software, hay una asimetría natural entre atacantes y defensores. Un sistema de software grande puede contener millones de líneas de código histórico, cientos de dependencias externas y una gran cantidad de rutas de permisos y ejecución complejas.

Los defensores deben asegurarse de que todos los eslabones clave sean lo suficientemente seguros, mientras que los atacantes solo necesitan encontrar un solo punto débil que aún no ha sido descubierto.

Vitalik señaló que depender únicamente de los investigadores de seguridad para descubrir vulnerabilidades en el software ya publicado antes que los hackers no puede realmente establecer una ventaja defensiva, porque si ambas partes utilizan IA cada vez más poderosa, en esencia, todavía están compitiendo para ver quién puede encontrar vulnerabilidades más rápido.

Lo que realmente necesita cambiar es la forma en que se construye el software, como él propuso en dos direcciones clave: la verificación formal (Formal Verification) y la minimización de la base de computación confiable (Trusted Computing Base, TCB).

Primero, la verificación formal, que busca reemplazar la "depuración basada en la experiencia" con pruebas matemáticas.

Las pruebas de software tradicionales solo pueden demostrar que "no hay errores en los escenarios probados", pero nunca pueden demostrar que "el código no tiene errores en absoluto", mientras que la verificación formal utiliza lógica matemática rigurosa para demostrar que un fragmento de código de programa cumple estrictamente con las normas de seguridad esperadas en todas las posibles entradas y transiciones de estado, sin defectos como desbordamientos de memoria, estados no restablecidos (como PHP2Shell) o reentradas lógicas.

En el pasado, el costo de la verificación formal era extremadamente alto, la cantidad de código necesaria para escribir pruebas matemáticas a menudo era varias veces mayor que la del código de negocio, solo la industria aeroespacial o los protocolos criptográficos centrales podían permitírselo.

Pero en la era de la IA, la IA no solo puede encontrar vulnerabilidades, sino que también puede convertirse en un asistente superpoderoso para escribir pruebas de verificación formal, por lo que Vitalik predice que en el futuro, la "verificación formal asistida por IA" se convertirá en la forma final de desarrollo de software------ya sea en protocolos de comunicación encriptados como Signal, TLS, ZK-EVM, o en contratos inteligentes a nivel de aplicación, todos pueden generar automáticamente pruebas matemáticas de seguridad de extremo a extremo a través de IA antes de que se publique el código.

Cuando un fragmento de código se demuestra matemáticamente como "impecable", incluso la IA más poderosa de los atacantes no puede encontrar vulnerabilidades que no existen.

En segundo lugar, la minimización de la base de computación confiable (TCB), que busca reducir al mínimo la superficie de ataque.

¿Qué es la base de computación confiable (TCB)? En términos simples, es la suma de todos los componentes de hardware y software que un sistema debe confiar incondicionalmente para garantizar la seguridad.

Recordando el evento de seguridad de 6.3 mil millones de dólares de Binance y el evento de secuestro de múltiples firmas de Bybit: ¿por qué no se rompió el algoritmo de clave privada subyacente, pero se perdieron los activos? Porque su TCB era demasiado grande------un enorme clúster de contenedores, complejas líneas de permisos de operación, el sistema operativo de la computadora portátil del desarrollador, las bibliotecas de JavaScript renderizadas en el frontend, todo se incluyó en la cadena de confianza que "una vez comprometida, puede llevar a la pérdida de fondos".

La idea central de la minimización de TCB es hacer sustracción y aislamiento: reducir las funciones que realmente involucran la protección de claves privadas, la verificación de firmas y la autorización central a un entorno de seguridad más pequeño, con límites más claros, que pueda aceptar auditorías estrictas, mientras que otras funciones complejas deben ejecutarse en entornos periféricos con permisos restringidos.

Incluso si el navegador, los complementos, los servicios frontend o los agentes de IA son atacados, no deberían obtener la capacidad de movilizar activos de los usuarios sin restricciones.

Desde esta perspectiva, también está el valor de billeteras no custodiales como imToken. Al usar un intercambio centralizado, los activos de los usuarios deben pasar por cuentas de la plataforma, billeteras custodiales y un sistema interno de retiros; mientras que al usar imToken, los usuarios gestionan sus propias claves privadas, administran directamente los activos en la cadena y realizan transacciones, reduciendo así el intermediario de la custodia centralizada.

Una cadena de confianza más corta significa menos exposición al riesgo a nivel de plataforma, y no hay que preocuparse por la suspensión de retiros o el congelamiento del saldo de la cuenta de la plataforma. Por supuesto, los usuarios también deben asumir la responsabilidad de la custodia de sus claves privadas y la seguridad de sus dispositivos.

III. De la aceleración técnica al aceleracionismo defensivo: ¿por qué necesitamos d/acc?

Si la verificación formal y la minimización del TCB responden a la pregunta de "¿cómo ser más seguros técnicamente?", entonces el d/acc, promovido a largo plazo por Vitalik, intenta responder a una pregunta más macro:

¿Cómo deberíamos priorizar el desarrollo tecnológico cuando la IA y otras tecnologías de vanguardia están cambiando rápidamente el mundo?

d/acc, que significa Aceleracionismo Defensivo, se refiere a una "aceleración selectiva": priorizar el desarrollo de tecnologías que puedan aumentar la capacidad de defensa social, descentralizar el poder y reducir el riesgo sistémico.

En comparación con el e/acc, que enfatiza la aceleración total, el d/acc se centra más en si la tecnología está aumentando la capacidad de ataque o mejorando la capacidad de defensa (lectura adicional: "Cuando Web3 se encuentra con d/acc: ¿qué puede hacer Crypto en la era de la aceleración tecnológica?").

Desde la perspectiva de d/acc, este sistema de defensa abarca la construcción en profundidad de cuatro dimensiones:

• Defensa cibernética: reducir la tasa de éxito de los ataques cibernéticos mediante criptografía, verificación formal, aislamiento de software y detección de vulnerabilidades, protegiendo así los activos digitales y los datos;
• Defensa biológica: mejorar la capacidad de la sociedad para enfrentar riesgos de seguridad biológica mediante la detección de patógenos, monitoreo del aire, desarrollo de vacunas y tecnologías de salud pública;
• Defensa física: reducir la vulnerabilidad de las infraestructuras críticas del mundo real ante ataques mediante energía distribuida, redes de comunicación resistentes y construcción de resiliencia;
• Defensa de la información: resistir la desinformación, la falsificación profunda y la manipulación masiva de información mediante protección de la privacidad, verificación de fuentes de información y mecanismos de colaboración descentralizados;

Estos campos pueden parecer muy diversos, pero todos giran en torno a un objetivo: mientras la tecnología sigue potenciando las capacidades de individuos y organizaciones, también deben obtener una capacidad de auto-protección que esté a la par, evitando que tecnologías más poderosas se concentren solo en unos pocos con recursos y control.

Fue en la discusión sobre la reciente crisis de vulnerabilidades de PHP donde Vitalik reafirmó una de sus afirmaciones más contundentes dentro del marco de d/acc: ante el impacto asimétrico de la IA de vanguardia, se debe ser cauteloso con el avance desordenado de la IA agresiva de alto riesgo en las etapas necesarias; al mismo tiempo, toda la sociedad debería invertir sistemáticamente más del 1% del PIB en ciberseguridad, seguridad biológica y en el refuerzo de la seguridad del mundo físico.

¿Por qué se necesita una inversión sistemática de tal magnitud?

Porque los beneficios del avance tecnológico a menudo pueden ser rápidamente valorados y comercializados por el mercado, pero el valor de la infraestructura de seguridad a menudo es subestimado.

Las empresas están dispuestas a invertir grandes sumas de dinero en modelos de IA más potentes, mayor capacidad de cálculo y herramientas de desarrollo de software más eficientes, pero no necesariamente están dispuestas a proporcionar un apoyo equivalente para el mantenimiento a largo plazo del software de código abierto, la verificación formal y las auditorías de seguridad. Si no se corrige proactivamente esta desajuste de recursos, el gran edificio digital construido sobre una base de código abierto frágil solo se volverá más peligroso.

Conclusión

Desde los riesgos expuestos por PHP2Shell en la infraestructura global de Internet, hasta los recientes eventos de seguridad en Bybit, Bitget y Binance, la situación de ciberseguridad en 2026 está recordando a todos con un costo real:

La competencia de ataque y defensa en la era de la IA ya no se trata solo de quién puede descubrir vulnerabilidades más rápido, sino de si todo el ecosistema de software puede establecer un sistema de defensa suficientemente confiable.

La seguridad nunca puede ser una solución definitiva, pero eso no significa que sea una guerra de desgaste imposible de ganar.

En las últimas décadas, la criptografía ha demostrado que ciertas capacidades de defensa pueden establecer una fuerte garantía de seguridad a través de principios matemáticos, en lugar de depender únicamente de que los defensores inviertan más mano de obra.

La combinación de IA con verificación formal, minimización de la computación confiable y otras tecnologías también tiene la oportunidad de expandir esta idea a todo el sistema de software.

Para los usuarios comunes, esta filosofía de seguridad también puede aplicarse a la elección de métodos de gestión de activos.

Elegir billeteras no custodiales como imToken, en esencia, significa mantener el control de los activos en manos propias, reduciendo la dependencia de plataformas centralizadas y sistemas operativos internos. Por supuesto, esto también significa que los usuarios deben prestar más atención a la custodia de las frases de recuperación, la seguridad de los dispositivos y la autorización de cada transacción, pero al menos, la capacidad de disponer de los activos ya no depende completamente de si una plataforma centralizada está funcionando correctamente.

Quizás esto es lo que Vitalik quiso decir con que el final de la ciberseguridad podría favorecer a los defensores: no se trata de esperar un día en que la IA no pueda encontrar ninguna vulnerabilidad, sino de avanzar constantemente para que los sistemas clave que necesitamos seguir funcionando, incluso frente a atacantes cada vez más inteligentes, puedan seguir operando de manera confiable gracias a un núcleo confiable más pequeño, límites de permisos más estrictos y mecanismos de seguridad más verificables.

El avance tecnológico merece ser acelerado, pero la capacidad de proteger los logros tecnológicos y los activos individuales también necesita ser acelerada.