PHP e inteligencia artificial: qué ha pasado con PHP2Shell
La investigación asistida por IA ha vuelto a poner PHP en las noticias. El 21 de octubre se publicaron correcciones para dos vulnerabilidades críticas del lenguaje; el día 23 llegó un aviso adicional. Repasamos los hechos, el papel de los investigadores y las consecuencias para los equipos tecnológicos.
Qué sabemos
- Los fallos están en el motor de PHP y pueden permitir ejecución remota de código sin autenticación bajo determinadas condiciones.
- Los investigadores emplearon modelos de IA; el equipo de PHP dirigió las correcciones y la publicación.
- Actualizar el CMS o añadir un cortafuegos no demuestra que el motor PHP esté corregido.
- La existencia de una vulnerabilidad no confirma que una web concreta haya sufrido un ataque.
Contenido de esta noticia
Qué es PHP2Shell y por qué PHP vuelve a ser noticia
PHP es un lenguaje utilizado para generar páginas y ejecutar lógica en servidores web. En este caso, PHP2Shell es el nombre con el que se ha difundido una investigación sobre problemas de seguridad de memoria en su motor.
Los avisos oficiales identifican CVE-2026-109618, relacionado con estados internos incompletos tras agotar memoria, y CVE-2026-109619, relacionado con referencias a memoria de una petición anterior que ya se había liberado. Ambos avisos tienen una puntuación CVSS v4 de 9,2 sobre 10. La posibilidad de explotación depende del entorno y de las condiciones descritas por sus mantenedores. Fuentes: aviso sobre corrupción por falta de memoria y aviso sobre estado global obsoleto.
El alcance obliga a revisar también la infraestructura que ejecuta una aplicación. Una web puede tener su propio código actualizado y conservar un motor PHP vulnerable. Comprobar el estado de una instalación exige información de ese servidor; esta noticia no es una auditoría de las webs de los lectores.
Las fechas que ayudan a entender lo ocurrido
- 2024: según la PHP Foundation, ya se habían detectado indicios del problema de falta de memoria durante trabajos posteriores a una auditoría externa. La corrección se complicó por decisiones de compatibilidad y recursos.
- 11 de agosto de 2026: la Fundación sitúa en esta fecha el informe de Calif que demostraba ejecución remota de código.
- 21 de octubre: se publicaron las actualizaciones de seguridad. La divulgación se había adelantado un día tras circular información sobre los fallos.
- 23 de octubre: PHP añadió un aviso sobre una combinación poco habitual de configuración y código relacionada con el progreso de subida de archivos.
La cronología de la investigación y las dificultades de coordinación están explicadas en el balance de la PHP Foundation del 21 de octubre. El seguimiento posterior figura en el archivo oficial de noticias de PHP.
Qué papel tuvieron OpenAI, Wiz y los modelos de IA
OpenAI atribuye a Calif la identificación de un fallo crítico utilizando GPT-5.6 Sol dentro de Patch the Planet. También señala el descubrimiento independiente de vulnerabilidades por Wiz y reconoce que los mantenedores de PHP dirigieron las correcciones. Así lo describe en su explicación de la respuesta coordinada.
Por su parte, Wiz declara haber empleado Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol durante la investigación. Su informe describe cómo los modelos facilitaron el análisis, las pruebas y la adaptación de demostraciones a distintos entornos. Es la versión del equipo investigador, recogida en su informe técnico de PHP2Shell.
Estas fuentes permiten hablar de investigación asistida por IA. No demuestran que un modelo descubriese, corrigiese y desplegase por sí solo toda la solución. La PHP Foundation insiste en que las decisiones y los parches pasan por personas. El conocimiento del motor y la revisión del comportamiento siguen formando parte del trabajo.
La relación con big tech
OpenAI y los modelos de Google aparecen en la investigación; proveedores de infraestructura también participaron en la respuesta. Cloudflare, por ejemplo, publicó su explicación de las protecciones WAF desplegadas. Es una muestra de cómo un problema en software abierto puede requerir coordinación entre mantenedores, laboratorios de IA y operadores de servicios.
Qué versiones incluyen las correcciones y qué cambió el día 23
Las publicaciones del 21 de octubre incluyen las siguientes versiones corregidas. Son una referencia de esa fecha; hay que comprobar los avisos posteriores y los paquetes del proveedor antes de decidir una actualización.
- Rama 8.2: PHP 8.2.35.
- Rama 8.3: PHP 8.3.36.
- Rama 8.4: PHP 8.4.27.
- Rama 8.5: PHP 8.5.12.
El aviso oficial del 23 de octubre añade un matiz: una combinación inusual de cambios del serializador de sesión en ejecución y progreso de subida activado requiere atención adicional. PHP aconseja desactivar session.upload_progress.enabled hasta la siguiente corrección regular, con las condiciones detalladas en el aviso. No debe interpretarse como que todos los entornos actualizados se encuentren en esa situación.
Para una revisión operativa, el NCSC británico recomienda localizar las instalaciones PHP, priorizar las expuestas a internet, actualizar y seguir los avisos de los proveedores. Si no se puede actualizar, remite a las mitigaciones oficiales y a valorar la retirada temporal del servicio cuando tampoco puedan aplicarse.
En un hosting gestionado, pide confirmación del paquete corregido y de qué servicios lo están ejecutando. Un proveedor puede incorporar el parche mediante un backport, conservando parte de la numeración anterior. Esa confirmación es más útil que deducir el estado de seguridad por el aspecto de una página.
Qué implica para quienes desarrollan y contratan talento tecnológico
Análisis de TaleCon: este caso permite plantear una conversación concreta sobre cómo trabaja un equipo cuando cambia el riesgo de una dependencia. No aporta datos de nuevas vacantes, salarios ni demanda laboral; muestra tareas que una organización necesita asignar.
Desarrollo puede comprobar compatibilidad y pruebas. Sistemas debe conocer los servicios y las versiones en ejecución. Seguridad puede coordinar la evaluación de exposición y los indicios de incidente. La persona responsable del producto debe ordenar la intervención y comunicar su impacto. En equipos pequeños, una misma persona puede asumir varias responsabilidades.
Si preparas una entrevista técnica, puedes preguntar: «¿Cómo comprobarías que una actualización de seguridad está realmente en producción?» o «¿Qué evidencias pedirías al proveedor de hosting?». Busca una explicación del proceso y sus comprobaciones, evitando pedir al candidato que memorice identificadores de vulnerabilidades.
Para desarrollar ese enfoque, consulta nuestra guía sobre el proceso de selección de personal tecnológico. Si estás buscando un puesto, explica en tu perfil qué responsabilidad asumiste en mantenimiento, pruebas o respuesta a incidencias, sin revelar información privada de tus proyectos.
Primer artículo de Tecnología y big tech
Con esta noticia abrimos una línea de seguimiento de software, inteligencia artificial, ciberseguridad e infraestructura. Las siguientes entregas podrán analizar agentes de programación, mantenimiento de código abierto y cambios en los equipos técnicos. Cada noticia necesitará sus propias fuentes y fecha de revisión.
Puedes seguir los artículos disponibles en Tecnología y big tech. Este texto reúne información comprobada hasta el 26 de octubre de 2026. Las novedades posteriores deberán contrastarse con los avisos oficiales antes de incorporarlas.
Fuentes y criterio editorial
Se han contrastado los avisos del proyecto PHP y de su Fundación con los informes públicos de OpenAI, Wiz, Cloudflare y NCSC enlazados en cada sección. Los relatos de los participantes se atribuyen a sus autores. No se han realizado pruebas de explotación ni auditorías de sistemas de terceros.
Conecta la actualidad con tu próximo paso profesional.
Define las responsabilidades técnicas de tu vacante o completa tu experiencia y preferencias como candidato.