← Todas las noticias
ARTÍCULO
Rumores
23 de octubre de 2026 4 min de lectura
Producido por Neska

Vulnerabilidad PHP2Shell: actualiza PHP hoy, los dos fallos RCE ya se explotan

Dos fallos críticos de PHP, CVE-2026-109618 y CVE-2026-109619, permiten ejecutar código sin autenticación y ya se explotan. Las versiones corregidas salieron el 21 de octubre.

En este artículo
  1. Qué está confirmado
  2. Vulnerabilidad PHP2Shell: qué versiones de PHP son seguras
  3. Qué se dice
  4. Por qué te interesa
  5. Qué hacer hoy

La vulnerabilidad PHP2Shell son en realidad dos fallos críticos del lenguaje PHP, CVE-2026-109618 y CVE-2026-109619, que permiten a un atacante sin credenciales ejecutar código en un servidor web. El proyecto PHP publicó versiones corregidas el 21 de octubre de 2026 y ese mismo día se observaron los primeros ataques. Si un servidor tuyo, o de un cliente, ejecuta PHP, actualízalo hoy.

Una gran sala de datos vista desde arriba, con filas de racks de servidores y carteles que indican servidores de correo y servidores web.
Foto: Florian Hirzinger - www.fh-ap.com (CC BY-SA 3.0), Wikimedia Commons.

Qué está confirmado

El proyecto PHP recibió los primeros avisos el 11 de agosto de 2026. Amazon Threat Intelligence informó de un intento de explotación el 17 de octubre, antes de la divulgación pública. El 20 de octubre los detalles se filtraron en línea antes de la fecha acordada y PHP adelantó la versión de emergencia al 21 de octubre. Ese día watchTowr observó explotación activa en su red de honeypots.

CVE-2026-109618 está en la gestión de los errores de memoria agotada: si PHP se queda sin memoria mientras prepara los datos de la petición, esos datos quedan inicializados solo en parte y la limpieza final los trata como válidos. CVE-2026-109619 es un error de estado global obsoleto que provoca un use-after-free en el heap, con divulgación de memoria y ejecución de código. Ambos permiten la ejecución remota de código, sin autenticación, con los privilegios de la cuenta del servidor web. Los avisos de los proveedores de seguridad los puntúan con 9,2 en CVSS v4.0.

Está afectada toda instalación de PHP que atienda peticiones web: Apache con mod_php, PHP-FPM, php-cgi, LiteSpeed y FrankenPHP. El proyecto PHP considera que el riesgo es mayor con mod_php, porque el ataque puede tener éxito antes de que se ejecute cualquier código de la aplicación. Por el mismo motivo, un cortafuegos de aplicaciones web o un agente RASP dentro del proceso PHP podrían no detenerlo.

Vulnerabilidad PHP2Shell: qué versiones de PHP son seguras

  • PHP 8.5: actualiza a la 8.5.12.
  • PHP 8.4: actualiza a la 8.4.27.
  • PHP 8.3: actualiza a la 8.3.36.
  • PHP 8.2: actualiza a la 8.2.35.
  • PHP 8.1, 8.0 y 7.4: sin versión oficial. Solo existen backports mínimos como código fuente, o como paquetes de distribuciones y proveedores LTS.
  • PHP 7.3 y anteriores, incluido PHP 5: sin corrección; hay que pasar a una rama con soporte.

Las distribuciones Linux suelen corregir un fallo sin cambiar el número de versión: revisa el changelog del paquete, no solo la salida de php -v.

Rumor

Qué se dice

Las fuentes no coinciden sobre el estado del exploit. Algunos investigadores afirman que los dos fallos ya están encadenados en un único script funcional y que hay análisis y una herramienta públicos. Huntress escribió que no había reproducido una prueba de concepto, y JFrog advirtió de que circulan exploits falsos. Quien descargue de un foro un supuesto exploit de PHP2Shell se arriesga a instalar malware.

A 22 de octubre, los fallos no figuraban en el catálogo KEV de la CISA, según watchTowr. El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) instó a actualizar de inmediato o a desconectar los sistemas expuestos. VirusTotal calcula que más de 5,1 millones de hosts PHP son accesibles desde internet.

Por qué te interesa

Si gestionas la informática de una pyme o de varios clientes, PHP no está solo en los sitios que has escrito tú. Está en WordPress, Joomla, Magento, PrestaShop, en el webmail, en aplicaciones de gestión antiguas y en cualquier contenedor cuya imagen base incluya PHP. Un contenedor conserva el PHP con el que se construyó: hay que reconstruirlo o descargar una imagen corregida y volver a desplegar.

Qué hacer hoy

  1. Haz inventario: php -v en cada host y docker exec <container> php -v en cada contenedor que sirva PHP.
  2. Actualiza a la versión corregida, o al paquete corregido de tu proveedor, y reinicia PHP-FPM o Apache.
  3. Si no puedes actualizar ya, retira ese sistema del acceso directo desde internet.
  4. Como medidas provisionales que no protegen del todo: session.upload_progress.enabled=0 y reinicio de los workers, un post_max_size bajo (8M, o 32M si necesitas subidas) y límites de memoria a nivel de contenedor.
  5. Revisa los logs de acceso desde el 17 de octubre y, si sospechas que se leyó la memoria de algún proceso, rota contraseñas, tokens y claves de API.

El proyecto PHP lo dice con claridad: ninguna configuración mitiga del todo estos fallos y actualizar es la única defensa duradera. Para que te ayudemos a fijar prioridades y a parchear rápido, consulta nuestros servicios de ciberseguridad.

Fuentes: watchTowr, FAQ de PHP2Shell; BleepingComputer; Qualys; JFrog; Huntress.

← ← Todas las noticias