Checkmarx hackeado por segunda vez en un mes: tus extensiones de VS Code pudieron haber robado tus credenciales HOY

Si usas VS Code y tienes extensiones de Checkmarx instaladas, deja de leer esto y ve a revisar tus versiones ahorita. En serio. Te espero.

…

¿Ya? Bueno. Porque el 22 de abril de 2026, el grupo conocido como TeamPCP le metió mano a Checkmarx por segunda vez en menos de 30 días, y esta vez la cosa fue mucho más seria: extensiones oficiales que millones de devs usan a diario se convirtieron en ladrones de credenciales silenciosos.

El contexto: TeamPCP lleva meses sembrando caos

Para entender la magnitud de esto hay que ir un poco atrás. El 23 de marzo de 2026, TeamPCP ya había comprometido dos GitHub Actions de Checkmarx: checkmarx/ast-github-action y checkmarx/kics-github-action. En ese ataque hijackearon 35 tags y usaron el acceso para robar tokens de GitHub desde la memoria de runners de CI/CD.

¿Qué hicieron con esos tokens robados? Exactamente lo que te imaginas: los usaron de palanca para el siguiente golpe.

Según el análisis de Socket.dev, el 22 de abril los atacantes autenticaron contra Docker Hub usando credenciales legítimas de Checkmarx y empezaron a sobreescribir imágenes oficiales del repositorio checkmarx/kics. No fue un acceso de fuerza bruta ni un zero-day exótico: entraron con la llave de la casa.

Qué comprometieron exactamente

El ataque del 22 de abril fue escalonado y tocó múltiples ecosistemas en cuestión de horas:

Producto afectado	Versiones comprometidas	Ventana de tiempo (UTC)
KICS Docker Hub (checkmarx/kics)	v2.1.20, alpine, latest, v2.1.21 falso	12:31 a 12:59
VS Code Extension: ast-results	v2.63.0, v2.66.0	13:06 a 17:48
VS Code Extension: cx-dev-assist	v1.17.0, v1.19.0	13:06 a 17:48
GitHub Actions (ast-github-action)	v2.3.35	14:17 a 15:41
Open VSX marketplace	mismas versiones	13:06 a 21:20

La extensión cx-dev-assist es particularmente popular entre equipos de seguridad que integran Checkmarx directamente en su flujo de desarrollo. La versión 1.18.0 ya traía el parche: si estás en 1.17.0 o brincaste a 1.19.0, estuviste en la ventana de riesgo.

Qué robaba el malware

Acá viene la parte que te va a erizar los pelos. The Hacker News documentó que el payload inyectado en las extensiones de VS Code incluía un módulo llamado mcpAddon.js, diseñado específicamente para barrer el sistema del developer y exfiltrar:

• Tokens de autenticación de GitHub
• Credenciales de AWS
• Tokens de Azure
• Bases de datos de credenciales de Google Cloud
• Archivos .npmrc (con tokens de npm)
• Claves SSH y configuraciones
• Variables de entorno del sistema
• Archivos de configuración de Claude y herramientas MCP

Ese último punto no es menor. Con el auge de los agentes de IA y herramientas como Manus Desktop de Meta que ya integran MCP directamente, los configs de MCP se están convirtiendo en llaves maestra de infraestructura completa. Robarlos no es chiste.

Todo ese contenido se comprimía, se encriptaba y se mandaba a audit.checkmarx[.]cx/v1/telemetry, un dominio que se veía legítimo de Checkmarx pero estaba bajo control de los atacantes.

El gusano que se propagaba por npm

Lo más peligroso del ataque no fue el robo en sí, sino cómo se replicaba. Una vez que el malware tenía las credenciales de npm del dev comprometido, ejecutaba un flujo automatizado:

1. Consultaba la API de npm para listar todos los paquetes donde esa cuenta tenía permisos de escritura
2. Compilaba la lista de “targets publicables”
3. Republicaba esos paquetes con el payload malicioso embebido

Una chimba de mecanismo de distribución, dicho en el peor sentido posible. Un solo developer comprometido podía infectar decenas de paquetes de los que él era mantenedor, contaminando a miles de proyectos downstream sin que nadie se diera cuenta.

BleepingComputer confirmó que el ataque también alcanzó el CLI de Bitwarden como parte de la misma campaña, lo que sugiere que TeamPCP ya tenía acceso a tokens con permisos mucho más amplios de lo que Checkmarx reconoció inicialmente.

La respuesta oficial de Checkmarx

En su comunicado del 22 de abril, Checkmarx confirmó el incidente y señaló que los artefactos maliciosos no sobrescribieron versiones anteriores conocidas como seguras. En teoría, si pinneabas SHAs específicos o usabas versiones anteriores a la ventana comprometida, no te afectó.

La empresa restauró las imágenes afectadas a sus digests legítimos y eliminó la tag falsa v2.1.21 que ni siquiera correspondía a ningún release oficial.

Pero seamos honestos: la mayoría de los equipos no pinnean SHAs ni revisan digests a diario. Si tenías latest activado en tu pipeline de KICS o auto-update habilitado en VS Code, probablemente jalaste el malware sin saberlo.

Qué hacer ahorita si usas herramientas de Checkmarx

Esta es la lista de acciones inmediatas. No para mañana, para hoy:

1. Revisa tus versiones de extensiones de VS Code Verifica que ast-results y cx-dev-assist sean versiones posteriores a las comprometidas. Desinstala y reinstala desde el Marketplace oficial de Microsoft, no desde Open VSX.

2. Rota TODAS tus credenciales si estuviste en la ventana No solo las de GitHub. AWS, Azure, GCP, npm, claves SSH, todo. Si un token vivía en las variables de entorno de tu sistema entre el 22 de abril y la fecha en que parcheaste, asume que está comprometido.

3. Bloquea estos dominios en tu red perimetral

• checkmarx.cx (91.195.240.123)
• audit.checkmarx.cx (94.154.172.43)
• updates.checkmarx.cx
• checkmarx.zone

4. Audita tus workflows de GitHub Busca específicamente .github/workflows/format-check.yml y cualquier workflow que no reconozcas. TeamPCP inyectó workflows para capturar secretos como artefactos.

5. Revisa tus paquetes npm Si mantienes paquetes en npm y tu token pudo haber sido robado, revisa el historial de publicaciones de tus paquetes en busca de versiones no autorizadas.

El patrón que se repite y nadie está aprendiendo

Este ataque no es un caso aislado. Es parte de una campaña sistemática de TeamPCP que en marzo también comprometió el repositorio de Trivy (el scanner de vulnerabilidades de Aqua Security) antes de llegar a Checkmarx. El patrón es siempre el mismo: comprometer un token de CI/CD, usarlo como palanca para el siguiente ataque, y así sucesivamente.

Lo que hace esto especialmente preocupante para devs en México y LATAM es que la mayoría de las empresas de la región no tienen procesos formales de auditoría de supply chain. Como señalamos en nuestro análisis sobre la regulación de IA que ya afecta a empresas en México, el cumplimiento regulatorio en seguridad sigue siendo un tema pendiente, y ataques como este demuestran el costo real de no tener controles básicos.

Pinear imágenes de Docker por SHA, desactivar auto-updates en extensiones de IDE para proyectos críticos, usar secretos con alcance mínimo necesario: no son prácticas de ninja, son higiene básica que la mayoría de los equipos omite por flojera o por que “nunca ha pasado nada”.

Ya pasó. Dos veces en un mes en la misma empresa.

¿Tu equipo tiene un proceso definido para esto? Cuéntalo en los comentarios, porque la neta el silencio en ese tema es bastante elocuente.

Fuentes

• Socket.dev: Malicious Checkmarx Artifacts Found in Official KICS Docker Repository
• The Hacker News: Malicious KICS Docker Images and VS Code Extensions Hit Checkmarx Supply Chain
• BleepingComputer: New Checkmarx supply-chain breach affects KICS analysis tool
• Checkmarx Blog: Security Update April 22
• Sysdig: TeamPCP expands, supply chain compromise spreads from Trivy to Checkmarx GitHub Actions
• Docker Blog: Trivy, KICS, and the shape of supply chain attacks so far in 2026
• CyberNews: Checkmarx suffers second massive supply chain attack