PHP2Shell: dos fallos críticos y un pánico que se adelantó al exploit
El 20 de octubre, un usuario identificado como petecooper publicó en el foro de Hacker News los identificadores de dos vulnerabilidades de PHP que debían seguir bajo embargo, según reportó Infosecurity Magazine. El mensaje, ya eliminado, aseguraba que eran dos fallos de ejecución remota de código (RCE) con puntuación máxima CVSS 10.0 y que afectaban a todas las versiones desde PHP 5.
El equipo de seguridad de PHP reaccionó con un aviso público y adelantó el calendario. Los parches salieron el 21 de octubre en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y la calificación oficial del proyecto quedó en 9.2 sobre 10, no en el 10.0 que circuló. Los fallos se registraron como CVE-2026-109618 y CVE-2026-109619, y los investigadores los bautizaron PHP2Shell.
El alcance potencial explica el ruido. Según datos de W3Techs citados por Infosecurity Magazine, PHP sostiene el 69,7% de los sitios web cuyo lenguaje de servidor se conoce. Investigadores de Wiz lo resumieron para CRN: "Con el 70% de internet afectado, el impacto de PHP2Shell no se puede exagerar".
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días¿Por qué medio sector entró en pánico antes de tener un exploit?
Las alertas llegaron desde todos los frentes. Wordfence advirtió que todo sitio en WordPress era vulnerable porque todos corren sobre servidores PHP, y GrapheneOS sacó su foro de discusión de línea de forma temporal "para no correr el riesgo", según The Verge. CERT-EU y el NCSC británico publicaron avisos de emergencia que recomendaban aislar las aplicaciones expuestas a internet cuando el parche no se pudiera aplicar de inmediato.
La frase que más circuló fue la de Sansec, que según The Verge esperaba "ataques masivos dentro de los 15 minutos posteriores al lanzamiento". El CTO de Cloudflare, Dane Knecht, dijo que ya veían "ataques tempranos" contra sitios PHP y que la compañía actualizaba reglas de firewall como parche temporal. El autor del análisis que originó esta nota recuerda además que un miembro del equipo central de PHP calificó el asunto de catastrófico, con la advertencia de que los exploits empezarían a aparecer 15 minutos después de que saliera el parche.
La tesis: un bug real no es lo mismo que un exploit fácil
Aquí está el aporte central del artículo original. El autor sostiene que el fallo existe y que importa, pero que no es fácil de explotar y que está lejos de casos como Log4Shell, Heartbleed, Shellshock o el decodificado YAML de Rails, donde los botnets empezaron a causar daño en cuestión de horas.
Su evidencia es concreta: en GitHub hay miles de "PoC" —pruebas de concepto, scripts que prometen demostrar la explotación— y ninguno funciona contra una instancia limpia de PHP. Muchos de esos scripts dependen de LFI (local file inclusion), es decir, exigen que el servidor ya tenga otra vulnerabilidad previa que permita leer archivos arbitrarios. Como prerequisito, eso desarma el argumento de severidad.
Y hay un detalle incómodo: según el autor, varios de esos PoC "funcionan" porque el propio LLM modificó el servidor de prueba para introducirle una vulnerabilidad grave. El exploit no rompe PHP: rompe un entorno preparado para que el exploit parezca funcionar.
El debate, eso sí, no está cerrado. WatchTowr reportó a CRN intentos de explotación activos contra ambos CVE, y CrowdStrike afirmó haber verificado un ataque "sin autenticación, sin sesión y sin código de aplicación vulnerable de por medio". Huntress, en cambio, no había observado explotación en su base de partners. La distancia entre "no hay exploit funcional" y "hay intentos de explotación" es exactamente la zona gris donde conviene no elegir bando sin datos propios.
¿Qué papel jugó la IA en todo esto?
Doble y contradictorio. Por un lado, Wiz reconoció a CRN que la IA fue clave para descubrir los fallos y construir exploits funcionales: "Con modelos de frontera y las herramientas adecuadas, un solo investigador completó en una semana lo que antes le habría tomado meses a un equipo de clase mundial". Los mismos investigadores señalan que el código vulnerable llevaba más de una década ahí.
Por el otro, la IA también fabricó el espejismo. El autor lo describe como "puntos de Schelling de decisión": cuando miles de personas le piden a un LLM que resuelva el mismo problema, todas reciben la misma respuesta, incluidos los mismos errores lógicos. De ahí que miles de PoC compartan el mismo defecto —depender de LFI— y que ninguno funcione.
Para un founder, la lección es incómoda: la IA acelera tanto la detección real como la falsa sensación de comprensión.
Qué significa esto para tu startup
Tres movimientos concretos.
1. Parchea igual, aunque el exploit sea difícil. La dificultad de explotación no es un argumento para esperar. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Huntress recomienda inventariar cada instalación de PHP, incluidas las que vienen embebidas en appliances de proveedores, paneles de control como cPanel y Plesk, y aplicaciones de Windows. Prioriza lo que está expuesto a internet.
2. Si estás en una rama sin soporte, aísla. PHP 8.1 y anteriores ya no reciben actualizaciones regulares. The Hacker News citó un conteo de la firma Mallory: alrededor de 884.000 hosts expuestos a internet reportaban PHP 8.1 o anterior a Shodan el 20 de octubre, el 59% de los 1,5 millones que declaraban alguna versión. Si tu producto vive en una de esas ramas, la recomendación de CERT-EU es sacarlo de la red pública o ponerlo detrás de una VPN o un WAF.
3. No aceptes un PoC generado por IA sin reproducirlo tú. El consejo del autor es directo: levanta un servidor PHP en Docker y corre el script con tus manos, no con las de tu asistente. Si el PoC necesita que el servidor ya tenga LFI, no estás ante una prueba de PHP2Shell.
Cómo monitorear si ya te tocó
SentinelOne advirtió, según CRN, que un atacante puede extraer contraseñas, tokens y claves de API de la memoria del proceso PHP sin ejecutar código, lo que dificulta la detección con herramientas centradas en ejecución maliciosa.
- Alerta cuando php-fpm, php-cgi, httpd o apache2 lancen shells, intérpretes o herramientas de descarga.
- Si detectas algo, aísla el servidor, preserva los logs de PHP y del servidor web, y busca web shells, archivos nuevos en la raíz web, cron jobs y cuentas nuevas.
- Como referencia de velocidad: cuando salió CVE-2024-4577 en junio de 2024, Akamai vio intentos de explotación contra sus honeypots en menos de 24 horas, según The Hacker News.
Conclusión
PHP2Shell es un recordatorio de dos cosas a la vez. La primera: un CVSS alto mide el daño potencial, no la facilidad de explotación, y confundir ambos lleva a decisiones malas en las dos direcciones —pánico innecesario o negligencia. La segunda: en 2026 la IA es parte del problema y de la solución. Aceleró el descubrimiento de un fallo que llevaba más de una década escondido y, al mismo tiempo, llenó GitHub de exploits que no funcionan.
La postura sensata para un equipo pequeño es la aburrida: parchear, inventariar, aislar lo que no se puede parchear y verificar cualquier prueba en tu propio entorno antes de creerle a nadie, humano o modelo.
Fuentes
- There isn't an easy exploit for this PHP vulnerability (fuente original)
- 5 Things To Know About 'Critical' PHP Vulnerabilities Exploitation
- Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches
- PHP2Shell: Two Unpatched Critical PHP RCE Flaws (CVSS 9.2) Trigger Emergency Security Alert
- A critical PHP vulnerability may take websites down today
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
