¿No sabes de informática? Hemos preparado una versión en lenguaje sencillo, con mensajes listos para copiar: el fallo de seguridad de PHP explicado fácil.
Qué ha pasado
El proyecto PHP, el lenguaje en el que funcionan WordPress, PrestaShop, Laravel y buena parte de la web, publicó el 21 de octubre de 2026 una actualización de emergencia que corrige dos vulnerabilidades críticas del propio intérprete. Se las conoce conjuntamente como PHP2Shell.
- 20 de octubre: los detalles de los fallos se filtran en redes sociales antes de la fecha de divulgación prevista, que era el 22. Ese mismo día el equipo de PHP anuncia una versión de seguridad urgente para el día siguiente y la firma de seguridad watchTowr confirma que las vulnerabilidades son reales.
- 21 de octubre: PHP publica las versiones corregidas. El INCIBE-CERT y el CCN-CERT emiten sus alertas, y watchTowr observa los primeros ataques reales en su red de señuelos.
- 22 de octubre: los proveedores de hosting siguen desplegando el parche. Según watchTowr, la agencia estadounidense CISA aún no había incluido los fallos en su catálogo de vulnerabilidades explotadas conocidas.
Los fallos los descubrieron investigadores de Calif y los comunicaron a PHP de forma coordinada, pero la filtración adelantó el calendario. Según recoge Codeable, el consejero delegado de Cloudflare habló de miles de intentos de explotación antes del anuncio y de millones al día siguiente. Es un dato de una fuente secundaria, pero encaja con el aviso del CERT-EU, que señala que las pruebas de concepto ya circulan y que es probable que los atacantes ya estén explotando los fallos.
Las dos vulnerabilidades, sin jerga
| Vulnerabilidad | Qué ocurre | Gravedad |
|---|---|---|
| CVE-2026-109618 | Si PHP se queda sin memoria mientras prepara una petición, deja datos internos a medio construir y el código de limpieza los da por buenos. Permite ejecutar código de forma remota. | 9,2 sobre 10 (CVSS v4.0) |
| CVE-2026-109619 | Un estado interno sobrevive a la memoria de la petición, y la siguiente petición que atiende el mismo proceso de PHP puede actuar sobre esos datos sobrantes. Permite ejecutar código de forma remota. | 9,2 sobre 10 (CVSS v4.0) |
Las dos permiten que alguien sin credenciales ejecute su propio código en el servidor y, potencialmente, lo controle. De ahí el apodo: PHP2Shell, por la "shell", la consola con la que se dan órdenes a una máquina.
Según recoge Rescana, PHP indica que la ejecución remota completa de CVE-2026-109618 se validó por HTTP contra Apache con mod_php, y que el análisis del código apunta a que PHP-FPM también es susceptible, aunque no se ha demostrado todavía un exploit completo para FPM.
A quién afecta
- A cualquier PHP que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, LiteSpeed o FrankenPHP.
- El riesgo es mayor con Apache y mod_php, donde el ataque puede tener éxito antes de que se ejecute el código de tu aplicación.
- El fallo está en PHP, no en tu aplicación. Según Codeable, WordPress.org ha confirmado que no hay ni habrá una actualización de WordPress para esto. Lo mismo vale para PrestaShop, Laravel y cualquier otra aplicación hecha en PHP: se arregla actualizando PHP.
| Rama de PHP | Versión corregida | Situación |
|---|---|---|
| PHP 8.5 | 8.5.12 | Soportada |
| PHP 8.4 | 8.4.27 | Soportada |
| PHP 8.3 | 8.3.36 | Soportada |
| PHP 8.2 | 8.2.35 | Solo correcciones de seguridad hasta el 31 de diciembre de 2026 |
| PHP 8.1, 8.0 y 7.4 | Sin versión oficial | Paquetes de tu distribución o de un proveedor de soporte largo, o los parches mínimos que PHP publicó para quien compila desde el código fuente |
| PHP 7.3 y anteriores, incluido PHP 5 | Sin corrección | Afectadas. Hay que migrar |
El número de versión puede no cambiar. Muchos servidores instalan PHP desde su distribución de Linux, que suele aplicar la corrección sin cambiar el número que ves. Una versión que parece antigua, como la 8.5.11, no significa necesariamente que no esté parcheada, y al revés. Ante la duda, pregunta a tu proveedor por escrito.
Qué recomiendan las autoridades españolas
- CCN-CERT (alerta AL 11/26, del 21 de octubre, nivel de peligrosidad crítico): actualizar de inmediato todas las aplicaciones basadas en PHP y, mientras no sea posible, apagar o aislar los servicios expuestos a Internet cuyo uso no sea indispensable.
- INCIBE-CERT (aviso INCIBE-2026-762, importancia 5, crítica): aplicar la versión corregida de la rama y, si un sistema expuesto no se puede actualizar, aislarlo de las redes públicas hasta hacerlo.
Ambos coinciden con el resto de fuentes: la solución completa es actualizar.
¿Te toca actuar a ti? Depende de tu hosting
| Tu caso | Qué hacer |
|---|---|
| Hosting gestionado de WordPress | No hay nada que instalar. Confirma en el aviso o en la página de estado de tu proveedor que lo ha aplicado. |
| Hosting compartido (cPanel, IONOS, Hostinger, GoDaddy y similares) | Tu proveedor aplica el parche. Comprueba que lo ha hecho y, si usas PHP 8.1 o anterior, cambia a 8.2 o superior desde tu panel, mejor 8.3 o superior. |
| VPS o servidor propio | Te toca a ti, hoy. Actualiza PHP y reinícialo. |
| Servidor con PHP 8.1 o anterior que no puedes migrar hoy | Usa el paquete de tu distribución o de un proveedor de soporte largo, o aísla el sistema de Internet. |
Esto es lo que han comunicado algunos proveedores a 22 de octubre de 2026:
| Proveedor | Estado |
|---|---|
| IONOS | Ha aplicado la actualización oficial en todas las plataformas que gestiona. Quien tenga un VPS o un servidor dedicado debe actualizar por su cuenta. |
| Hostinger | Según informa la prensa a partir de su comunicado, el parche se aplica de forma automática en sus servicios. |
| GoDaddy | Parcheados todos los PHP en WordPress gestionado (21 de octubre), Windows Hosting (22 de octubre) y Web Hosting (22 de octubre, 13:30 UTC). Avisa de que el número de versión puede no cambiar. |
| OVHcloud | Según Codeable, ha parcheado PHP 7.4 a 8.5 en todos sus clústeres de hosting web y trabaja en las versiones anteriores. |
| Cloudflare | Ha activado reglas de su cortafuegos web contra estos ataques en todos los planes con WAF, incluido el gratuito. Es una capa de protección y no sustituye a actualizar PHP. |
Paso a paso para actualizar
Sigue los pasos en orden. Si tu web está en un hosting gestionado, te bastan los pasos 1 y 5.
Paso 1. Averigua qué versión de PHP usa tu web
- En WordPress: Herramientas, Salud del sitio, pestaña Información, sección Servidor.
- En tu panel de hosting: busca la sección de versión de PHP. En cPanel se llama MultiPHP Manager.
- En un servidor propio:
php -vmuestra la versión de la línea de comandos, que puede ser distinta de la que sirve tu web. Comprueba la del servicio PHP-FPM, por ejemplo conphp-fpm8.3 -ven Debian o Ubuntu, o la del módulo de Apache.
Apunta el número, recordando que en muchos servidores el parche no lo cambia.
Paso 2. Haz una copia de seguridad
Guarda una copia de los archivos y de la base de datos antes de tocar nada. Si algo falla después, podrás volver atrás. En hosting, casi todos los paneles tienen una herramienta de copias; en un servidor propio, haz una copia de la carpeta de la web y un volcado de la base de datos.
Paso 3. Actualiza PHP según tu caso
Hosting compartido o gestionado. No instales nada: pregunta a tu proveedor. Puedes enviarle este mensaje:
Hola, ¿habéis aplicado en mi plan la actualización de seguridad de PHP
del 21 de octubre de 2026 (CVE-2026-109618 y CVE-2026-109619)?
¿Qué versión de PHP usa mi web y está ya corregida?Si estás en PHP 8.1 o anterior, cambia a 8.2 o superior desde el panel. Antes, prueba la web en una copia de pruebas: algunos plugins y temas antiguos pueden fallar con una versión más moderna.
VPS con Debian o Ubuntu.
sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php8.3*'Sustituye 8.3 por tu rama (8.2, 8.4 u 8.5). Si tu servidor instala PHP desde un repositorio de terceros, comprueba que ya ofrece la versión corregida; si no, usa el paquete de tu distribución o espera a que se publique.
VPS con AlmaLinux, Rocky o RHEL.
sudo dnf upgrade --refresh 'php*'Los nombres de los paquetes y del servicio dependen del repositorio que uses.
Docker. Reconstruye la imagen con docker build --pull, partiendo de una imagen base de tu rama con la versión corregida (8.5.12, 8.4.27, 8.3.36, 8.2.35 o posterior), y vuelve a desplegarla. Si la imagen de tu rama aún no está publicada, espera a que lo esté o protege el servicio con las medidas provisionales de más abajo.
Paso 4. Reinicia PHP
Este paso es imprescindible. Actualizar los paquetes no basta: los procesos que ya estaban en marcha siguen usando en memoria la versión antigua hasta que se reinician.
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2La segunda línea solo si usas Apache con mod_php. Con Nginx, basta reiniciar PHP-FPM. En RHEL y derivadas, el servicio suele llamarse php-fpm, aunque depende del repositorio.
Paso 5. Comprueba que se ha aplicado
- Consulta de nuevo la versión, como en el paso 1.
- Si el número no ha cambiado, revisa el historial del paquete. En Debian y Ubuntu,
apt changelog php8.3-fpmsuele mencionar los CVE corregidos. Si no puedes comprobarlo, pide a tu proveedor una confirmación por escrito. - Navega por tu web y prueba lo esencial: acceso de usuarios, formularios, carrito y pagos, y subida de archivos.
Paso 6. Si usas PHP 8.1 o anterior
- Lo recomendable es migrar a PHP 8.3 o superior, tras probar la web en una copia de pruebas. Con PHP 8.2 ganas tiempo, pero solo recibe correcciones de seguridad hasta el 31 de diciembre de 2026.
- Mientras tanto, usa el paquete de tu distribución o de un proveedor de soporte largo. PHP publicó parches mínimos para 7.4, 8.0 y 8.1, pensados para quien compila PHP desde el código fuente.
- PHP 7.3 y anteriores no tienen corrección: hay que migrar.
- Si no puedes actualizar ni migrar hoy, aísla el sistema, como recomiendan el CCN-CERT y el INCIBE-CERT. Según Codeable, WordPress.org y el NCSC británico sugieren incluso desconectar el sitio hasta poder actualizar si gestionas tu propio servidor.
Paso 7. Revisa si ha habido intrusión
Los ataques empezaron el 21 de octubre y las pruebas de concepto circulaban antes de la publicación del parche. Si tu servidor estaba expuesto, conviene comprobar que no hay señales de intrusión:
- Usuarios: revisa que no haya administradores nuevos o desconocidos.
- Archivos: busca archivos PHP desconocidos en
wp-content/uploads, donde normalmente no debería haber ninguno, y archivos modificados recientemente. - Integridad de WordPress: si usas WP-CLI, ejecuta
wp core verify-checksumsywp plugin verify-checksums --allpara comparar los archivos con los originales. - Registros de acceso: busca peticiones inusuales o picos extraños desde el 20 de octubre.
Si encuentras algo sospechoso, restaura una copia limpia anterior, cambia todas las contraseñas (WordPress, base de datos, FTP o SSH y panel de hosting), regenera las claves de seguridad de wp-config.php y pide ayuda profesional.
Si no puedes actualizar hoy: medidas provisionales
PHP deja claro que ninguna configuración mitiga por completo estos fallos. Estas medidas cierran caminos concretos, pero no sustituyen a actualizar.
- CVE-2026-109619: fija
session.upload_progress.enabled = 0en elphp.inio en el pool de PHP-FPM y reinicia PHP. Según Codeable, WordPress no usa esa función, así que no debería afectar a una web típica. - CVE-2026-109618: el INCIBE cita
memory_limit = -1, aplicado a nivel de administración para que ninguna aplicación pueda sobrescribirlo, como mitigación principal. Un límite finito como 128M no desactiva la vulnerabilidad. Un límite ilimitado puede agotar los recursos del servidor si un script se descontrola, así que conviene que el servidor aplique su propio límite por otra vía y vigilar el consumo. - Tras cambiar la configuración, reinicia PHP y comprueba que ninguna configuración de aplicación, directorio o pool vuelve a fijar un límite de memoria finito.
- Mantén activo el cortafuegos web de tu proveedor o de Cloudflare como capa adicional y limita el acceso público a lo que no sea imprescindible.
Cuidado con las estafas que aprovechan la alerta
Cada gran alerta trae correos y mensajes falsos que se hacen pasar por tu hosting o por un supuesto "soporte de seguridad" y te piden entrar con tus credenciales o instalar un parche. IONOS ha avisado a sus clientes de que no pulsen los enlaces de correos sobre esta vulnerabilidad ni introduzcan sus datos de acceso. El parche de PHP se aplica en el servidor, no se descarga desde un correo. Entra siempre a tu panel escribiendo tú la dirección, y revisa las señales de alarma que se explican en la guía de cómo detectar estafas, que valen también fuera del mundo cripto.
Por qué importa si tu web guarda datos de clientes o mueve dinero
Un servidor controlado por un atacante puede dar acceso, potencialmente, a bases de datos, formularios, cuentas de usuarios y credenciales guardadas en la propia web. Si tu sitio gestiona pagos o servicios con criptomonedas, trata esta actualización como prioritaria. Los incidentes recientes del sector, como el de Coldcard o el de Ledger, apuntan en la misma dirección: actualizar con rapidez, confiar solo en canales oficiales y verificar las comunicaciones antes de actuar.
Preguntas frecuentes
¿Qué es PHP2Shell?
Es el nombre con el que se conoce a dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código en un servidor sin iniciar sesión. PHP las corrigió el 21 de octubre de 2026.
¿Tengo que actualizar WordPress?
No por este motivo. El fallo está en PHP y la corrección es actualizar PHP, no WordPress ni tus plugins. Mantener WordPress y los plugins al día sigue siendo recomendable por otras razones de seguridad.
¿Cómo sé si mi hosting ya lo ha corregido?
Revisa el aviso o la página de estado de tu proveedor y, si tienes dudas, pregúntaselo por escrito. El número de versión que ves puede no cambiar, así que no es una prueba definitiva.
¿Me han hackeado por no haber actualizado antes?
No necesariamente. Se han observado ataques desde el 21 de octubre, pero que tu web estuviera expuesta no significa que haya sido atacada. Aun así, conviene seguir el paso 7 para comprobarlo.
¿Qué hago si mi servidor usa PHP 7 u 8.0?
No hay versión oficial corregida. Usa el paquete de tu distribución o de un proveedor de soporte largo, o migra a PHP 8.2 o superior. Si no puedes hacerlo hoy, aísla el sistema de Internet.
Conclusión
PHP2Shell es una de las alertas más serias del año para cualquier web en PHP: dos fallos críticos, ataques reales desde el primer día y un parche disponible. La acción es sencilla de decir y exige disciplina: confirmar que tu proveedor ha actualizado, o hacerlo tú si gestionas el servidor, reiniciar PHP, comprobar el resultado y revisar que nadie se te haya adelantado.
Fuentes: aviso de PHP (php.net) y sus advisories en GitHub, watchTowr, CERT-EU (aviso 2026-018), CCN-CERT (alerta AL 11/26), INCIBE-CERT (aviso INCIBE-2026-762), Codeable, GoDaddy, IONOS, Rescana y la prensa especializada. Información actualizada a 22 de octubre de 2026. Este artículo es informativo y no sustituye a un profesional; si gestionas un servidor con datos de clientes, consulta a un especialista.