PHP2Shell: dos fallos críticos en PHP dejan webs fuera de servicio en Europa y obligan a actualizar ya

1. Qué ha ocurrido

El 20 de octubre, el equipo de seguridad de PHP anunció una versión de emergencia para el día siguiente. Según watchTowr, los detalles se filtraron en redes sociales ese mismo día, antes de la fecha de divulgación prevista, que era el 22 de octubre. El 21 de octubre se publicaron las versiones corregidas y el aviso de seguridad.

Los fallos son dos. El CVE-2026-109618 es una corrupción de memoria al gestionar una situación de falta de memoria: según PHP, el programa puede interrumpirse con datos internos de la petición a medio inicializar, y la limpieza posterior los trata como válidos. El CVE-2026-109619 se debe a que un estado interno de una petición puede sobrevivir después de que su memoria se haya liberado, y una petición posterior atendida por el mismo proceso puede usarlo. PHP asegura que ambos pueden permitir ejecución remota de código sin autenticación.

Wiz Research afirma haberlos descubierto en agosto y haberlos comunicado a PHP el 24 de agosto. OpenAI, por su parte, dice que investigadores de Calif los encontraron con sus herramientas unos dos meses antes, dentro de su programa «Patch the Planet». Wiz asegura que usó modelos de inteligencia artificial para descubrir los fallos y adaptar las pruebas de concepto a distintas versiones y configuraciones.

2. A quién afecta

Según PHP, están en riesgo todas las instalaciones que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El mayor riesgo es mod_php, donde PHP dice tener una demostración en la que una petición sin autenticar activa el ataque antes de que se ejecute código de la aplicación. Las versiones corregidas son:

• PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
• PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto. Hay parches de código fuente para 7.4, 8.0 y 8.1, y algunas distribuciones o proveedores ofrecen versiones propias con la corrección.
• watchTowr indica que las ramas antiguas sin soporte, incluida PHP 5, también están afectadas y sin corrección oficial.

PHP es muy común: Imperva dice que lo usan más del 69 % de las webs cuyo lenguaje de servidor se conoce, y Wiz habla del 70 %, aunque ninguno cita la fuente de esa cifra. Sobre cuántas instalaciones concretas son vulnerables hay cifras muy distintas, porque miden cosas diferentes. Recorded Future recoge 4.384.302 servicios PHP en 1.886.612 equipos según Modat, y unos 5,1 millones de direcciones IP con PHP según VirusTotal. De las que declaran su versión, Modat calcula que alrededor del 79 % usa una rama sin soporte. Unit 42 habla de más de 22,6 millones de instancias expuestas potencialmente vulnerables, sin explicar cómo las ha medido. Recorded Future subraya que son cifras de exposición, no de equipos comprobados como vulnerables.

3. ¿Se está explotando?

Las fuentes no coinciden del todo, y conviene decirlo así:

• CISA afirmó el 21 de octubre que no había observado explotación en el momento de publicar su aviso. watchTowr indica que, a 22 de octubre, ninguno de los dos fallos estaba en el catálogo de vulnerabilidades explotadas de CISA.
• watchTowr dice haber observado explotación real desde el 21 de octubre en su red de señuelos. Uno de sus responsables declaró a The Record que «nadie ha tenido éxito hasta la fecha», aunque no espera que dure.
• Cloudflare declaró, por boca de su director técnico, que ya veía ataques y desplegó reglas de mitigación. Recorded Future añade que Patchstack comunicó incidentes de explotación activa a partir de avisos de proveedores de alojamiento, antes de que PHP publicara el parche.
• Rapid7 habla de varias pruebas de concepto públicas, cada una válida solo para una combinación concreta de sistema, versión de PHP y servidor web, y no ha observado explotación real, aunque la espera.
• El equipo de inteligencia de amenazas de Recorded Future señala que la información disponible no permite saber cuántos intentos han tenido éxito ni confirmar compromisos.

4. El impacto: webs que se desconectan

Lo que sí se ve con claridad es la reacción. The Record informa de «cientos» de webs caídas el 21 de octubre, con administraciones que desconectaron sitios antes de que hubiera parche, y cita a Nintendo y al hospital Charité de Berlín entre las organizaciones que retiraron servicios mientras actualizaban. Unit 42 confirma que al menos un gobierno europeo desconectó su web por precaución, y The Record menciona avisos de la UE, Estados Unidos, Alemania, Japón, Australia, Reino Unido y Países Bajos.

UptimeRobot, un servicio que monitoriza la disponibilidad de webs, midió el 21 de octubre unas 11 veces más alertas de caída que un día normal, con un máximo de unas 37.000 por minuto frente a las 3.300 del día anterior. En Europa, las alertas se multiplicaron por unas 20 y en Norteamérica por unas 6, mientras que en Asia y Oceanía apenas cambiaron. La proporción de comprobaciones que no lograron conectar pasó de aproximadamente el 0,55 % habitual a cerca del 1,7 % entre las 14:00 y las 18:00 UTC. Por dominios, UptimeRobot contó 14.682 webs .nl inaccesibles el 21 de octubre frente a 4.356 el día anterior, y 18.422 .de frente a 8.660. A las 09:00 UTC del 22 de octubre, las alertas seguían un 30 % por encima de lo normal.

Escudo Digital, un medio español, relata cierres preventivos en portales públicos de varios países europeos y dice que en España no hubo caídas generalizadas de los portales de los ministerios, pero sí desconexiones y ventanas de mantenimiento en administraciones locales, organismos de investigación y universidades. No hemos podido contrastar ese relato con las propias administraciones.

5. ¿Y el impacto económico?

Lo que sí consta son indicadores del alcance de la interrupción: las alertas de caída de UptimeRobot, el porcentaje de comprobaciones fallidas, las organizaciones que retiraron servicios y los avisos de varios gobiernos. Esos datos muestran que el coste existe, porque una web desconectada no vende ni atiende, pero no permiten ponerle un importe. Parte de las caídas fueron decisiones deliberadas: es lo que recomendaba CISA a quien no pudiera actualizar. UptimeRobot atribuye el pico a cierres planificados, aunque no dice qué parte del total representan.

6. Qué hacer

1. 1

   Haz inventario de dónde hay PHP

   CISA pide localizar todos los sistemas con PHP, también el que viene dentro de otro software. Sophos, citada por The Record, señala que la mayor dificultad es encontrar todas las instancias.
2. 2

   Actualiza ya, empezando por lo expuesto a Internet

   Instala PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o un paquete de tu distribución o proveedor que incluya las dos correcciones. Según INCIBE, la actualización es la única solución completa.
3. 3

   Si usas PHP 8.1 o anterior, no esperes un parche oficial

   Aplica los parches de código fuente para 7.4, 8.0 y 8.1 si puedes, pide una versión corregida a tu proveedor o migra a una rama con soporte. PHP 8.2 dejará de recibir soporte el 31 de diciembre de 2026.
4. 4

   Si no puedes actualizar, aísla o desconecta

   CISA y INCIBE recomiendan retirar del acceso público el sistema que no se pueda actualizar. Los ajustes provisionales de PHP reducen vías conocidas, pero no hacen segura la instalación.
5. 5

   Vigila señales de compromiso

   CISA sugiere buscar procesos de PHP que lancen una consola de comandos o descarguen herramientas. Wiz apunta a peticiones multipart inusuales seguidas de errores de límite de memoria, errores HTTP 500 repetidos y cookies de sesión anormalmente largas.

7. En España

INCIBE-CERT publicó el 21 de octubre el aviso INCIBE-2026-762, con importancia 5 (crítica), en el que recomienda actualizar de inmediato, confirmar con los proveedores que sus paquetes incluyen las correcciones y, si no se puede actualizar un sistema expuesto, aislarlo de las redes públicas. Su aviso indica que se comunicaron ataques antes de publicarse las actualizaciones, sin precisar qué fallo se usó en cada caso. Escudo Digital menciona además una alerta del CCN-CERT dirigida a las instituciones, que no hemos podido verificar en la web del organismo.

8. Qué sabemos, qué no y qué son hipótesis

9. Qué significa para tu empresa

Si tienes una web, una tienda online o una intranet hecha en PHP, esto te afecta aunque no sepas qué es PHP. Tres ideas sirven para cualquier empresa:

• Pregunta hoy a quien te gestiona la web o el hosting qué versión de PHP usa y cuándo la actualizó. Pídele la respuesta por escrito.
• No dependas de una versión sin soporte. Cuando una rama deja de recibir parches, cada fallo nuevo se queda sin arreglo oficial.
• Ten un inventario y un plazo máximo para parchear lo que está expuesto a Internet. Es una de las medidas básicas que exige la directiva NIS2.

Preguntas frecuentes

Información actualizada a 23 de octubre de 2026 a partir de los avisos oficiales y de la prensa y los informes especializados. El asunto evoluciona deprisa: las cifras, las versiones y el estado de la explotación pueden cambiar. Consulta siempre el aviso de PHP y el de INCIBE.