Dos fallos de 9,2 sobre 10. Un intérprete. Casi toda la web.
Si eres cliente de aratech o tu web está alojada con nosotros, escribe ahora mismo a [email protected]. Confirmaremos tu versión de PHP, el estado de tu parche y lo que estamos haciendo al respecto. No esperes a que un boletín te lo explique.
Esto no es un problema de un plugin. No es un problema de una plantilla. No es un fallo de WordPress, de Magento ni de Laravel.
Es PHP. El propio intérprete.
Dos vulnerabilidades críticas en el núcleo de PHP, registradas como CVE-2026-109618 y CVE-2026-109619, permiten que un atacante sin autenticación ejecute código arbitrario en un servidor web. El equipo de seguridad de PHP califica ambas con 9,2 sobre 10 en CVSS v4.0. El conjunto de parches de emergencia salió hoy, 21 de octubre de 2026, a las 14:00 UTC (18:00 en Dubái). Las ramas corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
El detalle que debería preocuparte: estos fallos se filtraron públicamente el 20 de octubre, aproximadamente un día antes de la divulgación coordinada. La filtración incluía los identificadores CVE, una puntuación de gravedad y una fecha, y junto a ella circuló una captura de una herramienta de explotación llamada PHP2Shell, atribuida a Calif.IO, con un cartel que afirma que funciona contra toda versión de PHP desde la 5.4.0. Los detalles técnicos siguieron bajo embargo hasta las 14:00 UTC de hoy. Es decir: todo internet recibe el parche y el material para la ingeniería inversa en el mismo momento.
Qué son realmente las dos vulnerabilidades
Ambas son fallos de seguridad de memoria en el ciclo de vida de la petición. Ninguna requiere un inicio de sesión, un plugin o una página mal programada.
CVE-2026-109618, ejecución remota por corrupción en el manejo de memoria agotada. Cuando PHP alcanza una condición de memoria agotada, el proceso puede interrumpirse mientras los datos internos de la petición están solo parcialmente inicializados. La limpieza posterior trata esos datos inválidos como válidos, y un atacante capaz de provocar el fallo de asignación consigue determinar qué ocurre después.
CVE-2026-109619, ejecución remota por estado global obsoleto. El estado interno asociado a una petición puede sobrevivir después de que se libere la memoria que lo sustentaba. Una petición posterior atendida por el mismo worker puede consumir ese estado obsoleto antes de que la inicialización normal lo restablezca. La reutilización de workers se convierte aquí en superficie de ataque.
El aviso de PHP indica que el riesgo es máximo con mod_php, donde un exploit demostrado permite que una petición sin autenticación desencadene el ataque antes de que se ejecute cualquier código de la aplicación. Eso importa más que cualquier otra frase de este artículo: tu framework, tus reglas de firewall y tu lógica de negocio no están en la ruta de ataque.
Quién está expuesto
Cualquiera que sirva PHP mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed está dentro del alcance. Es decir, la configuración por defecto de una parte enorme de internet.
PHP mueve alrededor de siete de cada diez webs que declaran un lenguaje del lado del servidor. WordPress, Drupal, Joomla, Magento, Laravel, Symfony, aplicaciones a medida y una larga cola de dispositivos y herramientas que empaquetan PHP por dentro. Hay informes de que el rango afectado se remonta a la era de PHP 5, en 2004. El alcance exacto por versión se irá confirmando a medida que los proveedores publiquen sus propios avisos. Mallory contó el 20 de octubre unos 884.000 hosts expuestos a internet que aún declaraban PHP 8.1 o anterior ante Shodan: el 59 % de todos los hosts que declaraban alguna versión.
Y aquí está la parte que casi todo el mundo pasa por alto: PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. El equipo publicó parches mínimos sobre el código fuente para 7.4, 8.0 y 8.1, pero si estás en una rama sin soporte y no controlas tu compilación, no estás parcheado. Estás esperando el calendario de otra persona.
Por qué las próximas 48 horas importan más que el fallo
Una vulnerabilidad conocida pero no pública es una carrera entre investigadores y defensores. Una vulnerabilidad cuyo parche es público es una carrera entre atacantes y todos los demás.
En cuanto las versiones corregidas se puedan descargar, cualquiera puede compararlas con el código vulnerable e invertir la ingeniería del disparador. No es una preocupación teórica: es el guion habitual, y suele medirse en horas, no en semanas. Sansec espera ataques masivos unos quince minutos después de la publicación. Patchstack ya informa de explotación activa contra socios de hosting, y Cloudflare ha registrado intentos de ataque tempranos. Esa ventaja ya se está gastando.
La reacción de las instituciones es otra señal. Servicios neerlandeses como DigiD, MijnOverheid, la web de la Cámara de Representantes y Tweakers se pusieron fuera de línea como precaución. Varias plataformas japonesas importantes entraron en mantenimiento de emergencia. The SEO Framework apagó sus servidores. CERT-EU publicó el aviso 2026-018 y el NCSC británico pidió parchear de inmediato o desconectar los sistemas cuando la remediación no sea viable.
Cuando los gobiernos eligen la caída del servicio antes que la exposición, esa es la valoración honesta de la gravedad.
Haz esto ahora, en este orden
- Inventaría antes de parchear. Todas las instalaciones de PHP que ejecutas: producción, staging, contenedores, servidores que solo corren cron y dispositivos o herramientas de terceros que incluyan PHP. No puedes parchear lo que has olvidado.
- Actualiza a una versión corregida. 8.5.12, 8.4.27, 8.3.36 o 8.2.35. En alojamiento gestionado, pide a tu proveedor la ventana exacta por escrito y confirma después la versión real. No des por hecho que un aviso de mantenimiento significa que tus webs están listas.
- Si estás en PHP 8.1 o anterior, decide hoy. O compilas con los parches del equipo de seguridad de PHP, o actualizas a una rama con soporte. No hay una tercera opción que consista en estar a salvo.
- Reinicia todos los workers. PHP-FPM, Apache, LiteSpeed, FrankenPHP y cualquier worker de CLI de larga duración. Un parche instalado pero no recargado es un parche que no está en ejecución.
- Aplica el endurecimiento intermedio aunque ya hayas parcheado. Cuesta poco en
php.inio en la configuración del pool y no tiene coste mantenerlo:session.upload_progress.enabled = 0, a nivel de pool o de servidor, nunca conini_set()ni.user.inimemory_limit = -1, forzado donde la aplicación no pueda sobrescribirlopost_max_size = 8Msi no aceptas subidas,32Msi las necesitas, conupload_max_filesizepor debajo- en PHP 8.5,
fatal_error_backtraces = 0
- Busca, no solo parchees. Si tu web ha estado accesible y sin parchear, revisa archivos inesperados, PHP modificado en directorios de subida, usuarios administradores nuevos, conexiones salientes que no configuraste y tareas cron que no creaste. Un parche cierra la puerta; no saca de casa a quien ya entró.
- Ignora los plugins milagro. Circulan fragmentos copiados y plugins "solución PHP2Shell" sin verificar. No están respaldados, no funcionan, y algunos son el propio ataque.
La lección incómoda
Cada pocos años la web recuerda que el runtime que sostiene todo es un programa con sus propios fallos. La factura suele ser cara.
El patrón que vemos en aratech una y otra vez: la aplicación se actualizó, los frameworks se mantuvieron al día y la versión de PHP de debajo se quedó quieta durante años porque funcionaba. PHP 7.4 está sin soporte desde noviembre de 2022. Son casi cuatro años sin parches oficiales de seguridad, en una rama que ahora necesita parches del proveedor para sobrevivir a un fallo como este.
El fin de soporte no es una preferencia de mantenimiento. Es un riesgo no gestionado con fecha de vencimiento, y hoy es el día en que venció.
Si estás en una rama antigua, planifica la actualización como un proyecto real: un servidor limpio, una versión actual de PHP y del framework, pruebas completas y una migración con el entorno antiguo como respaldo. Son unos días de trabajo incómodo, repetidos cada pocos años, frente a la alternativa de esperar que el próximo 9,2 no te encuentre.
Si no lo tienes claro, pregúntanos hoy
Si eres cliente de aratech o tu web está alojada con nosotros, escribe ahora mismo a [email protected] y te diremos exactamente en qué situación estás: tu versión de PHP, si está parcheada, si hemos visto algo sospechoso en tu infraestructura y qué hay que hacer a continuación.
Si no eres cliente y no sabes qué versión de PHP ejecuta tu web, esa es tu respuesta. Escríbenos igual. Esta es la semana de averiguarlo.