Bug bounty y PHP2Shell: no lances exploits a ciegas
Cada vez que aparece un CVE gordo, medio mundo corre a cobrar un bug bounty rápido. Con PHP2Shell está pasando lo mismo, y a lo grande. Sin embargo, una cosa es detectar qué versión de PHP corre un servidor y otra muy distinta lanzar un exploit contra la máquina de otro. Los que llevamos años en esto lo tenemos claro: aquí las prisas se pagan caras.
Qué es PHP2Shell y por qué dispara la fiebre del bug bounty
PHP2Shell es el nombre con el que se conoce a dos fallos críticos del propio lenguaje. Se trata de CVE-2026-109618 y CVE-2026-109619, cuyos detalles se filtraron el 20 de octubre, antes de la divulgación coordinada y de los parches. Además, ambos se puntúan con un 9,2 en la escala CVSS v4.0.
El problema afecta a gran parte de la web. Los investigadores de Calif, OpenAI y Wiz hallaron dos fallos sin autenticación que afectan a instalaciones PHP que sirven peticiones web, como PHP-FPM, Apache con mod_php o LiteSpeed. Por tanto, hablamos de millones de servidores potencialmente expuestos.
La corrección llegó rápido. PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y avisa de que solo actualizar protege del todo. Si administras servidores, te dejo nuestra guía sobre la vulnerabilidad PHP con dos fallos RCE críticos. Actualiza antes de seguir leyendo.
Detectar la versión es sencillo, explotarla es otra liga
Averiguar qué versión de PHP usa un objetivo está al alcance de cualquiera. Vale con un escáner básico, con las cabeceras HTTP o con una herramienta de reconocimiento. Nuestra nueva app, ReconHive, que estará disponible en breve, también te ayudará con ese primer paso de inventariado.
Ahora bien, saber que algo es vulnerable no te da permiso para reventarlo. En un programa de bug bounty, la mayoría de las veces basta con demostrar que el activo está expuesto y avisar al equipo. Después, la empresa decide cómo y cuándo se prueba el impacto real.
Ya hay exploits públicos circulando. Es fácil imaginar a cientos de personas lanzándolos a diestro y siniestro, con la esperanza de cobrar. De hecho, watchTowr ya observa intentos activos de explotación de ambos CVE. Muchos de esos intentos no serán de investigadores, sino de delincuentes. Tú no quieres que te confundan con ellos.
Por qué explotar sin hablar con la empresa es una locura
Estamos ante fallos de corrupción de memoria. Uno de los exploits envía un cuerpo POST de varios megabytes con un nombre de campo enorme para provocar un fallo de memoria. En un servidor de producción, eso puede acabar en cuelgues, reinicios o caídas del servicio. Lo lógico es que un intento fallido tumbe procesos en lugar de ejecutar código limpiamente.
Además, el impacto no se queda en tu prueba. Estos son los riesgos más habituales:
- Caída de la web o de la aplicación y pérdida de ventas o de servicio.
- Corrupción de datos o sesiones de usuarios reales.
- Exposición accidental de información de terceros.
- Alertas del equipo de respuesta, que te tratará como un atacante.
- Descalificación del programa y, en el peor caso, denuncia.
Por eso la explotación debe hacerse de forma controlada. Hay que acordarlo con la empresa, usar un entorno de pruebas o una ventana pactada y limitar el alcance al mínimo. No es postureo, es sentido común. Un servidor roto no se arregla con una disculpa.
La legalidad del bug bounty: no todo vale
Mucha gente cree que un programa le da carta blanca. No es así. Cuando una empresa publica un programa, autoriza probar los activos que enumera. Lo que queda fuera del alcance sigue sin estar autorizado.
Tampoco hay garantías absolutas. Muchos programas incluyen términos legales que no ofrecen un puerto seguro (safe harbor) al investigador. Por eso conviene leer la letra pequeña. Y ojo con las fronteras: probar algo fuera del scope, aunque sea por accidente, puede ser ilegal incluso con un programa activo.
En España, el Código Penal castiga el acceso ilegal a sistemas (art. 197 bis) y los daños informáticos (art. 264). Estas normas penalizan el acceso no autorizado con independencia de la intención. Por tanto, «yo solo quería el bounty» no sirve como defensa. Ante la duda, consulta con un abogado especializado.
Cómo practicar el bug bounty con cabeza
Si quieres cobrar sin meterte en líos, sigue unas reglas simples:
- Comprueba que el activo está dentro del scope del programa.
- Verifica que existe safe harbor y lee las reglas sobre DoS y pruebas intrusivas.
- Detecta la versión y reporta la exposición antes de explotar nada.
- Pide autorización expresa si hace falta una prueba de concepto.
- Haz el PoC mínimo y documéntalo todo.
Recuerda también que las pruebas deben limitarse al mínimo imprescindible para demostrar el fallo, y el PoC mínimo es el estándar ético y legal. Eso no te quita premio. Al contrario, te da reputación y te abre puertas.
En resumen, PHP2Shell es una oportunidad para el bug bounty serio, no para la ruleta rusa. Detectar es fácil y legítimo. Explotar a ciegas es una mala idea con daños que luego no se deshacen. Habla con la empresa, pacta las reglas y cobra con la conciencia tranquila. Si necesitas contexto técnico, consulta el resumen de BleepingComputer sobre los parches de emergencia o el análisis de watchTowr.
Fuentes
- BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
- watchTowr: PHP2Shell RCE Exploited
- The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws
- Abstract Security: PHP2Shell flash report
- Cursos de Ciberseguridad: Bug bounty, guía completa
- CSO Online: Bug bounties offer legal safe harbor. Right? Right?
