Actualización al 22 de octubre de 2026. La historia de la IA y PHP2Shell no trata de una máquina que encontró un error y lo corrigió sola. Trata de investigadores, mantenedores y proveedores que utilizaron modelos avanzados para analizar fallas de memoria extremadamente complejas, convertirlas en evidencia verificable y coordinar una solución antes de divulgar los detalles.
Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 afectan al núcleo de PHP. Ambas recibieron una puntuación crítica de 9.2 en CVSS v4.0 y pueden permitir ejecución remota de código sin autenticación. Para comprender por qué son tan importantes, primero hay que mirar cómo PHP administra la memoria entre solicitudes web.
PHP no empieza desde cero en cada solicitud
Un sitio puede parecer una secuencia de páginas independientes, pero el proceso que ejecuta PHP suele atender muchas solicitudes durante su vida útil. Cada petición recibe memoria temporal; al terminar, esa memoria debe limpiarse y cualquier referencia interna debe restablecerse correctamente.
El problema aparece cuando una operación falla a mitad del proceso. Una referencia puede sobrevivir aunque la memoria a la que apuntaba ya haya sido liberada, o una estructura puede quedar parcialmente inicializada. Si PHP vuelve a confiar en esos datos, un atacante puede influir en el comportamiento del proceso.
Esto pertenece a la categoría de errores de seguridad de memoria. No es una contraseña débil ni una validación olvidada dentro de WordPress. Es una inconsistencia en la manera en que el motor maneja su estado interno cuando ocurre un error fatal.
CVE-2026-109618: corrupción durante el agotamiento de memoria
OOM significa agotamiento de memoria. PHP utiliza un mecanismo llamado longjmp() para abandonar el contexto actual cuando ya no puede asignar memoria. El aviso oficial explica que ciertas estructuras de una solicitud pueden ser accesibles antes de estar completamente inicializadas.
Si una asignación falla en ese momento, el flujo normal de limpieza queda interrumpido. Durante el cierre, PHP puede leer o tomar decisiones con información inválida. Los investigadores encontraron varias maneras de provocar esa condición mediante el procesamiento de solicitudes multipart, el formato utilizado habitualmente para formularios y cargas de archivos.
Conceptualmente, la secuencia es la siguiente:
- Llega una solicitud especialmente construida que obliga al proceso a consumir memoria.
- PHP encuentra un error fatal mientras prepara estructuras internas.
- El procesamiento se interrumpe antes de que esas estructuras queden consistentes.
- La fase de limpieza trata parte del estado inválido como si fuera legítimo.
- La corrupción resultante puede convertirse en lectura de memoria o ejecución de código.
La dificultad no estaba únicamente en causar un error. El verdadero reto era controlar qué ocupaba la memoria antes y después de la falla, reducir la incertidumbre sobre direcciones internas y adaptar la cadena a distintas versiones y configuraciones.
CVE-2026-109619: estado obsoleto entre solicitudes
La segunda vulnerabilidad es un caso de use after free, o uso después de liberar. PHP conserva distintos estados globales asociados con errores, sesiones, objetos y extensiones. Algunos campos pueden apuntar a memoria propiedad de una solicitud concreta.
Antes de destruir esa memoria, todas las referencias deben restablecerse. Sin embargo, un error fatal puede abandonar una operación antes de realizar la limpieza correspondiente. El trabajador continúa activo con un puntero que ya no representa información válida.
La explotación necesita dos papeles conceptuales. Una solicitud productora deja el estado obsoleto; otra solicitud, atendida posteriormente por el mismo trabajador, lo consume antes de que la inicialización normal pueda sustituirlo. Si el espacio liberado fue reutilizado con datos controlables, PHP puede interpretar esos bytes con un tipo o propósito equivocado.
De una referencia inválida a un impacto real
Wiz documentó cuatro manifestaciones técnicas agrupadas bajo las dos CVE: problemas con el deserializador del progreso de carga, exposición de memoria del proceso, referencias obsoletas en trazas de errores fatales y confusión de tipos relacionada con OPcache.
OPcache conserva código PHP compilado para acelerar las aplicaciones. Una interrupción en un punto delicado podía dejar diferencias entre el estado local de un proceso y la información compartida por varios trabajadores. Al reutilizar posiciones con otro tipo de objeto, PHP podía resolver metadatos antiguos como si todavía fueran válidos.
Los investigadores demostraron ejecución de código previa a la autenticación en despliegues de WordPress, Drupal y Joomla, además de exposición de memoria. Estas aplicaciones fueron objetivos representativos, no la causa. Wiz señala que incluso una aplicación mínima puede resultar afectada porque las primitivas vulnerables están en PHP.
La exposición de memoria merece atención propia. Un proceso puede contener contraseñas, tokens, claves de API, certificados o información de otras solicitudes. Por eso, impedir la ejecución remota no sería suficiente si una variante todavía permitiera recuperar datos sensibles.
¿Qué hizo realmente la inteligencia artificial?
OpenAI informó que Calif identificó una falla crítica utilizando GPT‑5.6 Sol dentro de la iniciativa Patch the Planet. Al mismo tiempo, Wiz descubrió y reportó independientemente ambas vulnerabilidades. Wiz indica que utilizó Wiz Atlas, Gemini 4 Argon y GPT‑5.6 Sol, con una contribución particularmente importante de Argon.
Los modelos ayudaron a razonar sobre grandes cantidades de código, formular hipótesis, analizar fallos, desarrollar pruebas controladas, adaptar la investigación a distintos diseños de memoria y buscar variantes. También participaron en la validación adversarial: intentar encontrar caminos que el parche inicial pudiera no cubrir.
Eso redujo un obstáculo que durante años protegió indirectamente a muchos sistemas: el enorme costo de convertir un error de memoria teórico en una cadena confiable. Según Wiz, los modelos permitieron desarrollar y adaptar demostraciones en horas donde antes se habría requerido un trabajo manual mucho más difícil de escalar.
La IA no reemplazó a los responsables humanos
Los hallazgos tuvieron que ser reproducidos, evaluados y comunicados de forma responsable. Los mantenedores de PHP dirigieron la corrección y la publicación de las versiones seguras. Investigadores y proveedores ayudaron a comprobar el parche, preparar detecciones, desarrollar mitigaciones y coordinar avisos para infraestructuras dependientes.
OpenAI describe un proceso de cinco etapas: validar y corregir la vulnerabilidad original; dar tiempo a organizaciones defensivas; coordinar con entidades gubernamentales; preparar actualizaciones en productos afectados; y publicar orientación cuando el parche estuviera disponible.
Esta colaboración importa porque publicar una prueba completa antes de que exista una corrección podría beneficiar primero a los atacantes. La divulgación coordinada busca abrir una ventana para los defensores sin ocultar indefinidamente un riesgo que los operadores necesitan conocer.
Una capacidad con doble uso
La misma aceleración puede ayudar a ambos lados. Un equipo defensivo puede encontrar fallas antiguas, probar un parche y proteger software abierto. Un atacante también puede utilizar modelos para comprender un cambio público, desarrollar herramientas ofensivas o adaptar una cadena a múltiples objetivos.
La lección no es detener la investigación con IA, sino elevar la capacidad defensiva al mismo ritmo. Los proyectos críticos necesitan mejores pruebas, aislamiento, lenguajes con seguridad de memoria cuando sean adecuados, respuesta coordinada y recursos para sus mantenedores.
También cambia una suposición histórica: una vulnerabilidad difícil de explotar ya no debe considerarse segura por su complejidad. Si los modelos reducen tiempo y especialización, las organizaciones deben corregir los errores demostrables antes de que una técnica sofisticada se convierta en una herramienta reproducible.
Qué cambia para propietarios y equipos técnicos
Para quien administra un sitio, la conclusión sigue siendo práctica: actualizar PHP a 8.2.35, 8.3.36, 8.4.27 o 8.5.12, o instalar un backport documentado por el proveedor. La historia técnica explica la urgencia, pero no sustituye el inventario, la corrección y la búsqueda de indicios.
Para los equipos de desarrollo, PHP2Shell recuerda que las capas inferiores también forman parte del riesgo. Mantener WordPress, plugins y código propio es necesario; vigilar el runtime, el sistema operativo, las imágenes base y las bibliotecas compartidas es igual de importante.
Para la industria, el caso anticipa una etapa distinta de la seguridad informática. La IA puede convertir años de conocimiento disperso en ciclos rápidos de hipótesis, prueba y corrección. El beneficio dependerá de mantener supervisión humana, controles sobre la investigación ofensiva y coordinación con quienes sostienen el software.
PHP2Shell es también una advertencia sobre el futuro
Estas fallas existieron durante más de una década. Lo nuevo no fue el error, sino la capacidad de comprenderlo, combinar sus efectos y comprobar su impacto con una velocidad antes poco realista.
PHP2Shell demuestra que la IA puede ofrecer a los defensores una ventaja decisiva, pero esa ventaja tiene fecha de caducidad. Corregir con rapidez, verificar el resultado y fortalecer la infraestructura son la manera de convertir un descubrimiento extraordinario en protección real.
Descubre más de Anivia Mx
Suscríbete para recibir las últimas entradas en tu correo electrónico.
