Imagen: Wiz Research

❝

En 30 segundos

  • El 21 de octubre de 2026 el proyecto PHP publicó parches para dos vulnerabilidades críticas: CVE-2026-109618 y CVE-2026-109619 (CVSS 9.2 cada una). Pueden permitir ejecución remota de código sin autenticación.

  • Versiones corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las versiones 8.1 y anteriores ya no reciben updates oficiales: pide backports a tu proveedor o migra.

  • Actualizar es la única solución completa. Las configuraciones de mitigación reducen riesgo, pero no hacen seguro un servidor.

  • Si usas WordPress, Drupal, Joomla o un hosting compartido, pregunta hoy a tu proveedor si ya parchearon.

  • El nombre «PHP2Shell» es el del exploit con el que Wiz Research demostró el problema. Wiz no ha publicado ese exploit en su post.

Qué es PHP2Shell

PHP2Shell es el nombre que le puso el equipo de Wiz Research al exploit con el que demostró que se puede tomar el control de un servidor que ejecuta PHP. Lo hicieron combinando varios fallos del propio motor de PHP, no de WordPress ni de ningún plugin.

Es una diferencia importante: el problema está en PHP. Según Wiz, incluso una aplicación mínima tipo «Hola mundo» puede ser vulnerable si corre sobre una versión afectada. Wiz mostró el ataque contra WordPress, Drupal y Joomla (en sus imágenes de contenedor más recientes al momento de las pruebas) solo como ejemplos.

Los fallos nacen de cómo PHP maneja los errores fatales, sobre todo cuando se queda sin memoria. En palabras sencillas: si una petición hace que PHP se quede sin memoria en el peor momento, PHP puede dejar «basura» interna sin limpiar, y una petición posterior que atienda el mismo proceso puede confiar en esa basura. Eso corrompe la memoria y, según el caso, permite leer datos o ejecutar código.

Los dos CVE, según el aviso de PHP:

  • CVE-2026-109618: ejecución remota de código por corrupción de memoria tras un error de falta de memoria (OOM).

  • CVE-2026-109619: ejecución remota de código por «estado global obsoleto» que sobrevive a una petición anterior.

Ambos tienen CVSS v4.0 de 9.2 (crítico), con ataque por red, sin privilegios y sin interacción del usuario.

A quién afecta

A cualquier instalación de PHP que atienda peticiones web con una versión sin parchear. El aviso de PHP menciona expresamente:

  • PHP-FPM

  • Apache con mod_php

  • php-cgi

  • FrankenPHP

  • LiteSpeed

El equipo de PHP considera mod_php el escenario de mayor riesgo: ahí se demostró que una sola petición sin autenticar puede disparar el ataque antes de que corra código de tu aplicación. En PHP-FPM, el análisis de PHP indica que es susceptible, aunque en el aviso no figura un exploit completo para esa configuración.

Versiones afectadas (menores que):

  • PHP 8.5 anteriores a 8.5.12

  • PHP 8.4 anteriores a 8.4.27

  • PHP 8.3 anteriores a 8.3.36

  • PHP 8.2 anteriores a 8.2.35

  • Ramas sin soporte (8.1 y anteriores): no reciben updates del proyecto. PHP publicó backports mínimos de código fuente para 7.4, 8.0 y 8.1, y algunas distribuciones o proveedores LTS ofrecen los suyos.

Wiz afirma que «todas las versiones de la última década» están afectadas, hasta PHP 5.4, y que PHP alimenta cerca del 70 % de los sitios web. Ojo con eso: el 70 % es la cuota de sitios que usan PHP, no el porcentaje de sitios vulnerables hoy, y el aviso oficial de PHP no enumera la rama 5.x. Para tu decisión, lo que importa es tu versión exacta y si tu proveedor ya aplicó el parche.

Cómo saber si estás expuesto

  1. Mira la versión de PHP que usa el servidor web. php -v en la terminal muestra la versión de la línea de comandos, que puede ser distinta a la que atiende tu web. Revisa PHP-FPM, el módulo de Apache o el panel de tu hosting.

  2. Compara con las versiones corregidas (8.5.12, 8.4.27, 8.3.36, 8.2.35).

  3. Ojo con los paquetes de distribución. Debian, Ubuntu, RHEL y similares suelen aplicar el parche sin cambiar el número de versión. Revisa el changelog del paquete o el aviso de seguridad de tu distribución buscando los CVE.

  4. Contenedores: reconstruye las imágenes con una base actualizada. Un contenedor viejo no se parchea solo.

  5. Hosting compartido o gestionado: pregunta al proveedor si ya aplicó el parche. Tú no puedes actualizar PHP en la capa del servidor.

  6. Software que trae PHP por dentro: algunos productos incluyen su propio PHP. CERT-EU remite al repositorio del NCSC-NL para identificar software afectado.

Señales que Wiz sugiere vigilar (no prueban un ataque, solo orientan una revisión): peticiones multipart inusuales seguidas de errores por límite de memoria o respuestas HTTP 500 repetidas, cookies PHPSESSID anormalmente grandes en las respuestas y reinicios inexplicables de workers de PHP. Wiz advierte que, al ocurrir por debajo de la aplicación, los logs de tu app pueden mostrar poco contexto.

Qué hacer: parchear primero, mitigar si no puedes

1. Actualiza a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o instala el paquete corregido de tu distribución) y reinicia todos los workers (PHP-FPM, Apache, FrankenPHP o el que uses). PHP 8.2 llega a fin de vida el 31 de diciembre de 2026, así que planifica la migración a una rama más nueva.

2. Si no puedes parchear todavía, PHP lista mitigaciones parciales. Repetimos lo que dice el propio aviso: reducen la exposición a vías de ataque concretas, pero no hacen seguro un servidor.

Para CVE-2026-109618 (falta de memoria):

  • Fijar memory_limit=-1 de forma que las aplicaciones no puedan cambiarlo (por ejemplo, php_admin_value en el pool de FPM o en Apache). Revisa que ningún ajuste vuelva a poner un límite.

  • Bajar post_max_size: 8M si no hay subida de archivos, 32M si la hay, y mantener upload_max_filesize por debajo.

  • Limitar tamaño de petición, número de campos, partes multipart y cabeceras en el servidor web o proxy.

  • No usar RLIMIT_AS ni RLIMIT_DATA como sustituto, porque pueden provocar justo el fallo que se quiere evitar.

Para CVE-2026-109619 (estado global obsoleto):

  • session.upload_progress.enabled=0 en php.ini o en la configuración del pool/servidor (no con ini_set() ni con .user.ini) y reiniciar workers.

  • En PHP 8.5, fatal_error_backtraces=0.

  • Corregir errores fatales y timeouts que un atacante pueda provocar en tu código.

3. Un tercer aviso, aparte. El 23 de octubre PHP publicó una nota informativa sobre otra vía de ejecución remota, CVE-2026-115560, poco probable porque requiere una combinación inusual de configuración y código. No habrá versión fuera de ciclo: PHP pide dejar session.upload_progress.enabled=0 hasta la próxima versión regular. Si ya lo aplicaste por el punto anterior, no hay que hacer nada más.

4. Windows: si usas PHP en Windows con cURL, PHP publicó el 26 de octubre builds reconstruidos (con sufijo -1) que corrigen un fallo distinto en Brotli (CVE-2026-111497). Es un asunto separado de PHP2Shell.

Lo que no sabemos (marcado como no verificado):

  • Si ya hay explotación activa. CERT-EU dijo el 21 de octubre que circulaban pruebas de concepto y que eso aumenta la probabilidad de explotación; la Fundación PHP indicó que, al momento de la publicación, no había identificado exploits funcionales. No encontramos confirmación independiente de ataques en curso.

  • Si hace falta rotar credenciales. Wiz demostró una vía que lee memoria de los procesos de PHP, donde puede haber contraseñas, tokens o claves de API. Ni PHP ni Wiz piden rotar claves por defecto. Es una precaución nuestra, no una recomendación oficial: si tu servidor estuvo sin parchear y expuesto, valora rotar secretos importantes.

  • La correspondencia exacta entre los cuatro fallos que describe Wiz y los dos CVE. La tabla de Wiz agrupa los errores de forma algo distinta a la descripción del aviso de PHP. Para acciones, guíate por el aviso de PHP.

Qué significa para ti

  • Si tienes un sitio en WordPress, Drupal o Joomla: el parche es de PHP, no del CMS. Actualizar el CMS no te protege de esto. Pregunta a tu hosting qué versión de PHP corre y cuándo la actualiza.

  • Si administras tus propios servidores o contenedores: esto es tarea de hoy. Ubica dónde corre PHP, actualiza, reinicia y verifica la versión.

  • Si desarrollas en Web3 o fintech: paneles de administración, back-offices, APIs viejas o landing pages en PHP también cuentan. Si guardan claves de API o tokens, un fallo que lee o ejecuta en el servidor es más grave. Revisa qué secretos viven en esos servidores.

  • Si lideras un equipo pequeño o una cooperativa: haz un inventario simple (qué corre PHP, qué versión, quién lo administra) y deja a una persona con la responsabilidad de confirmarlo por escrito.

  • El ángulo IA: según Wiz, modelos de IA de frontera hicieron mucho más práctico adaptar el exploit a distintas configuraciones, y lo hicieron en horas. Es una afirmación de Wiz, que además vende seguridad, así que léela con ese contexto. Lo que sí confirma la Fundación PHP es que los fallos de fondo llevaban años y que el equipo de seguridad de PHP recibe hoy muchos más reportes asistidos por IA.

Esto no es para entrar en pánico, pero sí para no dejarlo para el viernes.

Seguimos contándote lo que importa

Si quieres que te traigamos cada semana lo importante de tecnología, seguridad y blockchain en español y sin ruido, suscríbete a este blog y síguenos en X en @TellusCoop. Y si ya parcheaste, cuéntanos qué te funcionó: nos sirve para ayudar a otras personas de la comunidad.

Fuentes

Datos verificados el 27 de octubre de 2026 contra las fuentes anteriores. Este artículo es informativo y no sustituye el aviso de tu proveedor ni el de tu distribución.

Sigue leyendo

Ver más
caret-right