Una falla en el escaneo de seguridad de la herramienta permite que atacantes distribuyan payloads ocultos en directorios de caché de Python.
Highflame Ramparts, una herramienta de validación de seguridad para skill bundles de Python, contiene una vulnerabilidad catalogada como CVE-2026-120202 que permite a atacantes eludir completamente el escaneo de integridad. El problema afecta a las versiones 0.8.1 a 0.8.10 y reside en cómo el software maneja archivos compilados de Python (.pyc) ubicados en directorios de caché. La falla tiene severidad MEDIUM según la base de datos del NVD, pero su impacto real depende de cómo se use Ramparts en entornos de producción: si la herramienta es la única barrera de seguridad antes de ejecutar código de terceros, la clasificación subestima el riesgo.
Cómo dos funciones de escaneo ignoran el vector de ataque más obvio
La vulnerabilidad se origina en dos funciones específicas del código de Ramparts: collect_bundle_siblings y walk_bundle_subdir. Ambas están diseñadas para recorrer la estructura de archivos de un skill bundle y verificar la integridad de cada componente mediante hashes. Sin embargo, estas funciones saltan deliberadamente dos tipos de contenido: directorios anidados y archivos con extensión .pyc.
La lógica detrás de esta exclusión probablemente buscaba optimizar el escaneo al ignorar archivos temporales o generados automáticamente por el intérprete de Python. Pero esa decisión de diseño abre una ruta directa para inyectar código malicioso. Un atacante puede construir un skill bundle que incluya un archivo .pyc bajo la ruta scripts/__pycache__/, donde Python almacena por defecto el bytecode compilado. Ramparts ignora silenciosamente ese archivo durante el escaneo de seguridad, sin verificar su hash ni alertar sobre su presencia.
Cuando el skill se ejecuta, CPython (la implementación estándar de Python) carga y ejecuta el archivo .pyc sin cuestionarlo. El resultado es que código arbitrario del atacante se ejecuta en el contexto del sistema que confió en Ramparts para validar el bundle. No hay registro de la omisión, no hay advertencia al usuario, no hay segunda barrera.
Por qué los archivos .pyc son un vector subestimado en supply chain
Los archivos .pyc son bytecode precompilado que Python genera automáticamente para acelerar la carga de módulos. En un flujo normal de desarrollo, estos archivos se crean a partir del código fuente .py y se almacenan en directorios __pycache__. La mayoría de los sistemas de control de versiones los excluyen por defecto (vía .gitignore) porque se consideran artefactos derivados, no fuente primaria.
Esa percepción de «archivo temporal» es exactamente lo que hace peligrosa su inclusión en un bundle distribuido. Si un sistema de validación como Ramparts asume que los .pyc son irrelevantes para la seguridad, está ignorando que Python los ejecuta con la misma autoridad que el código fuente. Peor aún: un .pyc puede contener bytecode que no corresponde a ningún archivo .py visible en el bundle, lo que dificulta la auditoría manual.
En el contexto de supply chain de software, donde los bundles de terceros se integran en sistemas críticos sin revisión línea por línea, esta clase de bypass convierte a Ramparts en un falso positivo de seguridad: da la ilusión de validación sin proveer protección real contra el vector más simple de ataque.
Exposición en América Latina por dependencia de herramientas de automatización
Aunque no hay reportes públicos de explotación de CVE-2026-120202 en la región, el patrón de adopción de herramientas de automatización en sectores como fintech y e-commerce en Brasil, México y Argentina crea una superficie de ataque relevante. Empresas que integran skill bundles de Python en pipelines de CI/CD o en plataformas de extensibilidad (chatbots, RPA, integraciones de API) suelen confiar en herramientas de escaneo como Ramparts sin validación adicional.
El problema se agrava en equipos con recursos limitados de seguridad, donde la presencia de una herramienta de validación se interpreta como suficiente debido diligence. Si Ramparts está en la cadena de aprobación de código de terceros y nadie revisa manualmente los directorios __pycache__, un atacante con acceso a un repositorio de bundles (interno o de un proveedor comprometido) puede distribuir payloads sin disparar alarmas. La falta de telemetría sobre qué archivos fueron ignorados durante el escaneo impide incluso la detección post-mortem.
Qué versiones quedan expuestas y por qué el parche no es trivial
Las versiones afectadas van de 0.8.1 a 0.8.10, un rango que sugiere que la lógica de exclusión de .pyc estuvo presente durante al menos diez releases menores. Eso indica que no fue un bug introducido recientemente, sino una decisión de diseño que nadie cuestionó hasta que se reportó como vulnerabilidad. La corrección requiere modificar collect_bundle_siblings y walk_bundle_subdir para que incluyan archivos .pyc en el escaneo de integridad, pero eso plantea un problema de compatibilidad: bundles legítimos que incluyan .pyc generados automáticamente ahora fallarían la validación si sus hashes no están documentados.
La solución más robusta sería que Ramparts rechace por defecto cualquier bundle que contenga archivos .pyc, forzando a los desarrolladores a distribuir solo código fuente .py. Pero eso rompe flujos de trabajo existentes donde los .pyc se incluyen para optimizar el tiempo de carga en entornos de producción. El dilema entre seguridad y compatibilidad explica por qué la severidad se catalogó como MEDIUM: el impacto es alto solo si Ramparts es la única defensa, pero en teoría debería haber capas adicionales (sandboxing, revisión de código, firmas digitales del bundle completo).
Nuestro análisis
CVE-2026-120202 es un caso de manual sobre cómo las suposiciones de diseño se convierten en vulnerabilidades cuando el contexto de uso cambia. Ramparts fue construido asumiendo que los archivos .pyc son artefactos derivados sin valor de ataque, pero esa suposición solo es válida si el sistema que ejecuta el código verifica independientemente la integridad del bytecode. En un modelo de supply chain donde Ramparts es la barrera de entrada, esa suposición es falsa.
Lo que hace notable esta falla no es su complejidad técnica — es trivial de explotar — sino lo que revela sobre la brecha entre herramientas de seguridad y los flujos de trabajo reales de desarrollo. Si diez versiones consecutivas de Ramparts incluyeron esta lógica sin que nadie la cuestionara, significa que los casos de prueba de seguridad no contemplaban el escenario de un atacante que controla el contenido del bundle. Eso es coherente con un patrón más amplio en herramientas de validación de ecosistemas de lenguajes dinámicos: se diseñan para detectar errores de configuración, no para resistir adversarios activos. ¿Cuántas otras herramientas de la cadena de CI/CD asumen que ciertos tipos de archivos son «seguros por defecto» sin verificarlo?