Checkmarx ha confirmado que se ha publicado una versión corregida del complemento Jenkins AST en Jenkins Marketplace.
«Si está utilizando el complemento AST de Checkmarx Jenkins, debe asegurarse de utilizar la versión 2.0.13-829.vc72453fa_1c16 publicada el 17 de diciembre de 2025 o antes», dijo la firma de ciberseguridad en un comunicado durante el fin de semana.
Al momento de escribir este artículo, Checkmarx ha lanzado 2.0.13-848.v76e89de8a_053 tanto en GitHub como en Jenkins Marketplace, pero su actualización de incidente aún indica «Se está trabajando en una nueva versión de este complemento». No dijo cómo se hizo pública la versión del complemento malicioso.
Este desarrollo es el último ataque orquestado por TeamPCP dirigido a Checkmarx. El incidente se produce semanas después de que se creyera que el notorio grupo cibercriminal había comprometido una imagen de KICS Docker, dos extensiones de VS Code y un flujo de trabajo de GitHub Actions para impulsar malware de robo de credenciales.
Esta infracción comprometió brevemente el paquete npm de la CLI de Bitwarden, que sirvió como un ladrón similar capaz de recopilar una amplia gama de secretos de desarrolladores.
TeamPCP ha estado implicado en una serie de infracciones desde marzo de 2026 como parte de una campaña más amplia para explotar la confianza inherente en la cadena de suministro de software para difundir malware y ampliar su alcance.
Según los detalles compartidos por los investigadores de seguridad Adnan Khan y SOCRadar, TeamPCP supuestamente comprometió el repositorio GitHub del complemento y cambió su nombre a «Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now».
El repositorio comprometido también se actualizó para incluir la siguiente descripción: «Checkmarx una vez más no pudo rotar los secretos. Con amor: TeamPCP».
«El hecho de que TeamPCP vuelva al sistema Checkmarx después de unas pocas semanas apunta a una de dos posibilidades: o la remediación inicial fue incompleta y las credenciales no se rotaron por completo, o el grupo pudo haber mantenido un punto de apoyo que no fue identificado en la respuesta de marzo», dijo SOCRadar.
«El próximo segundo incidente de Checkmarx sugiere que este grupo está monitoreando activamente los puntos de reentrada, probando la profundidad de las reparaciones pasadas y explotando las brechas».
Source link
