PHP2Shell: dos RCE críticos en PHP se filtraron antes de tiempo y el parche sale hoy

Ayer a la mañana apareció en Hacker News un post que no debía existir todavía: dos vulnerabilidades de ejecución remota de código en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, se habían filtrado antes de un embargo de divulgación coordinada. En cuestión de horas la firma watchTowr confirmó que son reales y explotables, y el equipo de seguridad de PHP tomó la única decisión razonable cuando el secreto está roto: adelantar el parche de emergencia a hoy, miércoles 21 de octubre a las 14:00 UTC, con severidad crítica y CVSS v4.0 de 9.2, reservándose publicarlo aún antes si aparecían detalles técnicos o ataques activos.

Qué se sabe (y qué no)

Lo confirmado: son vulnerabilidades críticas de RCE en PHP core, con explotabilidad ya reproducida por watchTowr, que se limitó a decir tómenlo en serio y apliquen parches en cuanto estén disponibles. Junto con la fuga circuló una captura de una herramienta llamada PHP2Shell, acreditada a un grupo llamado Calif.IO, cuyo banner dice funcionar contra cualquier release de PHP desde la 5.4.0 en adelante. Eso hay que leerlo con pinzas —es el claim de la herramienta, no del proveedor—, pero el alcance potencial da frío: PHP 5.4 salió en 2012, así que la ventana cubre catorce años de versiones de un lenguaje que mueve buena parte del web, WordPress incluido.

Lo que no se sabe todavía: el detalle técnico de la raíz, el rango exacto de versiones afectadas y si el exploit funciona con una petición web normal o depende de alguna configuración del servidor. Todo eso se publica junto con el parche. Hasta ahora no hay explotación en la naturaleza reportada, pero Sansec proyecta ataques masivos dentro de los primeros quince minutos después del release. Sí, minutos. El ciclo de difundir el fix, crear el exploit automatizado y escanear en masa ya no toma una hora; toma menos que tu café.

Mi rutina cuando cae una noticia así

Administro un grupo de VPS con WordPress y varias cosas propias en PHP, así que esta noticia me encontró haciendo lo único que de verdad recomiendo: inventario. Correr php -v en cada máquina, revisar la versión por sitio en el panel de hosting y anotar qué rama tiene soporte activo y cuál está en fin de vida. Tomó veinte minutos y el resultado siempre incomoda: casi siempre aparece dos o tres servidores apoyados en ramas que nadie parchea, de esos proyectos pequeños que andan funcionando hace años bajo el lema si no está roto, no lo toques. Los reportes de la industria indican que el fix llegaría solo a las ramas con soporte vigente, así que un PHP 7 expuesto a internet quedaría sin parche posible: la jugada es actualizarlo hoy o sacarlo de la red mientras tanto.

El segundo paso es no depender solo del patch mismo: si tienes WAF, pásalo a modo bloqueo para el tráfico de los sitios PHP, y pon alerta en los procesos raros que pueda lanzar el worker de PHP: shells, intérpretes de scripts, descargadores. Monitoreo a nivel de proceso, como el process-watcher de Florian Roth montado en modo observación, te da esa visibilidad gratis en un Linux sin EDR, cachai que es más rápido que esperar a encontrar la web defaceada.

La opinión, como siempre

Lo rescatable es que aquí el sistema funcionó: la confirmación por terceros y la aceleración del parche son la respuesta correcta cuando la coordinada se rompe por el lado social, no técnico. La parte que me deja pensando es otra: un solo post en foros puede desbaratar semanas de coordinación entre investigador, proveedor y distribuciones, y el único recurso real de respuesta es tener la infraestructura al día antes de la noticia. El embargo protege a quien coordina; no protege a quien administró mal su servidor. Yo prefiero la segunda lección: si tu inventario de versiones lo sacas el día que sale un CVSS 9.2, ya lo sacaste tarde.

Fuente del tema: Upcoming Critical PHP Security Release, del sitio oficial de PHP.

Fuente de inspiración: Upcoming Critical PHP Security Release