Cognition lanza un plugin para agentes que cierra fallos en PHP y Node.js con CVSS 9,2

El 21 de octubre de 2026 se publicaron actualizaciones de seguridad urgentes para PHP y Node.js, y en ambos casos se trata de ejecución remota de código. En PHP se han corregido dos vulnerabilidades, conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619), con una puntuación CVSS v4 de 9,2 y que no requieren autenticación. En Node.js se han corregido 10 CVE, cuatro de ellas con calificación High. Cognition, la compañía detrás del agente Devin, afirma que las vulnerabilidades ya se explotan de forma automatizada y ha publicado en abierto un plugin que convierte al agente de programación en el ejecutor de todo el proceso de parcheo.

Qué es exactamente lo que falla

PHP2Shell consta de dos errores. El primero, CVE-2026-109618, es una corrupción de memoria que se produce tras quedarse sin memoria RAM. El segundo, CVE-2026-109619, es un estado global obsoleto que una petición deja a la siguiente. Está expuesta cualquier configuración web de PHP: PHP-FPM, php-cgi, FrankenPHP, LiteSpeed y Apache mod_php, que presenta el mayor riesgo.

En Node.js el problema principal es CVE-2026-111497: una escritura fuera de los límites del búfer en el decodificador de Brotli que puede derivar en ejecución de código. Conviene parchear primero los servicios expuestos a internet que descomprimen Brotli: clientes HTTP, servidores y proxies. Otras tres vulnerabilidades High (CVE-2026-105482, CVE-2026-105483, CVE-2026-106069) están relacionadas con TLS y con la verificación de nombres de host. Son peligrosas para los servicios que se conectan a direcciones definidas por el usuario.

• PHP: correcciones en 8.2.35, 8.3.36, 8.4.27 y 8.5.12; para 7.4, 8.0 y 8.1 solo se han publicado backports en el código fuente
• Node.js: 22.23.4, 24.22.1 y 26.12.1
• Node.js 20 y anteriores ya no cuentan con soporte, no habrá parches y la vulnerabilidad persiste; es necesario migrar a 22+
• La versión de Node.js actualiza OpenSSL, c-ares, Undici, SQLite y el almacén de CA: el certificado raíz de eMudhra se ha eliminado de él

Por qué «simplemente actualizar» no funciona

PHP y Node.js se esconden en imágenes de contenedores, paquetes del sistema operativo, pipelines de CI, valores de Helm, Terraform y runtimes de Lambda, y además en decenas de repositorios. Cada despliegue hay que localizarlo, actualizarlo, verificarlo y publicarlo.

Hay trampas. Debian y Ubuntu hacen backports de las correcciones sin cambiar la versión upstream: en Ubuntu 24.04 el paquete corregido se llama 8.3.6-0ubuntu0.24.04.13, y `php -v` seguirá mostrando 8.3.6. Hay que comprobar el boletín de seguridad del proveedor o el changelog del paquete. Las imágenes fijadas por digest requieren un digest nuevo, y las etiquetas flotantes como php:8.3-fpm hay que reconstruirlas con una imagen base nueva. Modificar require.php o config.platform.php en Composer no arregla nada: esos ajustes no determinan el runtime en producción.

Si no se puede actualizar de inmediato, PHP propone medidas temporales. Entre ellas, session.upload_progress.enabled=0 con reinicio de todos los workers y la limitación del tamaño del cuerpo de la petición y del número de partes multipart en el proxy. No se deben usar RLIMIT_AS ni RLIMIT_DATA: son ellos mismos los que activan la ruta de código vulnerable.

Cómo funciona el plugin

El plugin Vulnerability Fixes se ha construido a partir del proceso con el que Cognition parcheó su propia infraestructura. Primero, el agente hace un inventario de solo lectura: Dockerfile, imágenes base, paquetes, compilaciones desde el código fuente, setup-php, setup-node, .nvmrc, Terraform, Packer, Ansible, Chef y Puppet. Después muestra una tabla y espera a que usted indique en qué repositorios autoriza actuar. Todo lo que entrañe más riesgo que un cambio de versión de parche (una actualización minor o major, un cambio de sistema operativo base, posibles cambios en el código) lo señala de antemano.

A continuación, el agente contrasta etiquetas, digests, versiones de paquetes y sumas de verificación con los registros oficiales, ejecuta las pruebas sobre la versión actual como línea base, las repite en la nueva imagen de producción y compara los runtimes: extensiones, ajustes ini, versiones de OpenSSL e ICU. El resultado es un PR por repositorio con las versiones anterior y posterior, los resultados de las pruebas, una etiqueta de riesgo y un plan de despliegue y de reversión.

El plugin está disponible en Devin Marketplace y también como Agent Skills estándar para Claude Code, Codex, Cursor, Factory Droid, GitHub Copilot, Gemini CLI y OpenCode: `npx skills add CognitionAI/devin-vuln-fixes`. Las skills se ejecutan con todos los permisos de su agente, por lo que Cognition pide leerlas antes de lanzarlas. Para compilar y probar se necesitan git, shell, Docker y acceso a su registro de imágenes.

Por dónde empezar hoy

Cognition aconseja, ante todo, desconectar las aplicaciones PHP públicas mientras dure el parcheo: la explotación está automatizada. Después:

• comprobar las versiones según el boletín de la distribución, no con `php -v`
• reconstruir las imágenes con etiquetas flotantes y sustituir el digest en las fijadas
• incluir Node 20 y anteriores en un plan de migración a 22+
• desplegar los PR arriesgados primero en staging o canary
• tras el merge, volver a desplegar cada servicio: la corrección solo surte efecto en la nueva compilación

El agente solo verifica lo que cubren las pruebas, así que, para aplicaciones con poca cobertura, el PR recomienda expresamente pasar por staging. Los runtimes gestionados los corrige el proveedor, y las soluciones de hardware de fabricantes y las aplicaciones Electron con PHP o Node integrados el agente se limita a marcarlas para que las actualice el fabricante.

En Cognition creen que casos como este se volverán la norma: la velocidad de descubrimiento de vulnerabilidades crece y los atacantes automatizan las cadenas de explotación con ayuda de la IA. La compañía recomienda escanear de forma continua la superficie de ataque externa, trasladar las aplicaciones internas tras una VPN o ZTNA, migrar a runtimes y contenedores recientes y abandonar los ciclos de parcheo de 30 días. El director de seguridad, Alex Stamos, ofrecerá un webinar el 26 de octubre a las 10:30 (hora del Pacífico).