PHP2Shell, el nombre colectivo de dos vulnerabilidades críticas del motor PHP, tiene por fin un dato a favor de los equipos de seguridad: la cantidad diaria de máquinas expuestas a internet y vulnerables a estas fallas cayó cerca de 67% en pocos días, según la telemetría de Wiz. Para una startup que corre su producto sobre PHP —el lenguaje detrás de cerca del 70% de los sitios web, según BleepingComputer— la pregunta ya no es si el riesgo existe, sino si su inventario de servidores está realmente al día.
¿Qué es PHP2Shell y por qué debería importarte?
PHP2Shell agrupa dos fallas del runtime de PHP: CVE-2026-109618, una corrupción que se dispara cuando el manejo de memoria agotada interrumpe a PHP con datos de petición parcialmente inicializados, y CVE-2026-109619, un estado interno que sobrevive después de que su memoria fue liberada. Ambas habilitan ejecución remota de código sin autenticación y fueron calificadas con 9.2 sobre 10 en CVSS, según The Hacker News.
El alcance explica la urgencia. Censys estima que más de 32,51 millones de servicios PHP seguían corriendo una versión afectada, de acuerdo con The Hacker News, y la propia telemetría de Wiz muestra que PHP está presente en el 65% de las organizaciones de su base de datos.
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →Las versiones afectadas van de PHP 5.4 a 8.5.11. El equipo de PHP publicó los parches el 21 de octubre de 2026 en las ramas 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según The Hacker News. Para PHP 8.1 y anteriores no hay parche oficial: esas ramas ya alcanzaron su fin de vida.
¿Qué encontró Wiz en su telemetría de explotación?
La conclusión central del reporte es incómoda para quien busca certezas: Wiz no observó ninguna explotación completa de extremo a extremo en su propia telemetría, y tampoco identificó un proof of concept público que funcione de forma general contra un objetivo arbitrario.
Eso no significa que el riesgo sea teórico. La firma aclara que algunos socios le compartieron de forma privada exploits que sí funcionan contra una variedad de objetivos, y que su equipo sigue experimentando internamente. Los videos con esas explotaciones exitosas están publicados en php2shell.com.
El contraste con el resto del sector es la parte que conviene leer dos veces. CISA agregó las dos fallas a su catálogo de vulnerabilidades explotadas (KEV) y ordenó a las agencias federales estadounidenses parchear antes del 29 de octubre, según Computer Weekly. La decisión llegó después de que Adel Karimi, responsable de detección y respuesta de Perplexity, confirmara ejecución remota de código en sus honeypots el 24 de octubre de 2026, de acuerdo con The Hacker News. Karimi describió el resultado como RCE confirmado con divulgación de memoria utilizable, y detalló que la respuesta entregó un volcado de cookie decodificado de 800 KiB.
La letra chica importa: ese éxito se logró sobre una configuración Apache mod_php de un solo worker, un escenario deliberadamente favorable. Como advirtió el propio Karimi, no es una medición de confiabilidad en otros conteos de workers, builds de PHP o aplicaciones.
Las dos variantes del kit de explotación que circula
Wiz capturó dos variantes de un kit de explotación de código abierto. Ninguna completó la cadena en los intentos registrados.
- Variante 1 (cadena legacy): el primer intento llegó desde 3.37.227[.]134 con un cuerpo multipart de 1.005 partes, incluido un campo llamado
bigcon unos 12 MB de relleno. Falló antes de llegar al código vulnerable: el tamaño declarado superaba el límite de 8 MB depost_max_size, así que PHP ni procesó el cuerpo. Un intento posterior desde 103.151.172[.]95 apuntó a un honeypot de Roundcube con conexiones estancadas para ocupar workers de Apache, pero tampoco alcanzó la condición de agotamiento de memoria. - Variante 2 (cadena actual): la más frecuente en las capturas. Su primera etapa sí agotó la memoria de PHP de forma consistente —el servidor registró errores fatales del tipo "Allowed memory size of 67108864 bytes exhausted"—, pero la etapa siguiente, que intenta filtrar memoria del proceso, falló en todas las ejecuciones.
También apareció tráfico etiquetado como PHP2Shell que no explotaba ninguna de las dos vulnerabilidades. El más temprano, desde 85.11.187[.]35, usaba una técnica clásica de envenenamiento de sesión más una vulnerabilidad de inclusión local de archivos (LFI) de la propia aplicación. El detalle revelador: el kit asumía la existencia de un endpoint vulnerable que solo existe en el entorno de laboratorio del PoC. Sin ese endpoint, no hay ejecución de código.
¿Por qué la cadena se rompe tan seguido?
Un exploit genérico es mucho más difícil de lo que parece. La etapa de filtrado del kit calculó su diseño de memoria para la imagen oficial php:8.4.26-apache con un límite de 128 MB. El honeypot de Roundcube de Wiz corría la misma versión de PHP pero desde un build distinto, con extensiones adicionales y un límite de 64 MB. Esas diferencias cambian el layout del heap y el reuso de memoria, y pueden romper el filtrado.
A eso se suma el problema del worker pinning: las peticiones consecutivas del exploit tienen que caer en el mismo proceso hijo de Apache mientras el estado de sesión persiste. Timeouts, latencia de red y disponibilidad de workers pueden interrumpir la secuencia. En las pruebas de Wiz, esa combinación bastó para impedir que la cadena se completara a través de una conexión a internet.
CrowdStrike llegó a una lectura parecida: la weaponización completa tardó más de lo esperado porque los atacantes necesitaban adaptar el PoC a la versión de PHP y a la aplicación específica de cada víctima, lo que exigía conocimiento de contenedores Docker y paquetes concretos, según Computer Weekly.
La caída del 67%: qué están haciendo las organizaciones
El otro hallazgo del reporte es la velocidad de la remediación. Desde la divulgación pública del 21 de octubre de 2026, Wiz registró:
- Una caída aproximada del 67% en el número diario de máquinas distintas expuestas a internet y vulnerables a PHP2Shell.
- Una baja de 8,3% a 5,7% en la proporción de esas máquinas que corren PHP 7.3 o anterior, medida en cinco días.
- Una reducción de aproximadamente 47,9% en el número de organizaciones con al menos una instancia expuesta y vulnerable.
Wiz aclara que estos datos muestran la tendencia general, pero no permiten atribuir cuánto aportó cada estrategia: parchear, actualizar, retirar máquinas o restringir el acceso desde internet.
El tracker gratuito de Infrawatch ofrecía otra foto del mismo fenómeno: hacia las 12:00 UTC del 27 de octubre, unos 443.000 hosts públicamente visibles ya estaban parcheados, unos 31.000 más que 24 horas antes y cerca del 20% del total. Por país, el Reino Unido iba en 27,2% de hosts visibles y Estados Unidos en 19,7%, según Computer Weekly.
El problema es la cola larga. Un conteo de Shodan publicado por Mallory el 20 de octubre encontró unos 884.000 hosts expuestos a internet que anunciaban una versión de PHP sin soporte: el 59% de los aproximadamente 1,5 millones que revelan su versión, según Notebookcheck. El desglose de CybelAngel sobre esos datos ubicaba a PHP 5.x en unos 369.000 hosts, PHP 7.x en 329.000 y PHP 8.0/8.1 en 186.000. Palo Alto Networks contó por separado más de 22,6 millones de instancias potencialmente vulnerables.
Y hay una fecha que se viene encima: PHP 8.2 llega a su fin de soporte el 31 de diciembre de 2026, según Notebookcheck. Quien se sienta tranquilo por haber aplicado el parche 8.2.35 tendrá que volver a moverse en poco más de dos meses.
¿Qué significa esto para tu startup?
Si tu producto corre sobre PHP —y con un 70% del web usándolo, las probabilidades son altas—, esto no es un problema de "los grandes". Es tu stack, tus plugins, tu CMS y, muy probablemente, el de tus proveedores.
1. Verifica la versión real, no la que anuncia el banner. El número de versión puede engañar: las distribuciones de Linux a veces aplican el parche manteniendo la cadena antigua. Ubuntu 22.04 parchea su paquete PHP 8.1 por el canal de seguridad normal, mientras que PHP 7.4 en Ubuntu 20.04 requiere Ubuntu Pro, según Notebookcheck. Revisa el changelog del proveedor buscando ambos CVE antes de dar por cerrado el tema.
2. Si estás en PHP 8.2, planifica el salto ahora. El fin de soporte es el 31 de diciembre de 2026. Aprovecha noviembre para hacer backup y probar tu aplicación en 8.3 o 8.4, en lugar de improvisar en la última semana del año.
3. Reinicia el proceso que realmente sirve las peticiones. Actualizar paquetes en disco deja binarios vulnerables como libphp.so o php-fpm residentes en los workers en ejecución. Google Cloud recomienda reiniciar explícitamente php8.x-fpm, apache2/httpd, frankenphp o lsws después de parchear.
4. Aplica mitigaciones de borde mientras terminas de parchear. Google Cloud documenta varias que atacan justo los mecanismos que usan estos kits: poner pm.max_requests = 1 para que cada worker se reinicie tras cada petición, bloquear multipart/form-data en rutas que no reciben archivos, rechazar Transfer-Encoding: chunked, limitar el tamaño del cuerpo a 8 MB y bloquear cookies PHPSESSID con bytes nulos o caracteres fuera del formato esperado.
5. Audita a tus terceros. Como advirtió Madelein van der Hout, de Forrester, revisar solo el sitio principal deja fuera a proveedores y aplicaciones relacionadas, y parchear no expulsa a un atacante que ya está dentro, según Notebookcheck. Si tu startup integra un CMS, un panel de facturación o un ERP de un proveedor externo, pregunta explícitamente por su versión de PHP.
6. No te confíes porque "no pasó nada". El único caso público de RCE confirmado ocurrió en una configuración favorable de un solo worker. Eso no es una garantía de que tu setup sea inmune: es una señal de que los atacantes todavía están adaptando sus herramientas, y de que esas barreras se van a reducir con el tiempo.
Conclusión
PHP2Shell deja una lección que va más allá de un par de CVE. La remediación funcionó y la exposición cayó con fuerza en días, pero el exploit exitoso apareció igual, sobre una configuración específica y con ayuda de un honeypot bien instrumentado. La diferencia entre las organizaciones que salieron bien paradas y las que quedaron expuestas no fue tener un WAF, sino saber con precisión qué versión de PHP corría cada servicio, quién lo mantenía y cuándo había que reiniciarlo.
Para una startup con equipo pequeño, la prioridad es simple: inventario primero, parche después, y una fecha en el calendario para el fin de soporte de PHP 8.2. Y una advertencia extra del propio reporte: el equipo de PHP publicó mitigaciones para una nueva falla de RCE, CVE-2026-115560, que no tiene parche y solo es explotable en combinaciones inusuales de configuración y código, según BleepingComputer. La superficie no se cierra sola.
Fuentes
- PHP2Shell: Exploitation attempts and remediation trends (fuente original)
- CISA confirms PHP2Shell vulnerabilities now exploited in attacks
- PHP2Shell: US updates Kev catalogue as exploits spread
- CISA Confirms Active Exploitation of Two PHP2Shell Flaws Enabling Remote Code Execution
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619
- PHP2Shell leaves millions of servers on PHP versions with no official fix
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →
