PHP: parches urgentes para 2 fallos RCE críticos

Qué parcheó PHP el 21 de octubre y por qué no puedes esperar

El equipo de seguridad de PHP lanzó parches de emergencia para dos fallos de ejecución remota de código (RCE, por remote code execution) que afectan a toda la línea PHP 8.x. Están catalogados como CVE-2026-109618 y CVE-2026-109619, los investigadores los agruparon bajo el nombre php2shell y ambos llevan una puntuación de 9.2 sobre 10 en CVSS v4.0, según CyberScoop.

La urgencia no es teórica: ya había exploits circulando desde la noche previa al parche, después de que el proceso de divulgación coordinada se rompiera antes de tiempo. Si tu startup tiene un sitio, una tienda o una API en PHP —WordPress, Drupal, Joomla, Magento o código propio— la ventana para actualizar se mide en horas, no en semanas.

Las versiones corregidas, según BleepingComputer, son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los entornos afectados incluyen PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. La mala noticia para quien no puede tocar el servidor: el fallo está en el intérprete de PHP, no en el CMS ni en el framework, así que ningún plugin de seguridad te salva por sí solo.

¿Por qué el riesgo es mayor en mod_php?

BleepingComputer recoge la evaluación del propio equipo de seguridad de PHP: el riesgo es máximo en configuraciones con mod_php, donde existe un exploit demostrado en el que una petición no autenticada puede desencadenar el ataque antes de que se ejecute cualquier código de la aplicación.

Traducido a la operación de una startup: tus defensas de aplicación nunca entran en juego. El login, el plugin de seguridad de WordPress, el middleware de tu framework —nada de eso llega a ejecutarse antes de que el atacante tenga el control del worker.

Los dos fallos comparten origen: PHP puede dejar la memoria en un estado corrupto cuando una petición termina de forma anómala. CVE-2026-109618 explota una cadena de debilidades de manejo de memoria para lograr RCE con la cuenta del web worker; CVE-2026-109619 es un problema de estado global obsoleto que habilita un use-after-free no autenticado y también divulgación de memoria, según BleepingComputer.

El detalle que más debería preocupar a un CTO es otro: Wiz Research demostró que podía leer la memoria del worker de PHP, que puede contener contraseñas, tokens y claves de API (tbreak, citando a Wiz). Un RCE no es solo alguien ejecutando código en tu servidor: es acceso potencial a tus credenciales de base de datos, tus llaves de pasarela de pago y tus secretos de infraestructura. Si esa memoria se filtró, rotar credenciales deja de ser opcional.

Cómo se rompió la divulgación coordinada

El post de Simon Willison documenta una cadena de fallos que convirtió un parche ordenado en una carrera. El 20 de octubre, alrededor de las 15:00 UTC, los dos identificadores CVE empezaron a circular en foros y redes sociales, acompañados de una hora de publicación equivocada y un CVSS incorrecto de 10.0 (el real es 9.2). No se filtraron detalles técnicos, pero el daño ya estaba hecho.

La PHP Foundation explica lo que pasó después: el proyecto adelantó su preanuncio y lo publicó a las 19:30 UTC, y movió la release del 22 de octubre a las 14:00 UTC del 21 de octubre. Ese mismo día, cerca de las 20:00 UTC, Calif —una de las firmas de seguridad que había reportado los fallos— publicó por error un video que mostraba su prueba de concepto funcionando contra varios objetivos y revelaba detalles adicionales. Las copias del video borrado circularon igual y aceleraron el desarrollo de PoCs de explotación.

Del otro lado, el equipo que descubrió la vulnerabilidad publicó su propia cronología:

• 19 de agosto de 2026: Wiz Research descubre el primer fallo de PHP usando Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol.
• 20 y 21 de agosto de 2026: confirman RCE no autenticado contra Drupal y WordPress, respectivamente.
• 24 de agosto de 2026: reportan las vulnerabilidades al equipo de seguridad de PHP.
• 21 de septiembre de 2026: PHP reconoce los reportes y empieza a desarrollar el parche coordinado.
• 21 de octubre de 2026: releases parcheadas disponibles y divulgación pública.

Es decir: hubo casi dos meses de trabajo coordinado que la filtración redujo a un solo día de ventaja efectiva.

Cuánta superficie de ataque hay realmente

Los números explican por qué gobiernos enteros apagaron sitios. PHP corre entre el 70% y el 80% de los sitios web cuyo lenguaje de servidor es conocido, según estimaciones que cita CyberScoop y el dato de W3Techs que recoge Decrypt.

• VirusTotal, citado por BleepingComputer, estima más de 5,1 millones de hosts PHP expuestos en internet, con unos 3,8 millones con al menos un puerto abierto.
• CyberScoop recoge estimaciones de investigadores de más de 1,3 millones de hosts potencialmente vulnerables, mientras una búsqueda en Shodan contó cerca de 1,9 millones.
• Entre los servidores que revelan su versión, unos 758.000 corren ramas de PHP 5.4 a 8.1 frente a 272.000 en ramas soportadas, según VirusTotal vía CyberScoop.
• La firma Mallory contó unos 884.000 hosts expuestos que anunciaban PHP 8.1 o anterior el 20 de octubre (Decrypt).

La respuesta institucional fue contundente. El centro estatal finlandés Valtori empezó a sacar servicios web públicos de línea, la agencia nacional de ciberseguridad de Países Bajos bajó su propio sitio y el Ministerio del Interior de Francia dejó portales de prefecturas offline de forma temporal, según Decrypt. CERT-EU y el NCSC británico recomendaron aislar las aplicaciones expuestas a internet cuando el parche inmediato no fuera viable.

Hay una tensión honesta en los reportes: CyberScoop señaló que CISA no había observado explotación hasta esa tarde y que varios investigadores veían sobre todo reconocimiento y sondeo, mientras watchTowr decía haber detectado explotación real en su red de honeypots y Patchstack listaba incidentes confirmados (tbreak). Con este nivel de severidad, esa diferencia no cambia la decisión: se parchea igual.

El cambio de fondo: la IA encontró el bug antes que los atacantes

Wiz reportó que la vulnerabilidad existía desde hace décadas, pero era tan compleja que pocos atacantes podían explotarla: requería construir exploits para bugs de memoria que funcionaran a través de distintas versiones, configuraciones y comportamientos de aplicación.

Según declaraciones recogidas por CyberScoop, los modelos de IA frontera eliminan esa barrera porque adaptan exploits a distintas versiones y layouts de memoria. Las propias palabras de los investigadores de Wiz: esto cambia la economía tanto del descubrimiento como de la explotación.

El otro lado de la moneda también es real. OpenAI dijo en su blog, citado por CyberScoop, que a su conocimiento la IA de frontera encontró estas vulnerabilidades antes que los atacantes, lo que abrió una Defender's Window para preparar parches y protecciones. La misma nota advierte que espera que hallazgos similares aumenten marcadamente en los próximos meses.

¿Qué significa esto para tu startup?

Si vendes software o servicios, tu sitio es parte de tu producto: caído o comprometido, el costo reputacional y de confianza es inmediato. Y si manejas datos de usuarios, un RCE significa que la conversación pasa de uptime a notificación de brecha.

Acciones concretas, en orden:

• Verifica tu versión de PHP ahora. Si es 8.x, el objetivo es 8.5.12, 8.4.27, 8.3.36 o 8.2.35 según tu rama. Si estás en 8.1 o anterior, no habrá release oficial: el equipo de PHP publicó backports mínimos de código para 7.4, 8.0 y 8.1, y tu distribución o proveedor LTS puede tener su propia corrección.
• No esperes a tu CMS. Wordfence advirtió que las actualizaciones automáticas no aplican esta corrección; el arreglo es de PHP, no de WordPress. Si estás en hosting compartido o gestionado, escribe a tu proveedor y pide confirmación por escrito de que aplicó los paquetes parchados.
• Si usas el repositorio comunitario rpms.remirepo.net, la PHP Foundation advirtió que no tendrá actualizaciones ese día: pasa a paquetes de la distribución o compila desde el código fuente.
• Si no puedes parchear ya, aplica las mitigaciones temporales que publicó el equipo de PHP —bajar post_max_size, desactivar session.upload_progress.enabled, ajustar fatal_error_backtraces en PHP 8.5— y considera aislar la aplicación de la red pública. El WAF de Cloudflare quedó disponible incluso para planes gratuitos, pero el CTO de Cloudflare lo llamó solo un stopgap.
• Revisa logs e integridad de archivos. Busca peticiones anómalas y archivos PHP inesperados desde el 20 de octubre, y rota las credenciales que hayan estado accesibles en el worker de PHP.
• Planifica la salida de PHP 8.2. Según Decrypt, esa rama llega a fin de vida el 31 de diciembre de 2026 y después no recibirá más parches de seguridad. Si tu stack se va a quedar ahí, tienes una migración con fecha límite.

Un dato para calibrar la velocidad de esta carrera: en septiembre, atacantes sondearon sitios vulnerables menos de cinco horas después de que se publicara el parche de otra vulnerabilidad crítica de WordPress Core, según TechRepublic. La lección de esta semana es la misma, amplificada: el parche no cierra la historia, la abre.

Conclusión

PHP2Shell no fue un susto mediático: fueron dos RCE de severidad crítica en el intérprete que sostiene la mayor parte de la web, con exploits en circulación antes de que existiera parche público. La buena noticia es que el arreglo ya está disponible y que la IA de frontera dio a los defensores una ventaja inédita de dos meses. La mala es que esa ventaja solo se cobra si actualizas.

Si hoy no puedes confirmar en qué versión corre tu PHP, ese es tu primer pendiente del día. Es la clase de tarea que no se delega sin verificación: pide la confirmación, guárdala y agenda una revisión de versiones soportadas antes de que termine el trimestre.

Fuentes

• Today's PHP Security Release, and How We're Strengthening PHP Security (fuente original)
• Prepare yourselves: PHP to release emergency fixes for 2 critical vulnerabilities
• PHP ships emergency patches for critical PHP2Shell flaws
• PHP Panic: Two Critical Bugs Put 70% of the Internet at Risk
• New PHP vulnerabilities found; Internet is going to be a bit bumpy for a few days
• WordPress Flaw Under Active Attack: CVE-2026-87902