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 robo histórico, esta vez le tocó a Binance.

Según una investigación preliminar, los atacantes podrían haber accedido a un contenedor de servicio al infiltrarse en la computadora portátil de un ingeniero de DevOps, y luego enviaron 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 incidentes 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 incidentes de seguridad en conjunto, se puede notar una tendencia clara: los atacantes están cada vez menos inclinados a atacar directamente la criptografía y las claves privadas, y en su lugar, comienzan 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 los procesos 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 los defensores, 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 incidentes.

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

• 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 para obtener credenciales internas de alto nivel, y luego eludieron el mecanismo de control de riesgos existente mediante instrucciones de retiro falsificadas;
• En el último incidente de Binance, la ruta de ataque probablemente comenzó con la infiltración de la computadora portátil de un ingeniero de DevOps;

Los tres incidentes 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 monederos fríos y mecanismos de firma múltiple no pueden resolver todos los problemas, ya que lo que realmente utilizan los atacantes son aquellos eslabones de confianza que pueden influir en la ejecución final de las transacciones, pero que no han sido 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, hizo un tweet 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 críticas en el motor central 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 en todo el mundo, plataformas principales como WordPress, Magento y Drupal están construidas sobre PHP.

Y estas dos vulnerabilidades de gestión de memoria y reinicio 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 en riesgo.

Lo 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.

Anteriormente, también hemos discutido en varias ocasiones las tres transformaciones cualitativas en los métodos de ataque cibernético en la era de la IA (lectura adicional "Cuando los hackers son 'más eficientes' usando IA, ¿cómo se actualiza la carrera armamentista entre 'la lanza y el escudo' de Web3?"):

• La "industrialización" de la explotación de vulnerabilidades de día cero (0-day): En el pasado, encontrar vulnerabilidades profundas en el motor central de PHP o en el firmware requería que los mejores expertos en seguridad dedicaran meses a la auditoría de código manual y pruebas de fuzzing, ahora la IA puede escanear globalmente los repositorios de código abierto las 24 horas del día a un costo muy bajo, convirtiendo en masa los bugs antiguos que han estado latentes durante diez años en armas letales;
• La compresión extrema de la "ventana 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 la IA para invertir el parche, generar automáticamente variantes de exploit y completar escaneos e inyecciones automatizadas en toda la red en minutos, mientras que los equipos de operaciones tradicionales calculan las actualizaciones en días o semanas, frente a los scripts de ataque de IA que responden en milisegundos, esto resulta insignificante;
• 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 en este caso, y la alteración de la cadena de suministro frontal que sufrió Bybit, dado que los ataques en la cadena son los más fáciles de monetizar, la industria de criptomonedas está experimentando una ola de "ataques cibernéticos globales de IA a nivel de pandemia".

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á increíblemente difícil

Frente a la discusión de la industria provocada por la IA al descubrir vulnerabilidades de bajo nivel como PHP2Shell, 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 los defensores, 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 caminos de permisos y ejecución complejos.

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

Vitalik señaló que depender únicamente de que los investigadores de seguridad descubran 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 los dos enfoques centrales que propuso: verificación formal (Formal Verification) y minimización de la base de cálculo de confianza (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 se encontraron bugs en los escenarios probados", pero nunca pueden demostrar que "el código está absolutamente libre de bugs", mientras que la verificación formal utiliza lógica matemática rigurosa para demostrar que un 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 reiniciados (como PHP2Shell) o reentradas lógicas.

En el pasado, el costo de la verificación formal era extremadamente alto, y la cantidad de código necesaria para escribir pruebas matemáticas a menudo era varias veces mayor que el 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 encriptada 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 la publicación del código.

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

En segundo lugar, la minimización de la base de cálculo de confianza (TCB), que busca reducir al mínimo la superficie de ataque.

¿Qué es la base de cálculo de confianza (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.

Al revisar el evento de seguridad de 6.3 mil millones de dólares de Binance y el incidente de secuestro de la firma múltiple de Bybit: ¿por qué el algoritmo de clave privada subyacente no fue comprometido, pero los activos se perdieron? 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 fue incluido en la cadena de confianza que "una vez comprometida, resultará en la pérdida de fondos".

La idea central de la minimización de TCB es hacer restas y aislar: 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 rigurosas; otras funciones complejas deben ejecutarse en entornos periféricos con permisos restringidos tanto como sea posible.

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 como resultado.

Desde esta perspectiva, también está el valor de billeteras no custodiales como imToken. Al usar un intercambio centralizado, los activos del usuario deben pasar por cuentas de la plataforma, billeteras custodiales y un sistema interno de retiros; mientras que al usar imToken, los usuarios mantienen sus propias claves privadas, gestionan 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:

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

d/acc, que significa Aceleracionismo Defensivo, se refiere a una forma de acelerar de manera 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 la aceleración total enfatizada por e/acc, 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 en cuatro dimensiones:

• Defensa cibernética: reducir la tasa de éxito de ataques cibernéticos mediante criptografía, verificación formal, aislamiento de software y detección de vulnerabilidades, protegiendo activos digitales y datos;
• Defensa biológica: mejorar la capacidad de la sociedad para enfrentar riesgos de seguridad biológica mediante 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 parecen abarcar un amplio espectro, pero todos giran en torno a un objetivo: mientras la tecnología continúa mejorando las capacidades de individuos y organizaciones, también deben obtener la capacidad de auto-protección correspondiente, evitando que tecnologías más poderosas se concentren solo en unos pocos que tienen recursos y control.

También en la discusión sobre la reciente crisis de vulnerabilidades de PHP, Vitalik reafirmó una de sus afirmaciones más contundentes dentro del marco de d/acc: frente a los impactos asimétricos traídos por la IA de vanguardia, en las etapas necesarias se debe tener precaución ante el avance desordenado de la IA agresiva de alto riesgo; al mismo tiempo, toda la sociedad debería invertir sistemáticamente más del 1% de su PIB en la seguridad cibernética, la seguridad biológica y el refuerzo de la seguridad en el mundo físico.

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

Porque los beneficios derivados 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, en mayor capacidad de cálculo y en herramientas de desarrollo de software más eficientes, pero no necesariamente están dispuestas a proporcionar un apoyo de igual magnitud para el mantenimiento a largo plazo del software de código abierto, la verificación formal y la auditoría 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.

Reflexiones finales

Desde los riesgos expuestos por PHP2Shell en la infraestructura de Internet global, hasta los importantes incidentes de seguridad que han ocurrido en Bybit, Bitget y Binance, la situación de la 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 tarea única, 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 defensivas 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 aún más 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 la custodia de plataformas centralizadas y de los 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 sea lo que Vitalik quiso decir con que el final de la ciberseguridad podría favorecer a la defensa: no esperar un día en que la IA no pueda encontrar vulnerabilidades, sino avanzar constantemente para que nuestros sistemas clave, que dependen de su funcionamiento, puedan seguir operando de manera confiable incluso frente a atacantes cada vez más inteligentes, apoyándose en núcleos confiables más pequeños, límites de permisos más estrictos y mecanismos de seguridad más verificables.

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