Fallo crítico en PHP (PHP2Shell): qué hacer hoy si tu web es WordPress o Joomla

Hoy hay portales públicos de media Europa en mantenimiento por un fallo de PHP, no por un plugin olvidado. Si tu web está hecha con WordPress, Joomla u otro programa que corre sobre PHP, el trabajo de esta tarde es concreto: saber qué versión exacta tienes, parchear y, si eso no llega a tiempo, dejar la web fuera de línea hasta que llegue.

Qué ha pasado con PHP el 21 de octubre

El 21 de octubre de 2026, INCIBE-CERT publicó con importancia crítica (5 sobre 5) un aviso sobre dos vulnerabilidades en el núcleo de PHP: CVE-2026-109618 y CVE-2026-109619, con una puntuación CVSS v4.0 de 9,2. Un atacante remoto, sin usuario ni contraseña, puede ejecutar código con los privilegios del proceso que sirve la web. El fallo está en PHP, al atender la petición, antes de que tu WordPress o tu Joomla ejecuten su propio código. Un plugin de seguridad no sustituye al parche.

No es un riesgo teórico. Xataka recoge que Cloudflare ya ha visto tráfico de ataque contra clientes expuestos, y que los atacantes van cambiando sus peticiones para esquivar las defensas. El centro de ciberseguridad británico (NCSC) contempla expresamente dejar fuera de línea lo que no se pueda parchear, y organismos de Países Bajos, Finlandia, Dinamarca y Francia ya lo han hecho: el portal del Gobierno neerlandés, la autoridad francesa de protección de datos (CNIL) y hasta la web del CCN-CERT español mostraban avisos de mantenimiento. Apagar un servicio no demuestra que ya estuviera comprometido: es la medida mientras no hay parche.

La cifra conviene leerla con calma. El Mundo habla de un riesgo para hasta el 70 % de las páginas. La referencia que cita Xataka, de W3Techs, es esta: PHP está en el 69,3 % de las webs cuyo lenguaje de servidor se puede identificar, y WordPress —que depende de PHP— en el 39,6 % de todas las webs. En la prensa anglosajona el problema circula como PHP2Shell. El Mundo, con información del Wall Street Journal, recoge que el equipo de seguridad de PHP lo compara con Heartbleed y lo sitúa como el asunto más grave del lenguaje en más de una década. El hallazgo se hizo con ayuda de herramientas de IA y el parche se adelantó tras una filtración. Eso explica la prisa. No cambia lo que tienes que pedir hoy a tu hosting.

¿Está tu web afectada?

Si tu web tiene un panel de administración donde entras con usuario y contraseña para cambiar textos, casi seguro funciona con PHP. Es el caso de WordPress, Joomla, Drupal, PrestaShop, WooCommerce, Moodle y la mayoría de webs hechas con plantillas como YOOtheme, Divi o Elementor. Todas entran en el aviso mientras el servidor no tenga la versión corregida.

No entran las páginas servidas como archivos estáticos (HTML, CSS y JavaScript sin un programa detrás), ni las webs de plataformas que no usan PHP. Si no sabes qué tienes, pasa la URL por Analiza tu web: te dice qué CMS y tecnologías se ven desde fuera. No detecta este CVE ni la versión menor de PHP; eso se lo preguntas al hosting.

Qué versión de PHP cierra el aviso

INCIBE recomienda actualizar de inmediato a la versión corregida de tu rama:

• PHP 8.5 → 8.5.12
• PHP 8.4 → 8.4.27
• PHP 8.3 → 8.3.36
• PHP 8.2 → 8.2.35

PHP 8.1, 8.0 y 7.4 ya no tienen una rama mantenida al uso, pero el proyecto ha publicado parches de código fuente. Si tu proveedor no los empaqueta, la vía práctica es que los incorpore o pasar a una rama mantenida ya corregida.

Ojo con el panel del hosting: elegir «PHP 8.3» no significa que el servidor esté en 8.3.36. INCIBE avisa, además, de que algunos repositorios de terceros no publican la corrección el mismo día. Y como recuerda Xataka, PHP vive en el servidor: su actualización suele depender del proveedor de alojamiento, no de quien tiene la web. La pregunta al hosting es la versión exacta, o la confirmación por escrito de que el paquete incluye este arreglo.

Si no puedes actualizar un sistema expuesto a Internet, INCIBE pide aislarlo hasta aplicar la versión corregida. En su aviso hay medidas temporales de configuración: no sustituyen al parche y conviene aplicarlas solo siguiendo ese texto, no un resumen de memoria.

YOOtheme Pro 5: otro parche crítico el mismo día

No forma parte del aviso de INCIBE. El changelog de YOOtheme publicó el 21 de octubre la versión Pro 5.0.53 por un fallo distinto, CVE-2026-102785: ejecución de código sin login a través del manejador de imágenes. Si usas YOOtheme Pro 5 y no estás en 5.0.53 o posterior, toca actualizar también. YOOtheme indica que Pro 4 y anteriores no están afectados por ese aviso. Vale para su plantilla de Joomla y para la de WordPress.

Actualizar Joomla, WordPress o YOOtheme no corrige PHP. Actualizar PHP no corrige YOOtheme. Son dos comprobaciones.

Checklist: qué hacer esta tarde

1. Copia de seguridad de archivos y base de datos antes de tocar nada. Si la web ya muestra archivos raros o usuarios que no reconoces, conserva esa copia como evidencia y no la uses para «volver a poner el hackeo».
2. Anota la versión exacta de PHP. En Joomla está en Sistema → Información del sistema. En WordPress, en Herramientas → Salud del sitio → Información → Servidor, o pídesela al hosting.
3. Pide o aplica la versión corregida de la lista de arriba. Después, comprueba que el número es el parcheado, no solo la rama.
4. Si hay YOOtheme Pro 5, súbelo a 5.0.53 o posterior y míralo en el personalizador, no solo en la lista de extensiones.
5. Si el hosting no puede parchear hoy, apaga la web hasta que pueda. Es lo que están haciendo administraciones con equipos propios. Una pyme no gana nada quedándose expuesta «hasta el lunes».
6. Revisa si alguien entró antes: archivos PHP que no reconoces, administradores nuevos, ficheros modificados y peticiones raras en el registro del servidor. El parche no borra una puerta que ya hayan dejado puesta.
7. Prueba lo básico: portada, formulario, páginas que usan imágenes de YOOtheme y el acceso al panel.

El parche cierra este aviso. No el siguiente.

Este no es el primer parche de seguridad de PHP del año. Es el quinto: hubo tandas en mayo, a principios y a finales de julio, en septiembre y ahora en octubre. Cada una pide lo mismo: confirmar con el hosting, revisar plantilla y plugins, probar la web. Con un CMS, esa rutina no se acaba.

En una web que se edita de verdad —tienda, reservas, área privada, noticias cada semana, varias personas con permisos— compensa: el plan es parchear y seguir cuidando el CMS. Inventar una mudanza de urgencia esta noche no quita el agujero de esta tarde.

En una web informativa que casi no cambia, la cuenta sale al revés: parcheas más veces de las que publicas. Si el panel ya no es una herramienta de trabajo, el siguiente paso es quitarlo. Las páginas públicas pasan a servirse como archivos estáticos. Este fallo de PHP, y el del manejador de imágenes de YOOtheme, dejan de existir en esas páginas porque deja de haber un PHP atendiéndolas.

Eso no vuelve la web intocable. Siguen el acceso al hosting, el DNS, un formulario que aún envíe a un programa en PHP y los scripts de terceros que incrustes. Pero hay muchas menos piezas que parchear un martes por la noche. En casos sencillos, pasar una web informativa a estática cuesta desde 300 € + IVA; el presupuesto se cierra al ver la URL. No incluye por defecto dominio, hosting ni correo.

Cuándo sí y cuándo no merece la pena está explicado en cuándo pasar tu web a estática y dejar WordPress o Joomla.

Siguiente paso

Hoy, lo primero es el parche. Después, si tu web es informativa y el CMS solo acumula actualizaciones, mándanos la URL: en menos de 24 h te decimos si puede funcionar sin PHP en las páginas y cuánto costaría. Si hace falta seguir en Joomla o en WordPress, también te lo diremos. Sin compromiso.

Envíanos tu URL por WhatsApp

Preguntas frecuentes sobre el fallo crítico de PHP