Alerta de vulnerabilidades PHP: dos fallos críticos y qué hacer hoy

Hoy, 21 de octubre de 2026, el equipo de PHP ha publicado una actualización de seguridad fuera de calendario para corregir dos vulnerabilidades PHP críticas. Ambas están puntuadas con un 9,2 sobre 10, y ambas permiten lo peor que puede permitir un fallo: que alguien ejecute código en tu servidor sin necesidad de usuario ni contraseña.

Se las conoce ya como PHP2Shell, y se registran como CVE-2026-109618 y CVE-2026-109619. Si tienes una web, esto te afecta con bastante probabilidad, aunque no sepas que usas PHP.

Qué son estas vulnerabilidades PHP

PHP es el lenguaje sobre el que funciona buena parte de internet: WordPress, PrestaShop, Magento, Joomla, Drupal, Moodle y la mayoría de aplicaciones a medida que se hicieron en los últimos veinte años. No es una pieza más del montaje; es el motor que interpreta cada petición que llega a la web.

Las dos vulnerabilidades PHP corregidas hoy están en ese motor, y el código defectuoso lleva ahí desde PHP 5.4, publicado en 2012. Es decir: no es un problema de versiones antiguas que se arrastran, es un problema de prácticamente todas las versiones que existen.

Qué permite cada uno

CVE-2026-109618 está en el componente que informa del progreso de las subidas de archivos. Además de permitir ejecutar código, deja escapar trozos de memoria del servidor, al estilo de aquel Heartbleed de 2014: fragmentos de otras peticiones que pueden contener contraseñas o claves de API de otros usuarios.

CVE-2026-109619 está en la generación del informe de error cuando algo falla de forma grave, combinado con el acelerador que casi todos los servidores llevan activado. Permite ejecutar código, sin la fuga de memoria del anterior.

En los dos casos el atacante no necesita estar registrado, ni tener un usuario, ni conocer nada de tu web. Le basta con que tu servidor responda.

Las vulnerabilidades PHP ya se están explotando

Esto no es una advertencia preventiva. Cloudflare detectó los primeros ataques aprovechando estas vulnerabilidades PHP a las 07:43 UTC, más de seis horas antes de que existiera el parche, y activó reglas de protección para todos sus clientes, incluido el plan gratuito.

Y a partir de ahora va a ir a más, no a menos: con la corrección publicada, cualquiera puede comparar el código antes y después y deducir cómo se aprovecha el fallo. El periodo entre que sale un parche y empieza el ataque masivo se mide hoy en horas.

Qué hacer hoy, por orden

Protegerse de estas vulnerabilidades PHP es, en la mayoría de los casos, cuestión de diez minutos. Estos son los pasos:

• Averigua qué versión de PHP tienes. En WordPress: Herramientas, Salud del sitio, Información, Servidor. En el hosting suele llamarse «Selector de PHP».
• Actualiza a la versión corregida de tu rama: 8.5.12, 8.4.27, 8.3.36 o 8.2.35.
• Si usas PHP 8.1 o anterior, el problema es mayor. Esas versiones ya no reciben soporte oficial y no hay parche para ellas: lo que toca es subir de versión, no parchear.
• Si no puedes actualizar hoy, pon un cortafuegos delante. Las reglas de Cloudflare cubren los vectores conocidos y están hasta en el plan gratuito.
• Comprueba que no te hayan entrado ya. Archivos nuevos con fecha de hoy, usuarios administradores que no reconoces, tareas programadas raras.

Por qué conviene no dejarlo para la semana que viene

Con las obligaciones normativas uno puede permitirse ir ajustado y cumplir el último día. Con una vulnerabilidad de este tipo no existe esa opción, porque el plazo no lo pone un boletín oficial: lo ponen los programas que ya están recorriendo internet buscando servidores sin actualizar.

La diferencia entre actualizar hoy y actualizar el lunes es la diferencia entre una tarea de diez minutos y una limpieza de malware con la web fuera de servicio, el correo en listas negras y Google marcando el sitio como peligroso. Lo hemos visto suficientes veces como para insistir en ello.

Qué hacemos en Grupo ZAS

Las vulnerabilidades PHP de hoy son justo el tipo de aviso que distingue a quien vigila de quien no. La seguridad de lo que mantenemos nos ocupa a diario, y un aviso así es exactamente el momento en el que eso se nota o no se nota. Hoy, el mismo día del anuncio, hemos revisado todos los sistemas que gestionamos y aplicado en cada uno lo que correspondía.

Nuestras webs públicas no usan PHP en ningún punto —están construidas sobre otra tecnología—, así que no se ven afectadas por estos fallos. En el resto de plataformas que mantenemos hemos actuado en cuanto se publicó el aviso, antes de que nadie tuviera que preguntarnos por ello.

Si tienes una web con nosotros, no tienes que hacer nada. Si tu web la lleva otra persona, el favor que puedes hacerte hoy es escribirle y preguntarle por estas dos referencias: CVE-2026-109618 y CVE-2026-109619. Una respuesta rápida y concreta dice mucho. Y si no la hay, podemos revisarlo nosotros.

Preguntas frecuentes

¿Me afectan estas vulnerabilidades PHP si mi web es WordPress?

Sí. Las vulnerabilidades PHP afectan a WordPress porque está escrito en ese lenguaje, igual que PrestaShop, Magento, Joomla, Drupal o Moodle. El fallo no está en el gestor de contenidos sino en el propio PHP, el motor sobre el que todos funcionan, así que afecta por igual a una web hecha a medida y a una instalación estándar. Lo que hay que actualizar es la versión de PHP del servidor, no los plugins.

¿Cómo sé qué versión de PHP tengo?

En el panel de tu alojamiento suele aparecer en un apartado llamado «Selector de PHP» o «Versión de PHP». En WordPress lo tienes en Herramientas, Salud del sitio, pestaña Información, apartado Servidor. Si no lo encuentras, pregunta a quien te lleva el hosting: es la pregunta correcta que hacer hoy.

Mi web es muy pequeña, ¿de verdad van a atacarla?

Sí, y precisamente por ser pequeña. Estos ataques no eligen víctima: son programas que recorren internet entera probando el fallo en todo lo que responde. No hay una persona decidiendo que tu web merece la pena. Las webs pequeñas caen primero porque suelen tardar más en actualizarse.

¿Qué pasa si no puedo actualizar ahora mismo?

Pon un cortafuegos de aplicación delante mientras tanto. Cloudflare activó reglas para estos fallos el mismo día y están disponibles incluso en su plan gratuito. Es un parche puente, no una solución: el objetivo sigue siendo llegar a la versión corregida cuanto antes. El centro de ciberseguridad británico llegó a recomendar apagar los sistemas que no se pudieran arreglar rápido.

¿Cómo sé si ya me han entrado?

Señales típicas: archivos PHP nuevos o modificados con fecha reciente en carpetas donde no debería haberlos, tareas programadas que no reconoces, usuarios administradores nuevos, picos de tráfico saliente o avisos de tu proveedor. Si encuentras algo, actualizar no basta: hay que limpiar, porque el acceso ya se consiguió.