CVE-2026-82329 — qué ocurre en tus pipelines
La CVE-2026-82329 es un bypass de autenticación en el componente REST API de JFrog Artifactory. Con una puntuación CVSS 3.1 de 9.8 (crítica), permite a un atacante remoto y no autenticado saltarse completamente los controles de acceso: puede leer, escribir y eliminar artefactos en cualquier repositorio Maven, npm, Docker u otro. La vulnerabilidad fue notificada a JFrog a finales de julio de 2026 y Fastly recopiló evidencias de explotación activa ya el 25 de agosto. El 2 de septiembre, la CISA la incluyó en su catálogo de vulnerabilidades explotadas conocidas, lo que indica que actores maliciosos la usan a gran escala. En un contexto CI/CD, un repositorio Artifactory comprometido es una puerta de entrada directa a cada entorno que descarga sus dependencias de ese servidor: la próxima compilación se convierte en el vector de propagación.
La backdoor Rust: CVE-2026-42016 y CVE-2026-42018
Los incidentes documentados por SecurityWeek y The Hacker News revelan una cadena en dos etapas. CVE-2026-42016 explota primero CVE-2026-82329 para depositar un ejecutable Rust en un paquete de la cadena de dependencias objetivo. CVE-2026-42018 describe el comportamiento malicioso de ese ejecutable: conexión C2 cifrada, exfiltración de tokens de entorno (CI_JOB_TOKEN, DOCKER_AUTH_CONFIG, secretos de Vault) y persistencia mediante un hook post-install. El atacante no necesita comprometerse el servidor Artifactory en sí: le basta con escribir en un repositorio compartido consumido por tus runners de GitLab, GitHub Actions o Jenkins. La siguiente compilación descarga y ejecuta la backdoor en el contexto del pipeline, con todos los secretos inyectados por tu CI. El vector elude el análisis antivirus clásico porque el binario Rust se presenta como una herramienta de prueba legítima.
Quién está afectado — versiones y configuraciones
- Artifactory on-premises 7.x todas las ediciones (OSS, Pro, Enterprise) hasta 7.84.17 incluida
- Artifactory on-premises 6.x: todas las versiones (rama en fin de vida, sin parche previsto)
- Artifactory Cloud (JFrog SaaS): parcheado por JFrog el 28 de agosto de 2026, no se requiere acción
- Artifactory en Kubernetes (Helm chart oficial): la versión de la imagen determina la vulnerabilidad, no la del chart
- Instancias que exponen la REST API en Internet a través de un proxy inverso: riesgo inmediato y confirmado
- Instancias solo en red interna: riesgo reducido pero no nulo — movimiento lateral post-intrusión documentado
Triaje urgente — 4 pasos antes de parchear
Verificar la versión instalada
Ve a Administration → General → About o ejecuta: curl -u admin:CONTRASEÑA http://localhost:8082/artifactory/api/system/version. Si la versión devuelta es inferior a 7.84.18, la instancia es vulnerable. Anota el número exacto para el procedimiento de actualización.
Buscar indicadores de compromiso (IOC)
Revisa los logs ($ARTIFACTORY_HOME/var/log/artifactory-request.log) en busca de peticiones POST anónimas sobre /api/storage/, /api/deploy/ o /api/conan/. Un volumen inusual de 401 seguidos de un 201 o 200 sin user-agent conocido es una señal clara. Compara los hashes de tus paquetes críticos con los valores esperados en tu SBOM o lockfile.
Aislar la instancia si está comprometida
Si detectas artefactos sospechosos, bloquea el acceso entrante en los puertos 8081 y 8082 (ufw deny in 8081 / 8082) y revoca todos los tokens de API existentes. Conserva los logs antes de parchear. Notifica a tus equipos de CI para que eviten cualquier build que descargue dependencias de la instancia hasta que finalice el triaje.
Auditar los pipelines CI consumidores
Lista todos los pipelines que apunten a tu Artifactory. Para cada build ejecutado entre el 25 de agosto y hoy, verifica los artefactos descargados, los binarios ejecutados en la fase de pruebas y los tokens potencialmente expuestos. Rota por precaución todos los secretos de CI inyectados en los runners que hayan descargado dependencias de la instancia sospechosa.
Parchear Artifactory — procedimiento oficial de JFrog
JFrog publicó el parche en la versión 7.84.18 para la rama 7.x. Para una instalación RPM o DEB, detén el servicio (systemctl stop artifactory), reemplaza el paquete (yum update jfrog-artifactory-pro o apt-get install --only-upgrade jfrog-artifactory-oss), verifica la integridad de los archivos de configuración en $ARTIFACTORY_HOME/var/etc/artifactory/, y reinicia. El tiempo de inactividad es de 5 a 10 minutos. Para despliegues Helm, actualiza el tag de imagen a releases-docker.jfrog.io/jfrog/artifactory-oss:7.84.18 y ejecuta helm upgrade. La rama 6.x ya no tiene mantenimiento: la actualización a 7.84.18+ es la única opción soportada — una mitigación parcial con WAF no es suficiente.
Una alternativa duradera: Gitea Packages
Si gestionas tu Artifactory principalmente como registro de paquetes para tus pipelines CI/CD, Gitea Packages cubre el mismo ámbito funcional desde la versión 1.20 sin gastos de licencia Enterprise ni superficie de ataque compartida. Gitea Packages admite de forma nativa Maven, npm, Docker, PyPI, Cargo (Rust), módulos Go, NuGet, Debian, RPM, Helm y Composer, todos accesibles mediante las URL estándar que esperan tus herramientas. La autenticación usa los tokens de Gitea existentes, los permisos de organización y las claves de despliegue — los mismos elementos que tu forge Git. Una instancia Gitea auto-alojada te da control total sobre la retención, los webhooks de política y la integración OIDC, sin depender de un proveedor externo para tus artefactos de producción.
Artifactory OSS vs Gitea Packages — comparativa práctica
Desplace la tabla
| Criterio | Artifactory OSS 7.x | Gitea Packages 1.21 |
|---|---|---|
| Formatos soportados | Maven, Gradle, npm, PyPI, Docker, Helm, Conan | Maven, npm, Docker, PyPI, Cargo, Go, NuGet, Debian, RPM, Helm, Conan |
| Licencia | SSPL (restricciones de uso comercial cloud) | MIT — libre para cualquier uso |
| Infra mínima | 4 vCPU / 8 GB RAM recomendados | 2 vCPU / 4 GB (equipo ≤ 10), 4 vCPU / 8 GB (equipo activo) |
| CVE críticas (24 meses) | CVE-2024-45793, CVE-2025-11345, CVE-2026-82329 | 0 CVE críticas en el período |
| Auth unificada forge + registro | No — IAM separado | Sí — mismo token, misma org de Gitea |
| Tiempo de instalación | 30-60 min (JVM, config DB) | < 15 min (binario único o imagen Docker) |
Desplegar Gitea en un VPS y configurar el registro
Aprovisionar el VPS
Elige un VPS con al menos 2 vCPU y 4 GB de RAM para un equipo pequeño, 4 vCPU y 8 GB para un equipo activo con capas Docker voluminosas. La imagen Gitea preconfigurada del catálogo ServOrbit arranca Gitea, PostgreSQL y un proxy inverso nginx con TLS de Let's Encrypt mediante un único comando cloud-init. Una vez la VM en marcha, apunta tu dominio (por ejemplo gitea.tuempresa.com) a la IP del VPS.
Completar la instalación de Gitea
Ve a https://gitea.tuempresa.com/install. Introduce la conexión PostgreSQL (host localhost, base de datos gitea, usuario gitea), desactiva el registro público si tu instancia es interna y activa 2FA obligatorio para administradores. Los paquetes están habilitados por defecto desde la v1.20 — no se necesita configuración adicional.
Configurar el registro npm, Maven o Docker
Para npm: npm config set @TU_ORG:registry https://gitea.tuempresa.com/api/packages/TU_ORG/npm/ y añade un token de Gitea en ~/.npmrc. Para Maven: añade el repositorio en settings.xml apuntando a https://gitea.tuempresa.com/api/packages/TU_ORG/maven. Para Docker: docker login gitea.tuempresa.com y etiqueta tus imágenes como gitea.tuempresa.com/TU_ORG/mi-imagen:tag.
Securizar el acceso de red
Restringe el acceso a la API de paquetes a los rangos IP de tus runners de CI (regla ufw o grupo de seguridad cloud). Activa el HTTPS forzado en app.ini ([server] REDIRECT_OTHER_PORT = true). Configura webhooks de Gitea para notificar a tu SIEM en cada publicación de paquetes. Activa la política de retención automática de versiones antiguas para evitar la acumulación de capas Docker.
Migrar tus artefactos desde Artifactory
La migración puede hacerse de forma gradual sin interrumpir los pipelines existentes. Empieza por los repositorios menos críticos — típicamente bibliotecas npm internas o paquetes Python privados. Publica las nuevas versiones directamente en Gitea Packages y actualiza las referencias en tus lockfiles. Para Maven, actualiza la URL del repositorio en settings.xml y ejecuta mvn deploy sobre tus snapshots actuales. Para Docker, reetiqueta las imágenes con docker tag y empújalas al nuevo registro con docker push gitea.tuempresa.com/ORG/IMAGEN:TAG. Las imágenes son idénticas — solo cambia el FQDN del registro en tus archivos docker-compose.yml y manifiestos de Kubernetes. Planifica una ventana de coexistencia de una a dos semanas para cambiar los pipelines uno a uno con posibilidad de retroceso.
Verificación post-migración: ejecuta un análisis SBOM (syft o grype) sobre los artefactos publicados en Gitea para confirmar que ningún binario sospechoso siguió la migración. Prueba pip install, npm install, docker pull y mvn dependency:resolve desde un entorno limpio que apunte exclusivamente al nuevo registro. Si todas las compilaciones pasan y el SBOM está limpio, revoca el acceso a la antigua instancia de Artifactory y elimina sus credenciales de los secretos de CI.
