Un escéptico puso $500 en bitcoin como cebo y acabó demostrando que se equivocaba: PHP2Shell sí puede explotarse

Hace un par de semanas, dos vulnerabilidades críticas de PHP hicieron que una parte considerable de los sitios web quedara fuera de línea para actualizarse. Inmediatamente después del anuncio aparecieron “expertos” que afirmaban que la situación no era tan grave y que explotar las vulnerabilidades en el mundo real era casi imposible. Su principal argumento: nadie había publicado un exploit funcional. Uno de los escépticos decidió comprobarlo en la práctica.

Un cebo de $500

El autor creó un sitio web, colocó en él la clave privada de una cartera de bitcoin con $500 y publicó el enlace en Hacker News: hackéenlo y quédense con el dinero. Durante las primeras horas nadie lo consiguió y, por supuesto, los comentaristas lo interpretaron como una confirmación de que tenían razón.

Pero las causas eran bastante prosaicas. En primer lugar, el sitio recibió una avalancha de tráfico, se caía y dejaba muchas solicitudes sin respuesta. En segundo lugar, el propio sitio no era vulnerable. Tenía PHP instalado e incluso servía la página principal, pero la configuración no coincidía con la afectada por la vulnerabilidad.

El autor añadió recursos al servidor y reescribió el código, que era demasiado sencillo y no se parecía al de los sitios habituales. Después de eso, la vulnerabilidad funcionó y un hacker obtuvo la clave. Es cierto que el autor terminó proporcionando una clave equivocada, pero eso ya es un detalle secundario.

La admisión del escéptico

En la publicación final de su blog escribió que su opinión había sido incorrecta: PHP2Shell sigue siendo una amenaza real y puede explotarse. También considera que la explotación continúa siendo difícil y que una persona sin experiencia, armada únicamente con un LLM, probablemente no lo conseguiría.

Esta conclusión es discutible. Es probable que la mayoría de los intentos no fueran serios: la gente no gastó muchos tokens ni utilizó los modelos más inteligentes. Además, esos modelos suelen bloquear las solicitudes relacionadas con hackeos.

También hay datos. Un experto que hackeó OpenAI hace varios meses afirma que, en sus pruebas, solo Mythos y Sol-5.6 ejecutan el ataque en 2–4 horas. Los modelos abiertos GLM-5.3 y Kimi K3.1 estuvieron funcionando durante más de 20 horas sin lograrlo, y el investigador duda de que los modelos abiertos sean capaces de hacerlo en absoluto.

Esto también responde a una pregunta popular: ¿por qué no se oyen noticias de hackeos procedentes de China? ¿Acaso los estadounidenses solo están creando expectación? A juzgar por estas pruebas, no se trata de mera publicidad: los modelos disponibles allí todavía no tienen las capacidades necesarias para esta tarea.

Qué hacer en la práctica

Primero: no espere a que aparezca un exploit público para actualizar. Las demostraciones en video de ataques contra productos reales incluidas en el anuncio ya constituyen pruebas suficientes. La ausencia del código solo significa que no se ha publicado.

Segundo: si está comprobando afirmaciones de terceros sobre una vulnerabilidad, reproduzca la configuración de producción y no un entorno de pruebas simplificado. Que un servidor tenga PHP no significa que esté afectado por el problema. Ese fue precisamente el error del escéptico, y los defensores que se consideran seguros pueden cometer el mismo fallo.

Tercero: evalúe los riesgos teniendo en cuenta las capacidades de los modelos de frontera. Un ataque que tarda unas horas con un modelo potente resulta barato en comparación con el coste del tiempo de inactividad. Las pruebas poco exigentes con modelos baratos y un presupuesto reducido de tokens generan una falsa sensación de seguridad.

Limitaciones

Esta es la historia de un único experimento y un único conjunto de pruebas. Los datos sobre los modelos proceden de un solo investigador, no de un benchmark independiente. La explotación sigue exigiendo conocimientos y recursos. Pero la conclusión es sencilla: actualice sin esperar una demostración elegante.