Check Point Research registró actividad vinculada a PHP2Shell en el 10% de las organizaciones del mundo y en el 14% de las europeas. Para una startup que apoya su web, su tienda o su panel de clientes en PHP —de forma directa o indirecta, a través de WordPress, Drupal o Joomla— ese número no es una estadística lejana: es la probabilidad de que parte de su infraestructura ya haya recibido intentos de explotación.
¿Qué es PHP2Shell y por qué la IA cambia el ritmo del ataque?
PHP2Shell es el nombre colectivo de CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades críticas en el propio motor de PHP que permiten ejecución remota de código (RCE) sin credenciales, según reportó Infosecurity Magazine. Según recogió MuyComputer, la severidad asignada es de 9,2 sobre 10 en la escala CVSS.
El detalle que más confunde a los equipos es dónde vive el fallo: no está en el CMS ni en los plugins, sino en la capa que los ejecuta. Actualizar WordPress sin actualizar PHP deja la puerta abierta, y ese malentendido es exactamente el que aprovecha un atacante.
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 díasAlex Spokoiny, director de Seguridad y Confianza de Check Point Software Technologies, describe el mecanismo con precisión: la IA puede analizar el código afectado, localizar la debilidad y desarrollar métodos de explotación incluso cuando los detalles técnicos son limitados. Después, plataformas automatizadas pueden escanear sistemas conectados a internet, encontrar objetivos vulnerables e intentar ataques a gran escala.
Su frase resume el cambio de régimen: "Lo que antes requería una investigación manual exhaustiva ahora se puede lograr mucho más rápido". El mismo diagnóstico llega desde Arctic Wolf: parte de estos fallos llevaba más de una década en el código, y lo que cambió no fue el software, sino "la capacidad de encontrar esas debilidades y convertirlas en exploits funcionales", según dijo a Cyber Daily Ismael Valenzuela, vicepresidente de labs e investigación de amenazas de la firma.
¿Cómo se filtró la vulnerabilidad y a qué velocidad escaló la explotación?
La cronología explica por qué el margen de respuesta se comprimió a horas. Los fallos se descubrieron en agosto por investigadores de Calif y de Wiz (Google Cloud), con colaboración del proyecto Patch the Planet de OpenAI, según Infosecurity Magazine. La divulgación estaba agendada para el 21 de octubre, pero el 20 de octubre un usuario anónimo filtró detalles en un foro antes de que los parches estuvieran listos. El equipo de PHP tuvo que adelantar la publicación de las versiones corregidas: 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
La explotación se adelantó también. Amazon confirmó que su sistema honeypot MadPot detectó un intento de ataque el 17 de octubre, cuatro días antes de la divulgación, siempre según Infosecurity Magazine. Ya con los parches publicados, Cloudflare midió la curva completa: miles de intentos en las diez horas previas al anuncio, decenas de miles en los 45 minutos siguientes, cientos de miles en dos horas y "millones ahora", según su cofundador y CEO Matthew Prince.
Para dimensionar el terreno de juego, Wiz estima que alrededor del 70% de los sitios web del mundo usan PHP, de acuerdo con lo recogido por MuyComputer. Y Alon Noy, cofundador de la firma Astelia, calculó que unos 2,2 millones de servidores exponen PHP a internet, de los cuales cerca de 900.000 corren versiones que ya no reciben actualizaciones, según informó Infobae.
En Estados Unidos, el FBI, la CISA y la NSA pidieron el 21 de octubre inventariar todos los puntos donde corre PHP y, cuando no fuera posible aplicar la corrección de inmediato, retirar los sistemas de internet. La CISA aclaró que hasta ese momento no había observado explotación activa, pero insistió en parchear lo antes posible los sistemas expuestos.
¿Por qué identificar tus aplicaciones no alcanza para medir el riesgo?
Spokoiny advierte que hacer la lista de aplicaciones que usa una empresa no determina su nivel de exposición. Los fallos de PHP2Shell alcanzan al entorno de ejecución del lenguaje, no necesariamente a cada aplicación construida sobre él.
Según el ejecutivo, el análisis debe cubrir cuatro capas:
- la infraestructura subyacente y las dependencias de software;
- el lugar donde se ejecutan los componentes;
- quién es el responsable de mantenerlos;
- y los proveedores de SaaS y servicios gestionados por terceros, que deben informar si están afectados y qué medidas adoptan.
Para ordenar esa tarea, Spokoiny propone un inventario de activos que incluya tecnologías, dependencias y responsables —no una simple lista de servidores— y la gestión continua de la exposición a amenazas, conocida como CTEM, que permite identificar, priorizar y validar de forma continua las debilidades accesibles con mayores consecuencias.
¿Cómo respondió Check Point mientras esperaba los parches?
El caso de la propia Check Point funciona como plantilla de respuesta. La compañía mapeó en paralelo los entornos donde usaba PHP, identificó sistemas potencialmente expuestos y restringió el acceso a determinados servicios. Verificó que otros sistemas contaran con las protecciones adecuadas y contactó a sus proveedores de SaaS para conocer sus planes de mitigación.
Sus equipos de producto implementaron nuevas protecciones IPS (sistemas de prevención de intrusiones) en las primeras horas posteriores a la notificación, las aplicaron en su propia infraestructura, las pusieron a disposición de sus clientes y publicaron avisos de seguridad y guías técnicas. Todo antes de tener los parches en la mano. "Las medidas de mitigación inmediatas son esenciales, pero solo nos dan un respiro", señaló Spokoiny.
La lógica que sostiene es de paralelismo, no de secuencia: identificación de la exposición, reducción del riesgo inmediato, despliegue de protecciones y preparación de soluciones permanentes deben avanzar al mismo tiempo. "Estas actividades no pueden esperar unas a otras", afirmó.
¿Qué significa esto para tu startup?
La buena noticia es que casi todo lo que hay que hacer depende de decisiones de gestión, no de contratar un equipo de seguridad de élite. Estas son las acciones con mayor impacto inmediato:
- Pregunta por la versión de PHP, no por el plugin. Si tu web corre sobre hosting compartido o un proveedor gestionado, exige confirmación por escrito de qué versión de PHP estás usando y si el parche ya se aplicó. No basta con verificar que la página abre: un sitio puede funcionar con normalidad y seguir siendo vulnerable.
- Si estás en PHP 8.1 o anterior, no habrá parche oficial. Infosecurity Magazine confirmó que las correcciones solo cubren las ramas soportadas (8.2 en adelante). Para versiones antiguas, la migración a 8.2 o superior es la única salida real, y conviene planificarla ya: el soporte de PHP 8.2 termina el 31 de diciembre de 2026.
- Mientras actualizas, aplica mitigaciones temporales. Restringir peticiones multipart/form-data, limitar el tamaño del cuerpo de las solicitudes y reiniciar los workers de PHP tras cambiar la configuración son medidas que reducen la exposición, según Infosecurity Magazine. Los WAF y los sistemas IPS compran tiempo, pero Check Point subraya que no sustituyen al parche.
- Asume que puede haber habido compromiso previo. Jiří Kohout, estratega de riesgo y seguridad de Check Point, advirtió a Cyber Daily que instalar el parche no elimina el código malicioso que un atacante ya haya dejado en el servidor. Si detectas archivos PHP nuevos, solicitudes inusuales, ejecución de comandos sospechosa o conexiones a direcciones desconocidas, hay que rotar credenciales y revisar logs.
Un punto que suele pasarse por alto: si eres una startup que no administra su propio servidor, el riesgo es indirecto pero real. Si una plataforma donde tienes cuenta fue vulnerada, tus datos —y los de tus clientes— pueden estar expuestos. Vale la pena revisar también los proveedores externos que tocan tu infraestructura, no solo la tuya.
Conclusión
PHP2Shell es el recordatorio de que la seguridad de una web ya no depende solo de mantener el CMS actualizado. Depende de saber qué corre por debajo, quién lo mantiene y qué tan rápido se puede reaccionar cuando la información se filtra antes de lo previsto. Según MuyComputer, uno de los problemas de gestión de memoria implicados ya había sido identificado en una auditoría en 2024, pero no se había demostrado que fuera explotable hasta ahora: el código no cambió, cambió la capacidad de encontrarle la vuelta.
Spokoiny no se arriesga a pronosticar si PHP2Shell tendrá el impacto de Log4Shell. Su respuesta, en cambio, es concreta: "No podemos controlar cuándo se descubrirá o divulgará la próxima vulnerabilidad crítica, pero sí podemos controlar nuestra preparación para responder".
Fuentes
- Infobae: la inteligencia artificial acelera los ataques de PHP2Shell
- Infosecurity Magazine: PHP2Shell exploitation attempt detected by Amazon four days before disclosure
- Cyber Daily: PHP2Shell, the time to patch is running out
- MuyComputer: PHP2Shell, el fallo de PHP que ha puesto en jaque a Internet
- Infobae: cómo actuar ante la alerta del FBI sobre PHP2Shell
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 días
