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

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.

Qué sigue sin confirmar

• Qué versiones antiguas están afectadas. Los primeros informes, recogidos por CERT-EU antes de la publicación, decían que los fallos podían afectar a todas las versiones desde PHP 5. Los avisos oficiales identifican las correcciones de las cuatro ramas con soporte, pero no precisan la primera versión afectada.
• 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. Otras configuraciones se consideran susceptibles a partir del análisis del código, y la fiabilidad depende de la compilación de PHP, sus extensiones y el servidor web que recibe las peticiones antes de pasarlas a PHP.
• 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.
• Los ataques reales. El 21 de octubre el director de tecnología de Cloudflare dijo que la empresa veía los primeros ataques, según recoge Tenable; eso no indica cuántos sistemas se vieron comprometidos. Ninguna de las dos CVE figuraba en el catálogo de vulnerabilidades explotadas de CISA (KEV) cuando lo consultamos el 21 de octubre.
• El código de explotación. Circula código que dice explotar PHP2Shell. Un exploit 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. 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.
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. Sansec sitúa el aviso de Cloudflare sobre los primeros ataques de PHP2Shell a las 07:43 UTC del 21 de octubre, antes de la publicación prevista.

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.

¿Quiere saber qué sitios y sistemas de su empresa son accesibles desde internet? Use Revisar mi empresa más abajo. Es una solicitud gratuita al equipo de IntruForce. Le respondemos por correo para acordar qué activos revisar y confirmar que tiene autorización para solicitarla. No se revisa nada antes. Una vez acordada, la revisión automática suele tardar unas horas.