Saltar al contenido
ITLAB
ESEN

22 / 10 / 2026 · Seguridad

PHP corrige dos vulnerabilidades críticas: actualizar ya

PHP publicó parches para dos fallas críticas de ejecución remota de código (CVSS v4.0 9.2). Qué versiones corrigen, a quién afecta y qué hacer ahora.

El 21 de octubre de 2026 el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación. Su aviso pide actualizar de inmediato y advierte que no hay mitigaciones completas.

  • CVE-2026-109618 y CVE-2026-109619: CVSS v4.0 de 9.2 (crítica) según PHP; NVD les asigna 9.8 en CVSS v3.1. Incluyen uso de memoria liberada (CWE-416).
  • Afectan a todas las versiones anteriores a las corregidas. Wiz Research, que las difundió como «PHP2Shell», sostiene que afectan a versiones de la última década, hasta la 5.4.

A quién afecta

Es común suponer que solo corre riesgo Apache con mod_php. Según php.net, están en riesgo todas las instalaciones que atienden solicitudes web, incluidas PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor en mod_php, y uno de los avisos de GitHub informa ejecución remota validada también en FPM bajo ciertas condiciones.

PHP 7.4, 8.0 y 8.1 no tienen soporte; hay retroportes mínimos en código fuente y paquetes de algunos distribuidores. PHP 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026.

Estado de explotación

CISA indicó el 21 de octubre que no había observado explotación. Según la PHP Foundation, tras una filtración circularon pruebas de concepto, pero no se identificaron exploits funcionales al divulgarse. Al 22 de octubre de 2026 (fecha de consulta), los CVE no figuran en el catálogo KEV de CISA y no encontramos reportes confiables de explotación.

Cómo se gestionó

Es común atribuir el hallazgo solo a Wiz. Según la PHP Foundation, Calif y OpenAI reportaron en privado la causa raíz el 11 de agosto y Wiz aportó vectores adicionales el 24 de agosto. Una lectura frecuente es que el parche llegó rápido; la Fundación reconoce que el problema de fondo se detectó en una auditoría de 2024, sin vía de explotación concreta, y califica el retraso de «falla estructural» por el proceso de decisión y la falta de recursos.

También es común suponer que el aviso con un día de anticipación estaba planificado. Según la Fundación, el 20 de octubre, cerca de las 15:00 UTC, los CVE empezaron a circular en redes sin detalles técnicos; PHP adelantó su anuncio (19:30 UTC) y movió la publicación del 22 al 21 de octubre a las 14:00 UTC, porque los distribuidores aún preparaban sus paquetes. Un distribuidor rompió además el embargo horas antes. No encontramos otro anuncio previo de una publicación de seguridad en el archivo de php.net (2019 a 2026): fue una medida excepcional.

Wiz afirma haber usado IA (Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol). Las correcciones las hizo el equipo de seguridad de PHP, con desarrolladores financiados por la PHP Foundation.

Qué hacer ahora

  1. Inventariar los sistemas con PHP, incluido el software que lo trae embebido.
  2. Actualizar a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 o al paquete corregido de la distribución, empezando por lo expuesto a internet, y reiniciar todos los procesos de PHP.
  3. Si no se puede actualizar de inmediato, o se usa PHP 8.1 o anterior: CISA recomienda sacar esos sistemas de línea hasta actualizarlos. Las medidas provisionales de php.net reducen la exposición, pero no dejan segura la instalación; según CISA, un firewall de aplicaciones web puede dar cierta protección.
  4. Hosting administrado: confirmar versión y fecha de actualización con el proveedor.
  5. Monitorear: vigilar procesos de PHP que lancen intérpretes de comandos o descarguen herramientas, y conservar los registros.

La lectura de IT Lab

IT Lab actualizó sus servidores tras la publicación de los parches, sin incidentes. Parchar a tiempo exige tener inventario y procedimientos antes del aviso.

La divulgación coordinada funcionó en lo esencial: reportes privados, parches para todas las ramas con soporte y retroportes para las antiguas. No fue perfecta: la causa raíz se conocía desde 2024, hubo una filtración y el embargo se rompió. Valoramos que la Fundación lo reconozca con transparencia.

Wiz atribuye a la IA parte del hallazgo de una falla presente por años. Si la tendencia sigue, se hallarán más fallas y más rápido; la diferencia la hará la capacidad de actualizar pronto.

A juicio de IT Lab, este episodio no justifica por sí solo cambiar de plataforma. Muchas instituciones operan software abierto sobre PHP, como WordPress y Drupal; Drupal.org declara que «más de 150 gobiernos» lo usan. Ningún lenguaje está libre de fallas graves; ecosistemas con muchas dependencias, como el de JavaScript, tienen sus propios riesgos. Migrar traslada el riesgo; reducirlo exige inventario, actualización oportuna y monitoreo.

Preguntas frecuentes

Mi sitio usa WordPress o Drupal. ¿Está afectado? Si el servidor ejecuta PHP anterior a las versiones corregidas, sí. Actualizar el CMS no corrige la falla.

¿Basta con cambiar la configuración? No. Los avisos indican que actualizar es la única mitigación completa.

¿Uso PHP-FPM, estoy a salvo? No. php.net incluye FPM entre las instalaciones en riesgo.

¿Hay explotación activa? Al 22 de octubre de 2026 no hay reportes confiables, pero circulan pruebas de concepto. Conviene actuar como si fuera inminente.

¿Y PHP 7.4, 8.0 u 8.1? Sin soporte: conviene migrar.

Esta nota se actualizará si cambian las recomendaciones oficiales o el estado de explotación.

IT Lab ofrece gestión de parches y revisión de exposición para organizaciones chilenas: inventario de versiones, actualización coordinada y comprobación posterior. Conversemos.

Fuentes

¿Necesitas a alguien que se haga cargo de tu tecnología?

Cuéntanos qué necesitas ordenar, proteger o resolver. La primera conversación no tiene costo: evaluamos si nuestro modelo te sirve y cuáles serían los siguientes pasos.

Conversemos sobre tu empresa