PHP2Shell: qué pasó y cómo protegemos los servidores.
En octubre de 2026 se publicaron dos fallas críticas de PHP que permiten tomar el control de un servidor sin contraseña. Te contamos cómo funcionan, qué hay que hacer y cómo lo manejamos en Brova Cloud.
PHP2Shell es el nombre que recibieron dos vulnerabilidades de PHP: CVE-2026-109618 y CVE-2026-109619. Se publicaron el 21 de octubre de 2026 y las dos tienen un puntaje de gravedad de 9,2 sobre 10.
Permiten ejecutar código en el servidor con una petición armada a medida, sin usuario ni contraseña. Con ese acceso, un atacante puede instalar un web shell, una puerta trasera para controlar el servidor y los datos que guarda.
PHP es el lenguaje de WordPress, Drupal, Joomla y Magento. Según W3Techs, lo usa cerca del 69% de los sitios con un lenguaje de servidor conocido.
Cómo funciona el ataque
Las dos fallas están en cómo PHP maneja la memoria al recibir una petición:
CVE-2026-109618. Si PHP se queda sin memoria mientras prepara una petición, la limpieza puede tratar datos a medio armar como si fueran válidos.
CVE-2026-109619. Datos de una petición quedan en memoria después de liberarse, y la siguiente petición que atiende el mismo proceso puede usarlos.
El riesgo depende de cómo corre PHP en el servidor. Con Apache y mod_php, el ataque puede ocurrir antes de que se ejecute una sola línea del sitio. Con PHP-FPM la exposición es menor, pero depende de la configuración.
Quien visita un sitio vulnerable no corre peligro por navegarlo. El riesgo está en el servidor y en los datos que guarda.
La cronología
17 de octubre. Amazon registra el primer intento de ataque en sus servidores trampa, cuatro días antes del parche.
20 de octubre. Se filtran los números de CVE y PHP adelanta su versión de seguridad un día.
21 de octubre. Salen PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, con las fallas corregidas.
23 de octubre. PHP publica una tercera falla, CVE-2026-115560, en el progreso de subida de archivos de la sesión. Todavía no tiene parche.
Después de la publicación, Amazon, Cloudflare y watchTowr reportaron intentos de ataque a gran escala. Wordfence informó más de 74.000 intentos bloqueados en sitios WordPress.
Qué versiones están afectadas
Versión de PHP
Corregida en
8.5
8.5.12
8.4
8.4.27
8.3
8.3.36
8.2
8.2.35
8.1 y anteriores
Sin versión oficial. Solo parches de algunas distribuciones de Linux.
Las versiones viejas no tienen arreglo. PHP 8.1 y anteriores ya no reciben actualizaciones de seguridad. Si tu sitio corre en una de ellas, la solución completa es pasar a una versión con soporte.
Lo que no alcanza
Actualizar WordPress, los plugins o el tema no corrige PHP2Shell. La falla está en PHP, y se corrige en el servidor. Tampoco alcanzan estas medidas:
Un firewall solo. Un firewall de aplicaciones frena los ataques conocidos, pero si el servidor también responde directo, el atacante lo puede esquivar.
Mirar la versión con php -v. Algunas distribuciones de Linux aplican el parche sin cambiar el número de versión. Hay que revisar el paquete instalado.
Instalar el parche sin reiniciar. Con mod_php hace falta un reinicio completo de Apache. Con PHP-FPM, reiniciar o recargar el servicio.
Ocultar errores o desactivar la subida de archivos. No cambia nada frente a estas fallas.
Cómo lo manejamos en Brova Cloud
Brova Cloud es nuestro servicio de hosting gestionado, exclusivo para los sitios que construimos. Los servidores están en Helsinki, Finlandia, y todo el tráfico pasa por la red de Cloudflare.
Hetzner, el proveedor de nuestra infraestructura, actualizó sus sistemas. Pero Brova Cloud funciona con varios servidores privados, y cada uno se actualiza por separado. Por eso trabajamos servidor por servidor:
Copias de seguridad primero. Antes de tocar nada, hicimos una copia de seguridad de cada servidor.
PHP actualizado en cada servidor. Instalamos las versiones corregidas una por una y reiniciamos los servicios para que el parche quedara activo.
Todas las medidas recomendadas. Aplicamos las medidas de seguridad sugeridas para PHP2Shell, también las que hay que configurar a mano.
Revisión completa. Revisamos servicio por servicio, cuenta por cuenta y sitio por sitio.
No encontramos ninguna vulnerabilidad abierta ni rastros de ataque en los sitios que alojamos.
Estar al tanto también es parte del trabajo. Participamos en comunidades de administradores de sistemas y seguimos las alertas de seguridad todos los días. La seguridad y el cumplimiento de las normas internacionales son una prioridad en cada sitio que alojamos.
Qué revisar si tu sitio está en otro hosting
Preguntale a tu proveedor si ya instaló PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o el parche de tu distribución, y si reinició PHP después.
Si tu sitio corre en PHP 8.1 o anterior, planificá la actualización cuanto antes.
Hasta que salga el parche de CVE-2026-115560, desactivá session.upload_progress.enabled en la configuración de PHP. WordPress no usa esa función.
Revisá si hay archivos PHP nuevos o modificados que no reconocés en la carpeta del sitio.
Si el servidor estuvo expuesto, cambiá las contraseñas y las claves de API que guarda, porque una falla relacionada puede filtrar memoria del servidor.
Si tenés dudas sobre tu servidor, escribinos y lo revisamos con vos.
Joaquín Martinez Herrera 7 min de lectura
