Cuando un plugin de Jenkins se convierte en puerta trasera el caso Checkmarx expone credenciales y la seguridad de la cadena de suministro

Durante el fin de semana Checkmarx confirmó que una versión maliciosa de su plugin Jenkins para Application Security Testing (AST) fue publicada en el Marketplace de Jenkins, en lo que se suma a una cadena de incidentes que ya incluye filtraciones y artefactos troceados en GitHub, Docker y marketplaces de extensiones. La actoría conocida como TeamPCP aprovechó credenciales obtenidas en una brecha previa —vinculada al incidente contra Trivy— para insertar código con capacidad de robo de credenciales en varias herramientas de desarrollo, incluyendo una versión del plugin de Checkmarx subida fuera de su canal oficial. Puede consultarse la nota oficial de la compañía con los detalles y recomendaciones iniciales en su comunicado público: Checkmarx security update.

Jenkins es un pilar en muchos pipelines CI/CD y cualquier componente que se integre en su flujo de trabajo tiene acceso, en mayor o menor medida, a secretos, artefactos de build y credenciales de despliegue. Un plugin backdooreado no sólo puede exfiltrar tokens y credenciales almacenadas en el entorno del build, sino también actuar como vector para movimientos laterales y persistencia dentro de la infraestructura de desarrollo. La versión sospechosa publicada fue identificada como 2026.5.09 y, según Checkmarx, no siguió el procedimiento normal de releases (sin git tag ni release oficial), mientras que la compañía recomienda mantener, en lo posible, la versión segura 2.0.13-829.vc72453fa_1c16 o una anterior hasta que se confirme la remediación completa. El plugin oficial en el repositorio de Jenkins puede revisarse aquí: Checkmarx AST plugin.

Más allá del impacto puntual, este incidente subraya dos puntos críticos: la fragilidad de las credenciales persistentes en repositorios y la necesidad de validar cada artefacto que entra en el pipeline. Cuando una credencial se filtra en un eslabón de la cadena de suministro, el atacante puede pivotar a múltiples vectores (repos, images, extensiones) y mantener acceso por largos periodos si no se rotan y revocan secretos. El mensaje dejado por los atacantes —acusando la falta de rotación de secretos— es un recordatorio crudo: las rotaciones periódicas y la gestión con políticas de caducidad son control básico pero frecuentemente descuidado.

Si administras Jenkins o integras el plugin comprometido, asume que cualquier secreto que pasó por los jobs puede estar comprometido. Las acciones inmediatas deben incluir identificar y poner en cuarentena instancias que hayan instalado la versión 2026.5.09, rotar todos los secretos y credenciales expuestas, revocar tokens y claves asociadas a repositorios y sistemas de CI/CD, y buscar evidencias de exfiltración o persistencia. Checkmarx ha publicado indicadores de compromiso (IoCs) y artefactos maliciosos que los equipos de respuesta pueden utilizar para investigar; revisa su portal de seguridad y comunicaciones oficiales para obtener esas muestras y firmas.

En la parte operativa conviene revisar los pipelines en busca de accesos inusuales, comandos o descargas externos ejecutados por jobs, y auditar logs de GitHub, Docker Registry y sistemas de empaquetado. Revocar y volver a emitir credenciales con más restricciones (scope limitado, expiración corta), sustituir credenciales persistentes por mecanismos de identidad federada temporal (por ejemplo OIDC donde sea aplicable) y reforzar la segregación de entornos son medidas inmediatas para reducir el blast radius. Además, la verificación de integridad de artefactos (firmas, checksums, reproducible builds) y la preferencia por artefactos firmados en el pipeline dificultan la aceptación automática de paquetes no autorizados.

A medio y largo plazo las organizaciones deben elevar su higiene de seguridad en la cadena de suministro: implementación sistemática de políticas para tokens de máquina en repositorios, bloqueo de credenciales en los historiales, revisión de permisos en cuentas de servicio, y auditorías regulares a terceros y a los canales de publicación de plugins y paquetes. También es el momento de cuestionar procesos de desarrollo que permiten publicar artefactos críticos sin revisiones de seguridad independientes o sin controles de firma y trazabilidad. Para seguir el rastro técnico del compromiso por parte de investigadores independientes puede consultarse la evidencia pública compartida por analistas y responsables de la divulgación, incluido el hilo documentado por el investigador que identificó la actividad en GitHub: Adnan Khan en X.

Finalmente, aunque Checkmarx asegura que sus repositorios no contienen datos de clientes y que el entorno de desarrollo está separado del entorno de producción, las organizaciones deben actuar como si hubieran sido afectadas si han instalado el plugin comprometido y llevar a cabo una respuesta completa: detección, contención, erradicación y aprendizaje. La cadena de suministros software es ahora un objetivo preferente; reducir la exposición exige tanto cambios técnicos como disciplina operativa continua.