El proyecto PHP publicó este miércoles 21 de octubre de 2026 actualizaciones de emergencia para dos fallas críticas, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código en un servidor web sin usuario ni contraseña. El aviso oficial en php.net es tajante: no hay mitigaciones completas y actualizar es la única opción segura.
La pareja de fallas ya tiene nombre, PHP2Shell, y ya tiene ataques. Patchstack reportó intentos de explotación contra proveedores de hosting horas antes del parche, y Cloudflare confirmó ataques tempranos.
PHP es el lenguaje detrás de WordPress, WooCommerce, Magento, Moodle y buena parte de los portales de proveedores, intranets y tiendas en línea de las PyMEs mexicanas. Si tu empresa tiene un sitio web, lo más probable es que esta noticia te toque.
Qué se corrigió
| Dato | Detalle |
|---|---|
| Fallas | CVE-2026-109618 (corrupción de memoria al agotarse la memoria) y CVE-2026-109619 (estado interno que sobrevive entre peticiones) |
| Impacto | Ejecución remota de código sin autenticación |
| Gravedad | CVSS 4.0: 9.2 (aviso de PHP del 20 de octubre); la filtración previa hablaba de 10.0 |
| Afecta a | Toda instalación que atiende peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed |
| Mayor riesgo | mod_php: el ataque se dispara antes de que corra cualquier código de la aplicación |
| Versiones corregidas | 8.5.12, 8.4.27, 8.3.36 y 8.2.35 |
| PHP 8.1 y anteriores | Sin actualización oficial; correcciones mínimas en código fuente para 7.4, 8.0 y 8.1 |
Fuentes: aviso de seguridad de php.net (21 de octubre de 2026) e IT Pro.
En palabras simples: un atacante manda una petición armada a propósito, normalmente un envío de formulario con archivos, que hace que PHP se quede sin memoria a la mitad de su trabajo. Al limpiar, PHP trata datos basura como si fueran válidos, y eso abre la puerta para correr comandos en el servidor. No hace falta que el sitio tenga un formulario de carga visible.
Cómo se llegó aquí
La falla la descubrieron por separado los investigadores de Wiz y de Calif entre agosto y septiembre, y la reportaron al proyecto PHP, que empezó a preparar el parche en coordinación. El martes 20 de octubre se filtró su existencia antes de tiempo, y esa misma tarde la PHP Foundation anunció la publicación de emergencia para el día siguiente.
En hora del centro de México, la secuencia del miércoles 21, según el seguimiento en vivo de Precursor Security, fue así:
- 1:12 a. m.: el NCSC, la agencia de ciberseguridad del Reino Unido, emite alerta.
- 1:34 a. m.: Patchstack reporta intentos de explotación en proveedores de hosting.
- 5:56 a. m.: el NCSC recomienda sacar de línea los sistemas que no puedan parcharse de inmediato; gobiernos y universidades de Finlandia y Países Bajos desconectan servicios.
- Cerca de las 8:00 a. m.: salen las versiones corregidas.
- 8:31 a. m.: ya hay más de 100 repositorios con pruebas de concepto en GitHub, algunos con malware para quien los descargue.
Tenable, por su parte, no había logrado verificar ninguno de esos exploits a media mañana. Eso no es razón para esperar: la firma de seguridad para comercio electrónico Sansec anticipó explotación masiva en cuanto se publicara el parche.
Por qué es peor que la falla de un complemento
Estamos acostumbrados a avisos de complementos de WordPress explotados o de plugins de WooCommerce usados para meter puertas traseras. Esta vez el problema está una capa más abajo, en el intérprete que ejecuta todo lo demás. Según el seguimiento de Precursor Security, los investigadores demostraron ejecución de código sin iniciar sesión contra WordPress, Drupal, Joomla, Magento, Nextcloud, phpMyAdmin, Roundcube, Laravel, Symfony y WHMCS con su configuración de fábrica.
Dos agravantes para las PyMEs:
- Versiones viejas. Muchos sitios de WordPress y Joomla siguen en PHP 8.1 o anterior, que ya no recibe actualizaciones oficiales. Y PHP 8.2, aunque hoy sí recibió parche, llega a fin de vida el 31 de diciembre de 2026, según php.net.
- El parche depende de alguien más. En hosting compartido, el que actualiza es el proveedor. cPanel estaba preparando paquetes de PHP 7.4 a 8.5 durante el día, y algunos repositorios populares de Linux avisaron que no tendrían la actualización el mismo miércoles. Ubuntu, Debian, Red Hat y CloudLinux recibieron la corrección antes de su publicación.
Qué hacer hoy
- Haz la lista de todo lo que corre PHP. Sitio web, tienda en línea, portal de proveedores, intranet, Moodle, phpMyAdmin, paneles de control, sistemas de tickets. No olvides los equipos "que nadie toca", como el servidor de pruebas o la tienda vieja que sigue en línea.
- Averigua la versión exacta. En tu panel de hosting suele aparecer como "versión de PHP" o "selector de PHP". En un servidor propio,
php -vresponde; en Debian o Ubuntu,dpkg -l | grep phpmuestra la revisión del paquete. Como las distribuciones aplican el parche a versiones viejas, compara contra su aviso de seguridad, no solo contra el número. - Actualiza y reinicia. Lleva PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido de tu distribución, y reinicia los servicios. Si usas contenedores, reconstruye la imagen con la base parchada y vuelve a desplegar.
- Si estás en hosting compartido, escribe hoy a tu proveedor. Pregunta qué versión de PHP tiene tu cuenta, si ya aplicó la corrección y a qué hora. Si te dice que tu versión ya no tiene soporte, sube de versión, aunque implique probar complementos.
- Si no puedes parchar hoy, reduce la exposición. Activa un firewall de aplicaciones: Cloudflare publicó reglas, algunas en su plan gratuito. Aplica las mitigaciones temporales del aviso de php.net, como
session.upload_progress.enabled = 0y unpost_max_sizebajo, enphp.inio en el pool de FPM. En sistemas internos, sácalos de internet y déjalos solo tras VPN. El NCSC británico recomienda desconectar lo que no se pueda actualizar. - Busca señales de intrusión. Si tu sitio estuvo expuesto sin parche desde el 20 de octubre, revisa archivos PHP nuevos en la carpeta pública, tareas programadas (cron) desconocidas, usuarios administradores que nadie creó y procesos de PHP que lanzan comandos del sistema. Si encuentras algo, aísla el servidor y conserva los registros antes de limpiar. Un respaldo fuera del servidor es lo que te permite volver a un punto limpio.
- No descargues los exploits "para probar". Varios de los publicados en GitHub traen malware.
El patrón de fondo
Es la segunda vez hoy que contamos una falla que vive debajo de WordPress y no en WordPress: esta mañana fue Ghostscript y los PDF que toman servidores, y a principios de mes, las 20 vulnerabilidades de Apache 2.4.69. El sitio es tan seguro como la pieza más vieja del servidor. La guía de hardening de servidores Linux explica cómo mantener al día el sistema y no solo la aplicación.
Si no tienes claro quién actualiza PHP en tu sitio o tu tienda en línea, en servidores y ciberseguridad hacemos el inventario, aplicamos el parche correcto, reiniciamos servicios y revisamos que nadie haya entrado antes.
