Una vulnerabilidad Paperclip catalogada como crítica ha puesto el foco en la seguridad de las plataformas que gestionan agentes de IA. Según un informe técnico de Oasis Security, un fallo de autorización podía permitir a atacantes remotos obtener ejecución arbitraria de código aprovechando los permisos con los que corre el servidor.
Paperclip es una plataforma orientada a la gestión de agentes de IA, pensada para operar flujos autónomos a escala. Entre sus funciones está la importación de organizaciones mediante bundles portables y archivos YAML que definen agentes y los comandos que deberían ejecutar. En ese contexto, la cadena de ataque descrita por los investigadores muestra cómo una simple ausencia de controles adecuados puede escalar hasta un impacto severo.
Qué es el fallo y por qué es crítico
El defecto se rastrea como CVE-2026-41679 y tiene una puntuación CVSS de 10. El problema afectaba instancias accesibles en red de Paperclip que estaban configuradas en modo de autenticación por defecto.
El punto clave es que existía un salto de controles de autorización. En lugar de limitar acciones sensibles a usuarios debidamente verificados o administradores de la instancia, el flujo permitía que un atacante completara pasos que normalmente requieren validaciones adicionales.
La cadena de ataque: de cuenta “autoaprobada” a acceso a la CLI
De acuerdo con el informe, el atacante podía crear una cuenta sin verificación de correo electrónico. Lo importante no es solo la creación de la cuenta, sino que luego podía iniciar sesión de inmediato y continuar por un flujo de autorización de la interfaz de línea de comandos (CLI).
El proceso descrito se apoya en un reto (challenge) y su aprobación. Una vez dentro de la sesión, el atacante podía:
- Crear el reto de autorización para la CLI
- Aprobar el reto por sí mismo
- Activar credenciales de API persistentes
Con esa aprobación, el atacante obtenía un token de API asociado a la cuenta comprometida. Ese token le otorgaba acceso a nivel de “board”, lo que a su vez abría la puerta a rutas de importación de empresas.
Por qué el camino de importación era el eslabón débil
Oasis señala un matiz relevante: Paperclip restringía correctamente la creación directa de una nueva empresa a administradores de la instancia. Sin embargo, el camino alternativo para hacerlo mediante importación aplicaba un control distinto.
En la práctica, la ruta de importación solo exigía acceso a nivel de board, y no requería privilegios de administrador de la instancia. Esa diferencia permitió que el atacante, con las credenciales obtenidas en el flujo de CLI, llegara a las funciones necesarias para disparar el resto de la explotación.
Cómo se llegó a la ejecución de código
Una vez que el atacante tenía la vía de importación, podía usar un archivo de configuración especialmente preparado (mencionado como .paperclip.yaml) para manipular el comportamiento del sistema durante la importación.
Los investigadores indican que el contenido del archivo podía:
- Definir un agente controlado por el atacante
- Hacer que el agente utilizara un adaptador de ejecución a nivel de host
- Indicar un comando que el adaptador ejecutaría con el proceso del servidor de Paperclip
Cuando la explotación tenía éxito, el atacante conseguía las mismas capacidades del servicio que ejecuta Paperclip. Dependiendo de cómo estuviera desplegado, eso podría incluir acceso a datos de aplicación, repositorios de código, credenciales locales, secretos disponibles para los procesos del agente e incluso servicios internos alcanzables desde el host.
Impacto adicional: dos fallos más corregidos
La corrección de la vulnerabilidad Paperclip no se limitó al bypass de autorización. Oasis también reportó y describió otros dos problemas que se abordaron en el mismo contexto de remediación.
1) Falta de autorización en rutas de API
El primer fallo adicional era una ausencia de autorización en ciertas rutas de API. El efecto potencial era la divulgación de datos sensibles, al permitir que un actor no autorizado accediera a información que no debería ser accesible.
2) DNS rebinding en modo de desarrollo local
El segundo problema estaba relacionado con DNS rebinding en una debilidad de loopback. En modo de desarrollo local, Paperclip se vinculaba a 127.0.0.1 y confiaba en todas las solicitudes que llegaran a esa dirección como si provinieran de software confiable.
El riesgo aumenta cuando un desarrollador abre en el navegador una web controlada por un atacante. En ese escenario, el código JavaScript de esa página podía sortear las protecciones de mismo origen (same-origin) y obtener acceso a la API local de Paperclip. A través de una operación de importación, el atacante podía forzar la ejecución de un comando en el equipo del desarrollador.
Por qué este caso importa para la seguridad de agentes
Oasis remarca un punto de fondo: los agentes de IA se están convirtiendo en una nueva clase de identidad empresarial. A diferencia de los flujos tradicionales, los “agénticos workflows” suelen estar distribuidos: un usuario delega la intención a un agente, el agente invoca otras herramientas o agentes y cada paso puede seleccionar credenciales distintas.
El resultado práctico es que, cuando una acción llega al sistema objetivo, los registros a menudo muestran solo la credencial final. Esto puede dificultar atribuciones claras: no se ve con facilidad el usuario inicial, el agente responsable o la tarea exacta que se pretendía ejecutar.
En ese tipo de arquitectura, un fallo de autorización o una vía de importación manipulable pueden convertirse en una escalada rápida. Por ello, la remediación no solo es “arreglar un bug”, sino asegurar que los controles se apliquen consistentemente a cada flujo relevante.
Qué hizo Paperclip para corregir el problema
Según la información disponible, Paperclip aplicó controles de autorización adicionales en los flujos de vista previa de importación y en la ejecución de la importación. Además, se reforzó el alcance (“scoping”) de las empresas para impedir que rutas equivalentes otorgaran acceso con menos requisitos que el esperado.
Con estos ajustes, el objetivo es cortar la cadena: evitar que una sesión recién creada pueda entrar en el flujo de autorización de la CLI, impedir que el reto se apruebe sin verificación adecuada y bloquear que la importación pueda usar configuraciones maliciosas para provocar ejecución con permisos elevados.
Recomendaciones para equipos que usan Paperclip
Si tu organización utiliza Paperclip, este incidente es una señal para revisar la seguridad de extremo a extremo, especialmente en componentes que gestionan importaciones y ejecutan acciones mediadas por CLI.
- Actualiza cuanto antes a la versión que aplique los parches mencionados por el proveedor.
- Verifica configuraciones de autenticación y evita depender de configuraciones por defecto en entornos expuestos.
- Controla accesos a flujos de importación y revisa quién puede iniciar acciones que terminen ejecutando comandos o adaptadores.
- Cuida el modo de desarrollo: limita el acceso local y evita escenarios donde un sitio no confiable pueda desencadenar interacción con APIs locales.
Conclusión
La vulnerabilidad Paperclip (CVE-2026-41679) demuestra cómo una ausencia de comprobaciones de autorización puede convertir una cuenta sin verificación en una vía para alcanzar credenciales persistentes y, finalmente, ejecución de código con permisos del servidor. La corrección aplicada por Paperclip aborda tanto el bypass en el flujo de importación como otros problemas vinculados a autorización y a riesgos de DNS rebinding.
Para organizaciones que gestionan agentes de IA, este caso refuerza la necesidad de controles consistentes, trazabilidad y límites estrictos en rutas que conectan identidades, credenciales y operaciones capaces de ejecutar comandos.
Fuente: https://www.securityweek.com/critical-paperclip-flaw-allowed-admin-access-code-execution/
