El 21 de octubre de 2026 el equipo de PHP publicó los parches de dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas en conjunto como PHP2Shell. El atacante no necesita usuario ni contraseña. Una sola petición manipulada a tu web puede bastarle para ejecutar su propio código en el servidor y hacerse con el sitio. A las pocas horas de la publicación, la empresa de seguridad watchTowr informó de intentos de explotación de ambos fallos, y Cloudflare dijo que ya veía los primeros ataques.
Si tu web, tu tienda online o tu panel de administración funciona con PHP, tu servidor necesita la versión actualizada de PHP hoy mismo.
Qué ha pasado
El equipo de PHP anunció una versión crítica el 20 de octubre y publicó las versiones corregidas 8.5.12, 8.4.27, 8.3.36 y 8.2.35 el 21 de octubre a las 14:00 UTC. Les asigna una puntuación de 9,2 sobre 10 en CVSS v4.0, el nivel crítico. Una de las vulnerabilidades tiene que ver con cómo gestiona PHP la falta de memoria. La otra hace que datos de una petición se filtren a la siguiente petición en el mismo proceso del servidor.
Afectan a todas las formas de ejecutar PHP en un servidor web: PHP-FPM, Apache con mod_php, php-cgi, LiteSpeed y FrankenPHP. El equipo de PHP considera Apache con mod_php el caso de mayor riesgo: su aviso de seguridad describe un exploit demostrado en el que una petición sin autenticación lanza el ataque antes de que se ejecute ningún código de la web.
A última hora del 21 de octubre ninguna empresa de seguridad había informado de una intrusión confirmada. Ya circula por internet código que dice explotar estos fallos, y los ataques masivos pueden empezar en cualquier momento.
¿Te afecta?
Revisa estos puntos. Basta con un «sí».
- Tu web funciona con WordPress, WooCommerce, Laravel, OpenCart, Bitrix, Drupal, Magento u otro sistema en PHP.
- Tu empresa tiene un panel de administración, un portal de clientes o una API escritos en PHP. El backend de una app móvil también cuenta.
- Tu proveedor de hosting o tu desarrollador no te ha confirmado que PHP ya está actualizado en tu servidor.
- Tu servidor usa un panel de hosting como aaPanel. Algunos paneles no tenían PHP actualizado el día de la publicación.
- Tu versión de PHP es la 8.1 o anterior.
Si no sabes las respuestas, eso ya es motivo para preguntar hoy.
Qué puede hacer un atacante con tu web
Ejecutar código en el servidor le da al atacante el mismo acceso que tiene tu web. En la práctica, eso significa:
- control total del sitio: cambiar páginas, crear cuentas de administrador, redirigir a tus visitantes;
- acceso a la base de datos: nombres, correos, direcciones y pedidos de tus clientes;
- malware o páginas de spam instaladas en tu web;
- un aviso de Google en los resultados de búsqueda y en el navegador, que corta el tráfico y las ventas hasta que limpies el sitio.
Limpiar una web comprometida puede llevar días y, a veces, obliga a rehacerla entera. Una actualización lleva horas.
Qué hacer hoy
1. Averigua tu versión de PHP. Tu panel de hosting la muestra, normalmente en «Versión de PHP» o «Configuración de PHP». En WordPress, abre Herramientas → Salud del sitio → Información → Servidor. En Ubuntu puede seguir apareciendo un número antiguo, como 8.3.6, después de una actualización de seguridad, porque Ubuntu parchea el paquete y mantiene el número. Tu hosting o tu desarrollador tiene que comprobar la versión del paquete.
2. Pide a tu proveedor de hosting o a tu desarrollador que actualice PHP. Puedes enviar este mensaje tal cual:
Hola. El 21 de octubre de 2026 PHP publicó parches para las vulnerabilidades críticas CVE-2026-109618 y CVE-2026-109619 (PHP2Shell). Os pedimos que confirméis que PHP en nuestro servidor está actualizado a una versión corregida (8.5.12, 8.4.27, 8.3.36, 8.2.35 o un paquete parcheado de la distribución) y que PHP-FPM o Apache se ha reiniciado. Si usamos PHP 8.1 o anterior, indicadnos cómo pensáis aplicar el parche. Os pedimos también que reviséis los logs del servidor en busca de señales de explotación desde el 21 de octubre.
3. Si usas PHP 8.1 o anterior, planifica el paso a una versión con soporte. Para 7.4, 8.0 y 8.1 el equipo de PHP solo ha publicado parches en código fuente. Alguien tiene que compilar PHP desde el código fuente con esos parches o migrar la web a una versión más reciente.
Desactivar session.upload_progress.enabled en la configuración de PHP cierra parte de la vía de ataque. El equipo de PHP aclara que eso no deja el servidor seguro. Tómalo como un parche provisional hasta la actualización.
Tu versión y qué hacer
| Tu versión de PHP | Qué hacer |
|---|---|
| 8.5 | Actualizar a 8.5.12 |
| 8.4 | Actualizar a 8.4.27 |
| 8.3 | Actualizar a 8.3.36 |
| 8.2 | Actualizar a 8.2.35. El soporte de 8.2 termina el 31 de diciembre de 2026, así que planifica la siguiente actualización |
| 8.1, 8.0, 7.4 | Sin actualización oficial. Compilar PHP con los parches del código fuente o pasar a una versión con soporte |
| 7.3 y anteriores | Sin parche del equipo de PHP. Pasar a una versión con soporte |
Ubuntu ya ha publicado paquetes corregidos. En otras distribuciones de Linux, consulta el aviso de seguridad de tu proveedor.
Cómo lo resolvimos para nuestros clientes
El equipo de PHP publicó los parches a las 14:00 UTC. Nuestros ingenieros se pusieron con ello más o menos una hora después. Dos horas más tarde, hacia las 17:00 UTC, teníamos cerrados todos los servidores que mantenemos: 88 proyectos bajo nuestro soporte.
En cada servidor desactivamos primero el mecanismo vulnerable y después instalamos el PHP corregido. Paneles de hosting como aaPanel no tenían PHP actualizado el día de la publicación, así que compilamos PHP desde el código fuente con los parches. Hicimos lo mismo con los proyectos en PHP 7.4, 8.0 y 8.1, que el equipo de PHP ya no actualiza. Tras la actualización revisamos los logs de los servidores en busca de señales de que alguien hubiera aprovechado la vulnerabilidad. No encontramos ninguna.
Nuestra monitorización automática funciona sin pausa, y nuestros ingenieros actúan cuando detecta un incidente.
Cómo lo hicimos, paso a paso: cómo parcheamos 88 proyectos PHP en tres horas.
¿No tienes claro si tu web está protegida?
Revisamos tu versión de PHP y la actualizamos en un día laborable. Si tu web funciona con PHP 8.1 o anterior, te diremos qué camino es más rápido y más barato en tu caso: una versión compilada con los parches o una actualización de versión.
Si después quieres un mantenimiento continuo, mira soporte web y soporte de servidores. Para tiendas WordPress y WooCommerce tenemos una página aparte. Si sospechas que alguien entró antes de la actualización, o quieres saber qué más queda abierto, un test de penetración te da la respuesta.
FAQ
¿Tengo que actualizar si mi web funciona con WordPress?
Sí. WordPress funciona sobre PHP, y la vulnerabilidad está en el propio PHP. Actualizar WordPress y sus plugins no la corrige. Tu servidor necesita la versión corregida de PHP.
¿Mi proveedor de hosting actualizará PHP automáticamente?
Algunos lo hacen, otros esperan, y en muchos VPS y servidores dedicados nadie actualiza PHP si no lo pides. Pide a tu proveedor una confirmación por escrito con la versión exacta.
¿Se romperá mi web después de la actualización?
Una actualización dentro de la misma rama, por ejemplo de 8.3.x a 8.3.36, solo trae correcciones de seguridad y de errores, y rara vez afecta a una web. Pasar de 7.4 u 8.1 a una rama más nueva puede romper plugins o código antiguos, así que ese cambio hay que probarlo antes.
¿Basta con desactivar session.upload_progress?
No. Cierra parte de una vía de ataque. Según el equipo de PHP, solo la actualización resuelve el problema.
Fuentes
- Anuncio del equipo de PHP: https://www.php.net/archive/2026.php
- Avisos de seguridad: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w y https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
- Intentos de ataque y código de explotación: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote