>_toolkitbox

~/ / Artículos de IA / La IA ayudó a encontrar PHP2Shell: las vulnerabilidades críticas de PHP de octubre de 2026

La IA ayudó a encontrar PHP2Shell: las vulnerabilidades críticas de PHP de octubre de 2026

Según medios de comunicación, modelos de IA ayudaron a investigadores a encontrar dos vulnerabilidades críticas en el propio PHP, CVE-2026-109618 y CVE-2026-109619, que pueden permitir la ejecución remota de código sin autenticación. PHP publicó versiones corregidas el 21 de octubre de 2026. Este artículo resume lo que dicen los anuncios oficiales y las noticias sobre los fallos y sobre cómo participó la IA, y te permite comprobar si el PHP que usas incluye la corrección.

Contrastado con los anuncios oficiales el 2026-10-24. Esta página no es un aviso oficial y los detalles pueden cambiar, así que sigue las fuentes que aparecen al final.

Qué hacer primero

  1. Actualiza PHP a una versión corregida (8.5.12, 8.4.27, 8.3.36 u 8.2.35) o al paquete corregido de tu distribución de Linux. PHP dice que no existen mitigaciones completas y que actualizar es la única opción segura.
  2. Después de actualizar, reinicia PHP-FPM, Apache y cualquier proceso de PHP de larga duración para que carguen el código corregido. Un servicio que arrancó antes de la actualización sigue ejecutando el código antiguo.
  3. Si PHP procede de un paquete de la distribución, comprueba la versión completa del paquete, incluida la parte posterior al primer guion. Las distribuciones pueden incluir la corrección sin cambiar la primera parte del número.
  4. Si no puedes actualizar de inmediato, consulta las mitigaciones más abajo. PHP dice que reducen la exposición a vías de ataque concretas, pero no hacen que una instalación sea segura.

Qué ha pasado

El 21 de octubre de 2026 PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen dos vulnerabilidades críticas, ambas con una puntuación CVSS v4.0 de 9.2.

CVE-2026-109618, llamada RCE via OOM corruption: la gestión de la falta de memoria puede interrumpir PHP mientras los datos internos de la solicitud están solo parcialmente inicializados, y la limpieza de la solicitud puede entonces tratar los datos no válidos como válidos.

CVE-2026-109619, llamada RCE via stale global state: el estado interno propio de la solicitud puede sobrevivir después de que se haya liberado la memoria que lo respalda, y una solicitud posterior atendida por el mismo proceso de trabajo puede usar ese estado obsoleto.

  • CVE-2026-109618 · CVSS 4.0 9.2
  • CVE-2026-109619 · CVSS 4.0 9.2

Cómo intervino la IA

Según The Next Web, la empresa de seguridad Calif encontró el primer error en agosto con la ayuda de un modelo de OpenAI, durante una auditoría del código fuente de PHP financiada por OpenAI. Wiz dijo que encontró los fallos de forma independiente, semanas después, usando herramientas de IA, entre ellas los modelos Gemini de Google.

El sitio php2shell.com atribuye la investigación a Wiz Research, OpenAI Codex Security y Calif. Calif dijo que usó modelos de disponibilidad general y que conocer la historia de PHP importó más que el modelo.

El mismo artículo informa de que Cloudflare activó reglas de WAF para sus clientes unas nueve horas antes de la divulgación, y de que después circuló en línea un exploit de prueba de concepto. El sitio php2shell.com dice que una regla de WAF o CDN no debe considerarse un sustituto de actualizar PHP.

Cronología

  1. PHP anuncia una próxima versión de seguridad crítica, prevista para el 21 de octubre a las 14:00 UTC.
  2. Se publican PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 junto con un aviso de seguridad, y Ubuntu publica USN-8948-1.
  3. PHP publica un aviso informativo sobre session.upload_progress.enabled, relativo a otro vector, poco probable, registrado como CVE-2026-115560.

Quién está afectado

PHP dice que todas las instalaciones de PHP que atienden solicitudes web están en riesgo, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Considera que el riesgo es mayor con mod_php, donde una solicitud sin autenticar puede desencadenar el ataque antes de que se ejecute ningún código de la aplicación.

Los avisos de GitHub indican como afectadas las versiones anteriores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12. El sitio php2shell.com, que figura como gestionado por Wiz, dice que las versiones afectadas se remontan hasta PHP 5.4.

PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. Algunas distribuciones y proveedores de LTS ofrecen correcciones portadas a versiones anteriores (backports), y PHP proporcionó backports mínimos del código fuente para PHP 7.4, 8.0 y 8.1 para quienes compilan desde el código fuente.

Versiones corregidas

Una versión igual o posterior a la versión corregida de su rama incluye la corrección. Un paquete de distribución se considera corregido según la versión del paquete, así que usa la segunda tabla para Ubuntu y Debian.

Versiones propias de PHP

RamaPrimera versión corregida
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

Paquetes de Ubuntu y Debian

DistribuciónPaqueteVersión corregida del paqueteAviso
Ubuntu 26.10php8.58.5.9-0ubuntu2.1USN-8948-1
Ubuntu 26.04 LTSphp8.58.5.4-0ubuntu1.5USN-8948-1
Ubuntu 24.04 LTSphp8.38.3.6-0ubuntu0.24.04.13USN-8948-1
Ubuntu 22.04 LTSphp8.18.1.2-1ubuntu2.28USN-8948-1
Debian 12 (bookworm)php8.28.2.35-1~deb12u1DLA-4848-1
Debian 13 (trixie)php8.48.4.27-1~deb13u1DSA-6574-1

Las tablas muestran solo lo que indican los avisos oficiales. Para otras distribuciones, consulta el aviso de seguridad de tu proveedor.

Comprueba tu PHP

Elige de dónde procede tu PHP, pega el texto de la versión y la herramienta lo compara con las versiones corregidas de arriba. Solo juzga el texto que pegas. No puede ver qué versión se está ejecutando, así que confirma también que el servicio se reinició después de la actualización.

Comandos que muestran la versión

  • php -v
  • dpkg -l 'php*' | grep ^ii
  • apt-cache policy php8.3-fpm | grep Installed

Todo se ejecuta en tu navegador. El texto que pegas no se sube.

Si no puedes actualizar de inmediato

PHP enumera estas medidas. Dice que reducen la exposición a vías de ataque concretas, pero no hacen que una instalación sea segura, y que solo una actualización es una solución completa.

CVE-2026-109618

  • Establece memory_limit=-1, preferiblemente de modo que las aplicaciones no puedan sobrescribirlo, por ejemplo con php_admin_value en el pool de FPM o en la configuración de Apache. Un fallo de asignación de memoria subyacente aún puede alcanzar la ruta vulnerable.
  • Establece un post_max_size bajo: 8M para las aplicaciones que no necesitan subir archivos y 32M si se necesitan subidas. Mantén upload_max_filesize por debajo de post_max_size.
  • Aplica límites en el servidor web o en el proxy para el tamaño de la solicitud decodificada, el número de campos de entrada, el número de partes multipart, el número de cabeceras y la profundidad de anidamiento.
  • Usa un límite de contenedor o de cgroup como frontera de disponibilidad. No uses RLIMIT_AS ni RLIMIT_DATA, porque pueden provocar el fallo de asignación de memoria vulnerable.

CVE-2026-109619

  • Establece session.upload_progress.enabled=0 en php.ini, en un pool de FPM o en la configuración del servidor, y reinicia todos los procesos de trabajo. No confíes en ini_set() ni en un archivo .user.ini de FPM.
  • En PHP 8.5, establece fatal_error_backtraces=0 y reinicia todos los procesos de trabajo.
  • Elimina los ajustes no válidos u obsoletos aplicados por solicitud que emiten diagnósticos antes de la inicialización. Ocultar los diagnósticos no sirve.
  • Corrige los errores fatales y los tiempos de espera de ejecución que un atacante pueda provocar.

El aviso informativo del 23 de octubre

PHP sugiere establecer session.upload_progress.enabled=0 hasta la próxima versión regular de corrección de errores, para protegerse por completo frente a otro vector de ejecución remota de código, poco probable. Si ya lo aplicaste a partir del aviso del 21 de octubre, mantenlo.

PHP dice que el problema solo puede darse con una combinación inusual: una aplicación establece en su configuración session.serialize_handler como php_binary o php_serialize, lo cambia a php en tiempo de ejecución con ini_set() antes de session_start(), y el seguimiento de progreso de subida de sesión sigue activado. PHP publicará un aviso completo sobre CVE-2026-115560 con la próxima versión.

Lo que esta página no hace

  • No es un aviso oficial y no ofrece detalles de explotación. Los anuncios y avisos oficiales que figuran abajo son la referencia.
  • No puede decir si un sistema ha sido atacado. El sitio php2shell.com señala que la ausencia de actividad sospechosa no demuestra que un sistema no esté afectado.
  • La exposición depende de la versión, de la configuración y de cada vulnerabilidad. Las mitigaciones pueden afectar al funcionamiento de una aplicación.

Fuentes