Casi todas las vulnerabilidades sobre las que terminamos escribiéndoles a nuestros clientes están en algo que el negocio eligió. Un plugin que alguien instaló, una librería que un desarrollador incorporó, un producto que pasó por compras. Esta está en el piso.
Qué pasó
El 21 de octubre de 2026, el proyecto PHP publicó correcciones de emergencia para dos fallas en el intérprete mismo: CVE-2026-109618 y CVE-2026-109619, apodadas php2shell. Ambas están calificadas en 9.2 sobre CVSS v4.0. Ambas permiten que un atacante sin autenticación, sin cuenta y sin ningún punto de apoyo previo, ejecute código en el servidor web.
La primera es un fallo de corrupción de memoria en la forma en que PHP maneja quedarse sin memoria. Una solicitud multipart manipulada agota la memoria mientras aparenta respetar el límite configurado, y la limpieza posterior trata los datos dañados como válidos. La segunda es un use-after-free: estado que sobra de una solicitud apunta a memoria que ya fue liberada. Se alcanza a través de session upload progress, que viene activado por defecto, y a través de los backtraces de errores fatales.
Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las versiones 7.4 a 8.1 recibieron solo parches de código fuente. Las versiones 5.4 a 7.3 no recibieron nada, porque ya pasaron su fin de vida y no reciben correcciones de seguridad en absoluto.
El peor caso es Apache con mod_php, donde la explotación puede tener éxito antes de que corra una sola línea de tu aplicación. PHP-FPM, php-cgi, FrankenPHP y LiteSpeed también están afectados.
Esto no es una vulnerabilidad de plugin, y la diferencia importa
Cuando un plugin de WordPress o un paquete de JavaScript resulta vulnerable, la respuesta es incómoda pero conocida: averiguas qué versión tienes, actualizas, revisas que nada se haya roto. La corrección está en tus manos y el trabajo es tuyo.
php2shell no está en nada que hayas instalado. Está en el programa que lee tu código y lo ejecuta. Nada de tu sitio tiene que ser raro, estar desactualizado o estar mal escrito para verse afectado: una aplicación impecablemente mantenida sobre un intérprete vulnerable es un servidor vulnerable. Tu propia disciplina de actualizaciones, que es justamente en lo que la mayoría de las empresas sí ha invertido, aquí no te compra nada.
También significa que, para la mayoría de las organizaciones, el parche no es suyo. Si estás en hosting compartido, en WordPress administrado o en una plataforma como servicio, no controlas el binario de PHP. Lo parcha alguien más, en su calendario, y toda tu remediación consiste en averiguar si ya lo hizo.
Ese es un problema genuinamente distinto, y la versión honesta del consejo es incómoda: tu ventana de exposición aquí la definió la competencia operativa de un proveedor, no la tuya.
La pregunta que la mayoría de las empresas no puede responder
Pregúntale a una organización si su sitio principal corre PHP y te responde en segundos. Pregunta dónde más corre PHP y la sala se queda callada.
Por nuestra experiencia, la lista casi siempre es más larga de lo que alguien espera. El micrositio de marketing que se armó para una campaña hace tres años. La copia de staging del sitio principal que nunca se dio de baja. La herramienta interna que un área contrató por su cuenta. El subdominio que dejó una agencia que ya no trabaja aquí. El equipo de red o el NAS con una interfaz de administración en PHP que nadie considera un sitio web.
Nada de eso está en el calendario de parches de nadie, porque nada de eso está en la lista de nadie. Sí está, en cambio, en internet, y a un escáner no le importa cuáles de tus sistemas recuerdas tener.
Es la misma brecha que aparece una y otra vez en los incidentes que analizamos: el sistema periférico, el subdominio olvidado, el host que nunca llegó al inventario de activos. Una falla a nivel de intérprete es simplemente una manera más eficiente de descubrir que tu inventario está incompleto.
Una nota sobre las cifras, y sobre la línea de tiempo
Hay dos cosas que se están reportando sobre php2shell que conviene tratar con cuidado.
Las cifras de exposición no coinciden. Tenable ubicó el número de hosts expuestos a internet y potencialmente vulnerables entre 1.3 y 1.9 millones, según la metodología. Cortex Xpanse de Palo Alto reportó más de 22.6 millones de instancias expuestas. Es un orden de magnitud de diferencia, y la brecha casi seguramente tiene que ver con qué cuenta cada uno: hosts contra instancias, versiones confirmadas contra versiones plausibles. Cualquiera de los dos números sostiene la conclusión de que esto es amplio. Ninguno debería citarse como la cifra.
La línea de tiempo de explotación tampoco está resuelta. Tenable reportó que Amazon Threat Intelligence observó un intento de explotación de php2shell el 17 de octubre, cuatro días antes de la divulgación pública, y describió las vulnerabilidades como ampliamente explotadas para el 21 de octubre. Rapid7, en su propio análisis, señaló que existían exploits de prueba de concepto públicos pero que "ninguno parece ser ampliamente confiable", y que no había observado explotación activa al momento de publicar.
Esos dos relatos no son necesariamente contradictorios: se escribieron en momentos distintos, y "un intento observado" y "explotación ampliamente confiable" son afirmaciones diferentes. Pero no le diríamos a un cliente que el panorama de explotación está claro, porque no lo está. Lo que sí está suficientemente claro para actuar es que existe explotación funcional, que la clase de falla es bien conocida, y que el intervalo entre la divulgación y el escaneo masivo de algo así se mide en horas.
Esta la encontró la IA, y eso corta por los dos lados
Los investigadores a quienes se atribuye el hallazgo —uno que firma como Calif y un equipo de Wiz— dijeron que usaron modelos de IA en el trabajo.
Eso merece más que un encogimiento de hombros. Hace unas semanas escribimos sobre herramientas agénticas comprimiendo la línea de tiempo del atacante en las intrusiones a la banca de Seúl, y la preocupación obvia era que la ofensiva se abarate más rápido que la defensa. php2shell sirve de contrapeso útil: la misma capacidad, apuntada a un intérprete de veinte años, encontró dos fallas críticas y logró que se corrigieran antes de que se quemaran ampliamente.
La implicación incómoda está en medio. Si el descubrimiento de fallas se acelera por ambos lados, entonces la cantidad de divulgaciones críticas, sin autenticación y de parcheo urgente por año sube —no porque el software esté empeorando, sino porque hay más ojos, mecánicos, encima. La variable que un negocio realmente controla no es cuántas de estas aparecen. Es cuánto tarda en averiguar si está afectado y en aplicar la corrección. Ese número es ahora el que vale la pena medir.
Qué hacer en concreto
Establece qué estás corriendo, hoy. En WordPress es Herramientas → Salud del sitio → Información → Servidor. En un servidor propio, php -v. Hazlo para cada sitio y herramienta que tengas, no solo el principal, y si producir esa lista toma más de una tarde, ese es el hallazgo más importante.
Hazle a tu proveedor una pregunta específica. No "¿estamos seguros?", sino "¿qué versiones de PHP en nuestra cuenta ya están parchadas para CVE-2026-109618 y CVE-2026-109619, y a qué hora?". Varios proveedores administrados parcharon en cuestión de horas y publicaron la marca de tiempo. Un proveedor que no puede responder con precisión ya te dijo algo útil.
Sal de las versiones en fin de vida, y trátalo como urgente, no como orden y limpieza. PHP 5.4 a 7.3 no se van a corregir para esto, ni para lo siguiente. Si algo tuyo está en esas versiones, dejó de ser un problema de parcheo: es un problema de migración, y el reloj empezó a correr hace rato.
Usa las mitigaciones como puente, no como destino. Donde el parcheo tenga que esperar, desactivar session upload progress (session.upload_progress.enabled=0) y, en PHP 8.5, poner fatal_error_backtraces=0 reduce las rutas alcanzables. No son una corrección. Vale la pena conservar la frase de Rapid7: una actualización que contenga ambas correcciones completas es la única remediación completa.
Asume que la ventana estuvo abierta y revisa. Para cualquier cosa expuesta a internet que estuvo sin parchar entre el 17 y el 22 de octubre aproximadamente, trata el compromiso como posible y no como descartado. Registros del servidor web, archivos inesperados en los directorios públicos, tareas programadas nuevas, conexiones salientes desde el host web: los lugares de siempre, revisados bien una vez, salen más baratos que quedarse con la duda.
El resumen
No hay nada que un negocio hubiera podido hacer distinto en su propio código para evitar php2shell. Eso es precisamente lo que la hace digna de atención: recuerda que una parte significativa de tu superficie de ataque la mantiene gente que no empleas, con software que no elegiste, en un calendario que no fijas tú.
Las dos cosas que sí controlas son saber dónde está corriendo ese software, y qué tan rápido puedes averiguar si ya fue corregido. Ambas son preguntas de inventario y de proceso más que preguntas técnicas, que es justamente por lo que suelen quedarse sin presupuesto hasta que una mañana como la del 21 de octubre las vuelve urgentes.
Fuentes
- php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions — Tenable
- CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP — Rapid7
- Threat Brief: Critical Vulnerabilities in PHP — Unit 42, Palo Alto Networks
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 — Google Cloud
- PHP critical security release, October 2026: what it means for your WordPress site — Wordify
