PHP2Shell: Casi el 70 % de los sitios web utilizan PHP. ¿Sabe cuáles de los suyos están expuestos?

Nuestra opinión

Nosotros no empezaríamos por discutir la gravedad de PHP2Shell, sino por la lista de sitios y servicios, incluidos los que dejó un contratista o un proyecto terminado.

IntruForce

El 21 de octubre de 2026 el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen dos vulnerabilidades críticas en el propio PHP, CVE-2026-109618 y CVE-2026-109619, conocidas ya como PHP2Shell. El aviso de seguridad de PHP dice que los dos fallos «pueden permitir la ejecución remota de código sin autenticación»: si se cumplen las condiciones descritas en los avisos, quien pueda llegar al sitio por la red podría ejecutar su propio código en el servidor sin iniciar sesión. PHP califica ambas como críticas: 9,2 sobre 10 en la escala de gravedad CVSS v4.0, y pide a todos sus usuarios que actualicen de inmediato.

En una rama con soporte, la corrección es una actualización de versión. Solo se puede aplicar en los servidores que usted conoce, así que el paso difícil es identificar qué sitios web, subdominios y servicios antiguos de su empresa siguen usando PHP.

Qué sabemos y qué sigue sin confirmar

Qué sabemos

• Dos identificadores: CVE-2026-109618 (ejecución remota de código por un estado dañado tras quedarse sin memoria) y CVE-2026-109619 (ejecución remota de código por datos internos de una petición anterior que el mismo proceso de PHP vuelve a utilizar).
• PHP califica ambas como críticas, 9,2 en CVSS v4.0. Los avisos de PHP para CVE-2026-109618 y CVE-2026-109619 describen un ataque posible por la red, sin cuenta y sin interacción del usuario, pero de complejidad alta y con requisitos que dependen de cómo esté desplegado PHP.
• Versiones corregidas, publicadas el 21 de octubre de 2026: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
• PHP considera en riesgo «todas las instalaciones de PHP que atienden peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed». El riesgo más alto lo atribuye a mod_php, donde se ha demostrado un exploit funcional.
• PHP 8.1 y anteriores ya no reciben versiones nuevas del proyecto PHP. Por la gravedad del caso, el equipo de seguridad de PHP publicó parches mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta. Las distribuciones Linux y los proveedores de soporte extendido recibieron los parches por adelantado y pueden publicar sus propios paquetes corregidos.
• Según PHP, solo la actualización es una solución completa. Los ajustes temporales del aviso reducen vías de ataque concretas, pero no dejan la instalación segura.
• CISA incluyó CVE-2026-109618 y CVE-2026-109619 en su catálogo de vulnerabilidades explotadas (KEV) el 26 de octubre de 2026, la lista de fallos que sabe que se usan en ataques. Las entradas no identifican a las organizaciones afectadas.
• El 23 de octubre PHP añadió una recomendación: hasta la próxima actualización de mantenimiento, configure session.upload_progress.enabled=0 en php.ini o en la configuración del servidor, no en el código de la aplicación. La medida aborda otra vulnerabilidad, CVE-2026-115560, que las versiones del 21 de octubre no corrigen. Según PHP, requiere una combinación poco habitual de ajustes de sesión; pida al administrador que compruebe las condiciones exactas en el aviso de PHP.
• Instalar los paquetes actualizados no corrige los procesos de PHP que ya están en marcha. Reinicie los procesos de PHP que atienden peticiones web después de actualizar y después de aplicar estos ajustes, y confirme que todos usan la versión corregida.

Qué sigue sin confirmar

• Cuál es la primera versión afectada. Los avisos oficiales solo indican versiones corregidas para las cuatro ramas con soporte. Los investigadores de Calif dicen que el código afectado más antiguo que encontraron es de PHP 5.4.0; el proyecto PHP no ha confirmado una versión de inicio.
• Con qué fiabilidad se pueden explotar en un servidor concreto. Los avisos confirman el impacto en Apache con mod_php y, para CVE-2026-109619, en PHP-FPM bajo condiciones concretas de la aplicación y del despliegue. El análisis del código de PHP indica que otras configuraciones también podrían estar afectadas. Según Tenable, Trail of Bits demostró el 26 de octubre código de explotación funcional contra PHP 8.2 a 8.5 sin corregir; en un servidor real, el resultado sigue dependiendo de la compilación de PHP, sus extensiones y el servidor web que recibe las peticiones.
• La escala. Tenable cita dos recuentos distintos: una estimación de más de 1,3 millones de servidores accesibles desde internet que podrían ser vulnerables y una búsqueda en Shodan con más de 1,9 millones de servidores con PHP. Ninguno indica si esos sistemas tienen las correcciones o cumplen las condiciones de explotación.
• Cuántos ataques tienen éxito. El equipo de inteligencia de amenazas de Amazon informó de un intento de explotación el 17 de octubre, cuatro días antes de la corrección, y ahora describe intentos generalizados; aclara que no sabe si tendrían éxito contra sistemas reales. watchTowr informa de actividad de PHP2Shell contra sus servidores trampa el 21 de octubre. El 24 de octubre Adel Karimi documentó la ejecución de comandos en tres servidores trampa con PHP 8.4.26, Apache con mod_php y un solo proceso; las pruebas eran compatibles con CVE-2026-109618, no con CVE-2026-109619. Estos informes no permiten saber cuántas organizaciones sufrieron una intrusión.
• El código de explotación. Circula código que dice explotar PHP2Shell, y los ataques que registró Karimi coinciden en gran medida con una familia de pruebas de concepto públicas. Un código no verificado puede contener malware, así que no lo ejecute para probar sus propios servidores.

Por qué actualizar los plugins no lo resuelve

Estos fallos están en el propio PHP, el lenguaje sobre el que funciona la aplicación. WordPress, Drupal, PrestaShop, Magento y muchos otros sistemas usan PHP, pero actualizar el CMS, un plugin o una plantilla no actualiza por sí solo el software PHP del servidor. La corrección tiene que llegar con una nueva versión de PHP o con un paquete corregido de su distribución o de su proveedor de alojamiento.

Usar PHP no demuestra por sí solo que estos fallos se puedan explotar en un sitio: las condiciones oficiales anteriores dependen de la versión, de cómo se conecta PHP al servidor web y de su configuración. Pero la pregunta «¿nos afecta?» solo puede responderse para los servidores que usted conoce.

Las reglas de un firewall de aplicaciones web son una medida provisional. Según Sansec, Cloudflare desplegó reglas temporales contra los intentos de explotación conocidos. Cubren el tráfico que pasa por Cloudflare; las peticiones directas al servidor las evitan.

¿Qué sitios de su empresa usan PHP?

W3Techs detecta PHP en el 69,3 % de los sitios web cuyo lenguaje de servidor puede identificar (W3Techs, 21 de octubre de 2026). Una parte significativa de ellos sigue en ramas antiguas que el proyecto PHP ya no mantiene: según W3Techs, PHP 7 está en el 27,0 % de los sitios PHP y PHP 5 en el 7,7 %. Es una medida de las versiones en uso, no de cuántos sitios son vulnerables, y algunas distribuciones y proveedores comerciales trasladan correcciones a versiones antiguas.

Al hacer la lista, incluya los sitios que tienen un alojamiento o un mantenimiento distinto del de la web principal, por ejemplo:

• una copia de pruebas de la web que quedó publicada al terminar un proyecto;
• la página de una campaña comercial antigua que sigue publicada en un subdominio olvidado;
• un panel de alojamiento o un correo web con interfaz en PHP;
• una web que hizo una agencia y que sigue alojada en la cuenta de esa agencia;
• la web de una filial o de una delegación, por ejemplo en México o en Colombia, gestionada fuera del área de TI central.

No se puede parchear lo que no se sabe que existe. Un servidor que no está en la lista puede quedarse sin actualizar. Anote quién actualizó cada sitio y cómo lo comprobó.

Ver PHP desde fuera tampoco equivale a confirmar la vulnerabilidad. A veces un servidor deja ver PHP y su versión, por ejemplo en la cabecera X-Powered-By, pero esa cabecera puede estar desactivada, y el número de versión no indica si la distribución ha incorporado las correcciones. Un sitio que no muestra versión puede seguir usando PHP. Para confirmarlo, pida al administrador o al proveedor de alojamiento la versión de PHP en uso, la revisión del paquete y el aviso de seguridad correspondiente.

Cinco comprobaciones para empezar ahora

1. Haga inventario de sus sitios web públicos, subdominios y servicios relacionados, incluidos los que gestionan agencias, filiales y proveedores de alojamiento.
2. Anote, cuando sea posible, la tecnología, la versión y la persona responsable de cada sitio.
3. Localice las instalaciones de PHP antiguas o sin soporte, incluidas PHP 8.1 y anteriores.
4. Consulte la información oficial de PHP y de su distribución o proveedor de alojamiento, y siga los avisos de su equipo nacional de respuesta, como INCIBE-CERT en España o el CSIRT Nacional de Chile. Si un producto incluye su propia copia de PHP, como un dispositivo, una herramienta de seguridad o un panel de alojamiento, consulte el aviso del fabricante sobre actualizaciones o medidas compatibles. Actualice los sistemas afectados o limite su exposición hasta poder hacerlo. Pida al administrador o proveedor la versión y la revisión del paquete PHP que utiliza cada sitio, junto con el aviso que cubre ambas correcciones, y la confirmación de que se reiniciaron los procesos de PHP. Si un servidor pudo ser atacado antes de actualizarse, pídales que conserven sus registros y revisen la actividad desde el 17 de octubre.
5. Establezca un seguimiento periódico de los cambios en su superficie de ataque externa, para que los sitios y servicios nuevos entren en la lista cuando aparezcan.

Por qué una revisión puntual no basta

Se publican vulnerabilidades críticas nuevas con regularidad, y la lista de sus sistemas accesibles desde internet cambia cada vez que se publica, se traslada o se retira un sitio. Si solo revisa sus sistemas una vez al año, puede pasar por alto una vulnerabilidad publicada entre revisiones. En el caso de PHP2Shell, Amazon informó de un intento de explotación cuatro días antes de que se publicara la corrección.

Ya hemos visto este patrón: en la cadena de tres CVE de PAN-OS, lo decisivo era una interfaz de gestión accesible desde fuera; tras CVE-2023-20198 en Cisco IOS XE, la primera pregunta volvió a ser qué equipos exponían su interfaz web. En ambos casos la respuesta empieza por una lista actualizada de lo que está expuesto.