Las vulnerabilidades en Paperclip AI descritas por investigadores de seguridad muestran cómo un detalle de diseño puede convertir la configuración de agentes en “comportamiento ejecutable”. En la práctica, ciertos caminos de importación y algunas rutas de API pueden terminar en ejecución de comandos sobre un servidor o incluso en el equipo de un desarrollador.
Según el análisis público, hay fallos con impacto severo y otros que afectan la exposición de información. Lo importante para equipos y operadores es que el riesgo depende mucho del modo de despliegue y de cómo se maneja el registro y la confianza local.
Qué es Paperclip y por qué la configuración importa
Paperclip es un proyecto de código abierto descrito como un “control plane” para equipos que coordinan agentes de inteligencia artificial. En ese modelo, una parte del flujo consiste en importar agentes y luego iniciarlos.
El punto clave del informe técnico de Oasis Security es que la configuración del agente puede llegar a convertirse en ejecución real. Es decir: si un atacante logra introducir una configuración maliciosa que active un adaptador de proceso, el sistema termina lanzando un comando como hijo del proceso del servidor.
Fallo en el servidor: ejecución de comandos (CVE-2026-41679)
El camino con mayor severidad se registró como CVE-2026-41679, con una puntuación CVSS 10.0. Este escenario se centra en despliegues accesibles desde la red que funcionan en modo autenticado y usan una configuración de registro vulnerable.
De acuerdo con la información disponible, el ataque no requiere una cuenta existente previa ni que la víctima interactúe, siempre que el despliegue cumpla las condiciones indicadas. En resumen, el atacante puede registrarse por el flujo abierto por defecto, acceder a la autorización de la CLI e incluso aprobar un desafío pendiente.
Con esa aprobación, el atacante obtiene credenciales durables de una API a nivel de “board” (según la descripción del informe) sin una decisión explícita por parte de un administrador de instancia. Esa autorización luego permite crear una empresa mediante un mecanismo de importación.
La cadena del ataque, paso a paso
- El atacante se registra (sin invitación ni verificación estricta de email, según se describe) y entra a la CLI.
- Genera un desafío de CLI pendiente y lo aprueba.
- Usa la ruta de importación para definir un nuevo “board/company” y un agente con un adaptador de proceso.
- Incluye el comando que el agente ejecutará.
- Al iniciar el agente, el sistema pasa los controles habituales de “wakeup” y termina ejecutando el comando con los privilegios del proceso del servidor.
El impacto práctico depende de la cuenta de servicio y del host. El informe menciona que podría incluir acceso a datos de aplicación, repositorios, credenciales locales, secretos disponibles para procesos del agente y servicios internos a los que el servidor pueda conectarse.
Reparación del fallo del servidor: qué cambió en v2026.416.0
Para CVE-2026-41679, la corrección indicada se encuentra en Paperclip v2026.416.0 (o versiones posteriores). El cambio descrito consiste en exigir permisos de instance-administrator cuando la importación apunta a una nueva empresa, y permisos de company access cuando la importación apunta a una empresa existente.
Además, se afirma que la misma lógica protege tanto la vista previa como la ejecución del flujo de importación. El registro abierto puede seguir existiendo, pero un usuario recién registrado ya no debería poder tratar la ruta de importación hacia “nueva empresa” como si fuera una acción de administrador de instancia.
También se menciona que Rapid7 publicó un módulo público de Metasploit para automatizar la cadena de seis solicitudes asociada a este CVE, y que CISA/ NVD clasifica el aprovechamiento como prueba de concepto.
Vulnerabilidad en local_trusted: el navegador llega a localhost
La segunda vía crítica se identificó como GHSA-x8hx-rhr2-9rf7, con CVSS 9.6. A diferencia del caso anterior, este problema apunta a un modelo de despliegue distinto: cuando Paperclip corre con su configuración por defecto local_trusted.
En ese modo, el servicio se vincula a la interfaz de loopback (127.0.0.1) y, históricamente, se interpretó que cualquier solicitud que llegara al servicio debía considerarse de autoridad administrativa implícita. Esa comodidad para desarrollo local reduce fricción, pero también introduce una superficie de riesgo: la ubicación de red acaba funcionando como “identidad”.
Cómo funciona el ataque con DNS rebinding
El informe describe un ataque basado en DNS rebinding. Un hostname controlado por el atacante se resuelve inicialmente hacia el servidor del atacante y luego, en solicitudes posteriores, hacia 127.0.0.1. El navegador mantiene la idea de “mismo origen” y las peticiones posteriores acaban alcanzando el servicio local de Paperclip.
Cuando las solicitudes alcanzan Paperclip, el sistema acepta el hostname del encabezado Host. A partir de ahí, la página puede llamar a la API de importación, instalar una empresa con un agente basado en proceso y activar su endpoint de “wakeup”. Como el modo local asigna autoridad administrativa a esas solicitudes, se ejecuta el comando con los privilegios del desarrollador.
Se indica que el proof of concept fue verificado en macOS con Firefox, por lo que el registro público no necesariamente demuestra el mismo resultado en todos los sistemas y navegadores.
El arreglo: validación de hostname antes de asignar identidad
La corrección directa mencionada es una validación de hostname. Con Paperclip v2026.416.0 se habilita la protección de “private-hostname guard” para despliegues privados que corren tanto en local_trusted como en modo autenticado.
Según el texto, el guard se ejecuta antes del middleware que asigna identidad a la petición. Así, si una solicitud intenta “rebindear” con un hostname no aprobado, se rechaza antes de que llegue a rutas de API donde podría afectar la lógica de autorización.
Rutas de API sin las comprobaciones esperadas (GHSA-xfqj-r5qw-8g4j)
Más allá de la ejecución de comandos, existe una tercera advertencia: GHSA-xfqj-r5qw-8g4j con CVSS 8.3. Aquí el problema se centra en varias rutas de API que, en modo autenticado, no siempre rechazan adecuadamente solicitudes no autenticadas o de acceso entre empresas.
Uno de los ejemplos citados es que, con un identificador válido de “heartbeat-run”, un actor podría recuperar datos de issues asociados sin demostrar acceso a la compañía. En el texto se aclara que no era una enumeración abierta sin restricciones: el atacante aún necesita obtener o descubrir un run identifier válido.
Otras rutas devuelven documentación orientada a habilidades del lado del agente, incluyen rutas y convenciones de autenticación, o entregan información de estado y salud (modo de despliegue, versión, preparación de autenticación, estado de bootstrap, exposición y feature flags).
También se menciona que la ruta de desafío CLI sin autenticación forma parte de la cadena de generación de credenciales que termina habilitando el ataque de CVE-2026-41679.
La causa de fondo: “la comprobación llega tarde”
El análisis apunta a un diseño donde una solicitud puede continuar a través del middleware con identidad “no actor”. En ese escenario, cada ruta termina siendo responsable de recordar las aserciones necesarias para la operación. Cuando una ruta olvida aplicar la verificación correspondiente, aparecen huecos.
Como cambios, se describe que Paperclip añadió autenticación a rutas generales de skills, comprobaciones de acceso a la empresa en recuperación de “heartbeat issue”, control por alcance de invitación para onboarding y respuestas de salud reducidas para usuarios no autenticados.
Actualización recomendada y notas sobre versiones
Un punto operativo importante: el texto explica que Paperclip utiliza dos etiquetas de versión para el mismo código. Por un lado, la liberación de seguridad en GitHub se referencia como v2026.416.0. Por otro, los manifiestos del servidor y de la CLI dentro de ese tag reportan versión 0.3.1.
Esto ayuda a entender por qué algunas advertencias mencionan ambos identificadores. Además, se indica que el advisory asociado a DNS rebinding todavía no lista una versión parcheada en ese registro particular.
En la revisión del código etiquetado como v2026.416.0, se encontró que el guard de hostname está habilitado para despliegues privados en local_trusted, y que el mismo código también requiere permisos de instance-administrator para imports hacia nueva empresa, bloquea por completo adaptadores de proceso y HTTP en el camino de “agent-safe import” restringido.
Por lo tanto, la recomendación más segura para operadores es tomar v2026.416.0 o posterior como punto de actualización, y no depender de metadatos históricos antiguos en otras fuentes.
¿Hay evidencia de explotación en el mundo real?
Al momento de la revisión publicada (5 de agosto de 2026), no se reportó explotación en la naturaleza según las fuentes revisadas. Aun así, la existencia de módulos de automatización y la clasificación como prueba de concepto sugieren que el riesgo es real para despliegues expuestos.
Conclusión: revisa configuración, credenciales y confianza local
Las vulnerabilidades en Paperclip AI descritas no se limitan a “un bug aislado”. En conjunto, muestran cómo una combinación de importación de agentes, validaciones de autorización incompletas y supuestos sobre identidad de red puede terminar en ejecución de comandos.
Para reducir el riesgo, actualiza a v2026.416.0 o más reciente, revisa cómo está configurado el registro y el alcance de permisos para importaciones hacia nuevas empresas, y valida que la protección de hostname esté activa en despliegues privados, especialmente si usas local_trusted.
Fuente: https://thehackernews.com/2026/08/paperclip-ai-flaws-let-attackers-run.html
