Der erneute Angriff auf Checkmarx offenbart ein beunruhigendes Muster: Nur wenige Wochen nach dem spektakulären KICS-Angriff im März 2026, bei dem TeamPCP bereits Docker-Images, VS Code-Erweiterungen und GitHub-Actions-Workflows kompromittiert hatte, ist die Gruppe wieder eingedrungen. Diesmal zielten sie direkt auf das Jenkins-AST-Plugin ab — eine kritische Komponente in vielen Continuous-Integration-Pipelines weltweit.
Der Ablauf war dabei bemerkenswert frech: TeamPCP verschaffte sich Zugang zum GitHub-Repository des Plugins und benannte es provokativ um zu “Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now.” Die Repository-Beschreibung wurde ebenfalls angepasst und warnte sarkastisch: “Checkmarx fails to rotate secrets again. with love – TeamPCP.” Diese Arroganz deutet auf ein Sicherheitsteam hin, das die Eindringlinge deutlich unterschätzt haben dürfte.
Checkmarx hat inzwischen eine bereinigte Version 2.0.13-848.v76e89de8a_053 auf GitHub und dem Jenkins Marketplace bereitgestellt. Das Unternehmen gab jedoch keine Details darüber preis, wie die manipulierte Version überhaupt veröffentlicht werden konnte — eine Informationslücke, die Vertrauen weiter erodiert.
Für die Sicherheitsforschung ist der Fall diagnostisch wertvoll: Security-Experte Adnan Khan und SOCRadar analysieren zwei problematische Szenarien. Entweder war die ursprüngliche Remediation nach dem März-Vorfall unvollständig und Zugangsdaten wurden nicht vollständig rotiert. Oder — noch beunruhigender — TeamPCP behielt eine versteckte Hintertür, die im ursprünglichen Incident-Response übersehen wurde. Das zweite Szenario wäre ein klassischer Post-Exploitation-Fehler: Man entfernt den Angreifer, aber nicht den Schlüssel, den er versteckt hat.
Die schnelle Rückkehr deutet darauf hin, dass TeamPCP aktiv nach Re-Entry-Points sucht und die Tiefe bisheriger Sicherheitsmaßnahmen auslot. Deutsche Unternehmen, die Jenkins und Checkmarx-Tools einsetzen, sollten sofort prüfen, welche Plugin-Versionen im Einsatz sind. Eine forensische Analyse verdächtiger Aktivitäten in den CI/CD-Pipelines ist notwendig. Das BSI könnte auch hier eine Warnung aussprechen, ähnlich wie bei anderen Supply-Chain-Vorfällen.